From dpartridge at tangible.net Wed Jan 9 05:45:43 2013 From: dpartridge at tangible.net (David Partridge) Date: Wed, 9 Jan 2013 00:45:43 -0500 Subject: [Pki-users] Problems with Dogtag and CA cert signed by External CA In-Reply-To: <1574626.DPzbviIWT1@hudson.private.lan> References: <1879296.Sx4g43KeR8@hudson.private.lan> <507F1AA4.80009@redhat.com> <1574626.DPzbviIWT1@hudson.private.lan> Message-ID: <60F0F3C7AB631C4EB97B07CEE01B45355D9BF7B8AE@exch01.tangible.net> If using graphical interface and you exceed timelimit on the form for importing certificates signed by external CA, close browser and make sure as you navigate back to screen to associate CSR's with certificates that the little boxes that "remove existing database" or to that effect are NOT checked. You are destroying your initial CA database that has the CSR in the request branch when you try to associate the CSR's aka requests with the certificates. David M. Partridge Senior Identity Management and Security Engineer Tangible Software | 2010 Corporate Ridge, #620 McLean, Virginia 22102 | dpartridge at tangible.net Direct: 800-913-9901 x3001 | Cell: 571-286-9628 Fax: 703-288-1226 | DCO Jabber: david.partridge2 at chat.dco.dod.mil CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > -----Original Message----- > From: Dwayne MacKinnon [mailto:dmk at ncf.ca] > Sent: Thursday, October 18, 2012 11:50 AM > To: John Dennis > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] Problems with Dogtag and CA cert signed by > External CA > > On October 17, 2012 04:52:52 PM John Dennis wrote: > > On 10/17/2012 03:52 PM, Dwayne MacKinnon wrote: > > > Hi all, > > > > > > A helpful fellow called alee on #dogtag-pki suggested I write the > list. > > > I've been playing with dogtag-pki-9.0.0-10 on 64-bit Fedora 17. > > > > > > I'm looking to use dogtag to run a subordinate CA that does all our > > > everyday PKI stuff. So when I used pki-create and went into the > > > webform, I went the "create a csr" route and signed it using a root > > > CA I'd set up using openssl. > > > > > > Everything seemed to work out fine, until I got to the point where > I > > > was restarting pki-cad (using systemctl restart > > > pki-cad at pki-ca.service). It wouldn't start. > > > > > > With alee's help I tracked it down to a failure of > > > SystemCertsVerification during the selftests. > > > > > > He asked me to submit my debug log to the list, so here it is. > > > > Interestingly enough I'm in the middle of tracking down why NSS will > > not validate a self signed cert as a CA. I suspect dogtag is calling > > NSS's CERT_VerifyCertificateNow (or it's equivalent) and passing it a > > specific usage parameter. > > > > There are very specific requirements to accept a CA cert as valid. > > More valuable than the log would be show us what the cert looks like. > > I would ordinarily tell you to dump the cert in text form using > > openssl x509 -text but openssl often omits detailed information on > the > > cert extensions which are critical (no pun intended) here. How about > > if you also provide us with a PEM formatted version of the cert and > > we'll use our tools to examine it's contents. > > Sure. I've generated a clone cert with phony credentials. It's attached. > Thanks for the assistance. > > Cheers, > DMK -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5739 bytes Desc: not available URL: From alee at redhat.com Fri Jan 18 03:22:45 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 17 Jan 2013 22:22:45 -0500 Subject: [Pki-users] Announcing the release of Dogtag 10 Message-ID: <1358479366.4296.77.camel@aleeredhat.laptop> The Dogtag team is proud to announce the release of Dogtag v10.0.0. This release is being bundled with the GA release of Fedora 18, and marks the culmination of over a year of development by the Dogtag team. == Build Versions == pki-core-10.0.0-2.fc18 pki-ra-10.0.0-1.fc18 pki-tps-10.0.0-1.fc18 dogtag-pki-10.0.0-1.fc18 dogtag-pki-theme-10.0.0-1.fc18 pki-console-10.0.0-1.fc18 == Upgrade Notes == It is possible to upgrade from a Dogtag 9 instance by first upgrading your server to Fedora 18 and then updating the Dogtag software. Existing Dogtag instances will continue to work correctly using existing instances, with the Java-based instances running on Tomcat 6. However, because the new functionality and interfaces depend on instance configuration, these will not be available to existing Dogtag 9-style instances. To take advantage of these new features, new Dogtag 10 instances should be created. Documentation will soon be provided on how to migrate a Dogtag 9 - style instance to a new Dogtag 10 instance. == Highlights since Dogtag v. 9 == Infrastructure and Development Changes: * The Dogtag code base was moved to git from svn. * Java development is now done under Eclipse. * Dogtag 10 uses its own public-facing TRAC project management system. * Improvements were made to CMake modules for Java development. * Java development uses OpenJDK 7. * Python development uses Python 2.7 and Jython 2.2. * Dogtag 10 Java-based instances run on Tomcat 7. * Dogtag 10 RA and TPS instances run on Apache 2.4. Refactoring and Cleanup: * Code has been reformatted to uniform formatting and coding standards. * Based on feedback provided by Eclipse and Coverity, the following types of cleanup occurred: ** Removal of dead code and unnecessary code blocks. ** Removal of generic containers and implementation of type safety. ** Removal/ replacement of deprecated code, with the addition of JUnit tests to confirm correctness. ** Address various memory leaks and corruption issues, coding style issues etc. * The Dogtag code pre-dates many of the modern Java utilities to do encoding, HTTP and XML parsing etc. As a result, custom code was written to do these functions. This code has been replaced with standard code, and a whole package (osutil) was eliminated. REST Interface: To allow easier and more intuitive interaction with the Dogtag servers, a new REST interface has been added. This interface is based on RESTEasy framework, a fully certified implementation of the JAX-RS specification. Clients interact with this framework using intuitive REST URLs, and using standard XML or JSON inputs. Included is a Java client proxy framework which can be used by client applications to build HTTP requests on the Dogtag servers, simply by invoking methods on the client objects. This client framework is used in the new command line interface "pki" as described below. The plan is to continue over time to extend the REST interface to cover all of the essential Dogtag functionality. In this release, the following functionality has been implemented: * With a CA: ** Create, review and approve certificate requests. ** List, view, revoke, hold and release certificates. ** Get installation token from security domain ** Add/remove KRA connector configuration ** Retrieve and list certificate profiles * With KRA: ** Retrieve transport certificate ** List/ archive and recover symmetric keys * With all Java systems: ** Add/Remove/Modify/View users, groups and group members ** Start system installation service Third-party Components: * Dogtag 10 includes JQuery and the Jquery.i18n.properties plug-in. CLI: * A new intuitive command line interface has been created, based on the RESTEasy client framework. This allows administrators and agents to perform all of the operations exposed by the REST interface from the command line, or from scripts. Storage of symmetric keys in the DRM: * The DRM provides secure encrypted storage for asymmetric keys. The KRA has been extended to provide a mechanism to securely archive and recover symmetric keys. This would be useful for storing disk encryption keys for instance. SELinux changes: * In Dogtag 9, we maintained a custom SELinux policy to provide mandatory access controls for interactions with the Dogtag server. In Dogtag 10, this policy has been cleaned up, simplified and integrated into the system base policy. As a result, the pki-selinux package has been retired. ECC: * In earlier releases, Dogtag only supported ECC certificate issuance when the CA was connected to an ECC-capable external crypto token. In Dogtag 10, all CS servers (CA, OCSP, DRM, TKS, TPS) can now be issued ECC certificates and run in such environment that: ** CS servers can communicate securely with ECC SSL certificates. ** Administrators and agents can access their administration ports via SSL using ECC certificates ** ECC encryption certificates can now have their private keys archived (and recovered) by the DRM. For this feature, we used an ECC-capable HSM in our development and QE environment on the client side for development and testing. Certicom software tokens could not be used because of an issue with malformed private keys. ** The TMS testing client tool, tpsclient, can now be used to test token-based enrollment and key archival in the TMS environment (the actual smart card support will follow in a later release) New Installer: * New installer tools (pkispawn, pkidestroy) has been written in Python to create Dogtag Java-based instances (CA, KRA, OCSP, TKS). Over time, this installer will be extended to handle the remaining Apache-based instances (TPS and RA), and pkicreate/pkiremove/pkisilent will be retired and removed. * pkispawn performs the same operations that pkicreate and the pkisilent used to do, meaning that a Dogtag Java-based instance can be installed and configured in a single non-interactive step. With the right options, though, it is still possible to configure an instance by going through the web-based installation UI panels. New Directory Layout/ Architecture/ Standard Ports * It is now possible (though not required) to install multiple Java subsystems (CA, KRA, TKS, OCSP) within a single tomcat instance. This is useful for small deployments where, for example, you might want leverage the capabilities of a CA and KRA on a single server. In keeping with this change, the directory structure of a Dogtag instance has changed. * By default, Dogtag will install on the default tomcat ports (8443 and 8080). There will no longer be any separation of EE, admin and agent interfaces on different ports. Package Restructuring: * The Dogtag RPM packages have been restructured to reduce the number of packages and more accurately separate client and server components. The current packages are: ** pki-base: code common to clients and server ** pki-tools: Java and native tools used by client and server. ** pki-server: code used by Java servers, only on the server. ** pki-ca, pki-kra, pki-ocsp, pki-tks, pki-ra, pki-tps: subsystem specific code ** pki-javadoc: consolidation of the pki-common-javadoc, pki-java-tools-javadoc, and pki-util-javadoc packages ** pki-symkey: provides native symmetric key operations ** pki-console: administrative tool for CA, KRA, OCSP, and TKS * The UI packages have been rearranged and consolidated to make customizing an instance's user interfaces more straightforward, and to ensure a more consistent look and feel across subsystems. All of the subsystem-specific UI packages have been eliminated, and there is now a single UI package (dogtag-pki-server-theme) which contains all the CSS style sheets, image files and properties files for all subsystems. A customer wanting to customize the UI could simply replace the components in this package. Additionally, the pki-console requires its own UI package, dogtag-pki-console-theme. * A meta-package (dogtag-pki) has been created to conveniently install all existing Dogtag 10 PKI packages. From alee at redhat.com Fri Jan 18 03:23:12 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 17 Jan 2013 22:23:12 -0500 Subject: [Pki-users] Announcing Dogtag 10.0.1 for pki-core and dogtag-pki Message-ID: <1358479393.4296.78.camel@aleeredhat.laptop> The Dogtag team is proud to announce the first errata build for Dogtag v10.0.0. The only packages that are being modified are dogtag-pki and pki-core, both of which are being released as version 10.0.1. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.1-1.fc18 pki-ra-10.0.0-1.fc18 pki-tps-10.0.0-1.fc18 dogtag-pki-10.0.1-1.fc18 dogtag-pki-theme-10.0.0-1.fc18 pki-console-10.0.0-1.fc18 == Highlights since Dogtag v. 10.0.0 == * Nonces have been added to the RESTful interface for certificate revocation to preventing cross site scripting attacks on that interface. * A new servlet has been added to the RESTful interface to add and remove KRA connector configuration from a CA. This is used to clean up a CA when a KRA is destroyed. * The default validity of the CA signing cert has been lengthened from 8 to 20 years. * pkispawn has been modified to allow the user to specify the location of the generated admin cert PKCS#12 file. * OCSP now supports ECC CRLs. * A more robust use of interpolation has been added to pkispawn. * pkidaemon has been repaired to display the runtime status of PKI Java-based instances * A third-party license file has been added for Dogtag 10's use of JQuery and the JQuery.i18n.properties plug-in == Detailed Changes since Dogtag v. 10.0.0 == alee (12): - TRAC Ticket 367 - pkidestroy does not remove connector - Fix spec file to allow f17 to work with latest tomcatjss - TRAC Ticket 466 - Increase root CA validity to 20 years - TRAC Ticket 437 - Make admin cert p12 file location configurable - TRAC Ticket 393 - pkispawn fails when selinux is disabled - Punctuation and formatting changes in man pages - TRAC Ticket 436 - Interpolation for pki_subsystem - TRAC Ticket 433 - Interpolation for paths - TRAC Ticket 435 - Identical instance id and instance name - TRAC Ticket 406 - Replace file dependencies with package dependencies - Revert to using default config file for pkidestroy - Hardcode setting of resteasy-lib for instance cfu (1): - Bugzilla Bug 839426 - [RFE] ECC CRL support for OCSP edewata (3): - TRAC Ticket 214 - Missing error description for duplicate user - TRAC Ticket 213 - Add nonces for cert revocation - TRAC Ticket 191 - Mapping HTTP Exceptions to HTTP error codes mharmsen (4): - TRAC Ticket #430 - License for 3rd party code - TRAC Ticket 469 - Fix tomcatjss issue in spec files - TRAC Ticket 468 - pkispawn throws exception - TRAC Ticket 271 - Dogtag 10: Fix 'status' command in 'pkidaemon' From ryan.millay at gdc4s.com Mon Jan 21 14:58:06 2013 From: ryan.millay at gdc4s.com (ryan.millay at gdc4s.com) Date: Mon, 21 Jan 2013 09:58:06 -0500 Subject: [Pki-users] Configurable Subject Alt Name in Cert Profile? Message-ID: <24EA29E701392440B83354C4C16C5B9AF41F48@MA05EXM01.gdc4s.com> RHEL 5.8 Red Hat CS 8.1 I'm hoping this should be a relatively straight forward question and others have run into something similar: When generating a certificate, is it possible to dynamically include/not include the Subject Alt Name field based on an LDAP parameter? When looking at the certificate profile there's a "subjAltExtGNEnable" parameter, but I don't believe that can be set to a request parameter, like $request.includeSAN$ for example, based on the testing I've done. Assuming that the "subjAltExtGNEnable" field must be static text, perhaps there is another work around. If included, the Subject Alt Name in this case would represent a user's full DN. If not included, the request parameter could be left blank and the Subject Alt Name would be empty. Here's a little snippet from the cert profile: policyset.CSCertSet.7.constraint.class_id=noConstraintImpl policyset.CSCertSet.7.constraint.name=No Constraint policyset.CSCertSet.7.default.class_id=subjectAltNameExtDefaultImpl policyset.CSCertSet.7.default.name=Subject Alternative Name Extension Default policyset.CSCertSet.7.default.params.subjAltExtGNEnable_0=true policyset.CSCertSet.7.default.params.subjAltExtGNEnable_1=false policyset.CSCertSet.7.default.params.subjAltExtGNEnable_2=false policyset.CSCertSet.7.default.params.subjAltExtGNEnable_3=false policyset.CSCertSet.7.default.params.subjAltExtGNEnable_4=false policyset.CSCertSet.7.default.params.subjAltExtPattern_0=$request.pkispo nsordn$ policyset.CSCertSet.7.default.params.subjAltExtPattern_1= policyset.CSCertSet.7.default.params.subjAltExtPattern_2= policyset.CSCertSet.7.default.params.subjAltExtPattern_3= policyset.CSCertSet.7.default.params.subjAltExtPattern_4= policyset.CSCertSet.7.default.params.subjAltExtType_0=DirectoryName policyset.CSCertSet.7.default.params.subjAltExtType_1=RFC822Name policyset.CSCertSet.7.default.params.subjAltExtType_2=RFC822Name policyset.CSCertSet.7.default.params.subjAltExtType_3=RFC822Name policyset.CSCertSet.7.default.params.subjAltExtType_4=RFC822Name policyset.CSCertSet.7.default.params.subjAltNameExtCritical=false The issue that arises here is the CA fails with an IO exception from the $request.pkisponsordn$ format. That value is a user DN, similar to CN=FIRSTNAME.LASTNAME, OU=ORGANIZATION, OU=ORGANIZATION2, O=COUNTRY, C=COUNTRYCODE. The CA's debug log shows the '=' and the ',' being escaped by backslashes. The CA then fails to populate the Subject Alt Name due to the following error: SubjectAltNameExtDefault: populate java.io.IOException: Unknown AVA keyword 'CN\'. Is there a way to properly escape the user DN so it can be used in the Subject Alt Name? Again, the ultimate goal being the user DN could be populated or not. If populated, it is included as the Subject Alt Name. If not populated, the Subject Alt Name is left blank when the certificate is generated. Thank you, Ryan Millay -------------- next part -------------- An HTML attachment was scrubbed... URL: From msauton at redhat.com Wed Jan 23 07:38:45 2013 From: msauton at redhat.com (Marc Sauton) Date: Tue, 22 Jan 2013 23:38:45 -0800 Subject: [Pki-users] Configurable Subject Alt Name in Cert Profile? In-Reply-To: <24EA29E701392440B83354C4C16C5B9AF41F48@MA05EXM01.gdc4s.com> References: <24EA29E701392440B83354C4C16C5B9AF41F48@MA05EXM01.gdc4s.com> Message-ID: <50FF9385.8000400@redhat.com> Hello Ryan, I tried something with pki-ca-8.1.0-11 and could not see the subject DN escape exceptoin, may be the request was formed differently, in my test enrollment form created by a profile with this: ... input.i4.class_id=genericInputImpl input.i4.params.gi_display_name0=testmssan input.i4.params.gi_param_enable0=true input.i4.params.gi_param_name0=testmssan input.i4.params.gi_num=1 ... policyset.userCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.userCertSet.1.constraint.name=Subject Name Constraint policyset.userCertSet.1.constraint.params.pattern=(UID|CN)=.* policyset.userCertSet.1.constraint.params.accept=true policyset.userCertSet.1.default.class_id=userSubjectNameDefaultImpl policyset.userCertSet.1.default.name=Subject Name Default policyset.userCertSet.1.default.params.name= policyset.userCertSet.1.default.params.dnpattern=CN=$request.testmssan$ policyset.userCertSet.1.default.params.ldap.enable=false ... policyset.userCertSet.8.constraint.class_id=noConstraintImpl policyset.userCertSet.8.constraint.name=No Constraint policyset.userCertSet.8.default.class_id=subjectAltNameExtDefaultImpl policyset.userCertSet.8.default.name=Subject Alt Name Constraint policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true policyset.userCertSet.8.default.params.subjAltNameExtCritical=true policyset.userCertSet.8.default.params.subjAltNameNumGNs=1 policyset.userCertSet.8.default.params.subjAltExtType_0=DirectoryName policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.testmssan$ ... So in the enrollment form I provided with UID testmssan ... Generic Input testmssan: cn=testmssan,ou=people,dc=example,dc=com And i got a cert issued with: Identifier: Subject Alternative Name - 2.5.29.17 Critical: yes Value: DirectoryName: CN=testmssan,OU=people,DC=example,DC=com Thanks, M. On 01/21/2013 06:58 AM, ryan.millay at gdc4s.com wrote: > > RHEL 5.8 > > Red Hat CS 8.1 > > I'm hoping this should be a relatively straight forward question and > others have run into something similar: > > When generating a certificate, is it possible to dynamically > include/not include the Subject Alt Name field based on an LDAP > parameter? When looking at the certificate profile there's a > "subjAltExtGNEnable" parameter, but I don't believe that can be set to > a request parameter, like $request.includeSAN$ for example, based on > the testing I've done. > > Assuming that the "subjAltExtGNEnable" field must be static text, > perhaps there is another work around. If included, the Subject Alt > Name in this case would represent a user's full DN. If not included, > the request parameter could be left blank and the Subject Alt Name > would be empty. Here's a little snippet from the cert profile: > > policyset.CSCertSet.7.constraint.class_id=noConstraintImpl > > policyset.CSCertSet.7.constraint.name=No Constraint > > policyset.CSCertSet.7.default.class_id=subjectAltNameExtDefaultImpl > > policyset.CSCertSet.7.default.name=Subject Alternative Name Extension > Default > > policyset.CSCertSet.7.default.params.subjAltExtGNEnable_0=true > > policyset.CSCertSet.7.default.params.subjAltExtGNEnable_1=false > > policyset.CSCertSet.7.default.params.subjAltExtGNEnable_2=false > > policyset.CSCertSet.7.default.params.subjAltExtGNEnable_3=false > > policyset.CSCertSet.7.default.params.subjAltExtGNEnable_4=false > > policyset.CSCertSet.7.default.params.subjAltExtPattern_0=$request.pkisponsordn$ > > policyset.CSCertSet.7.default.params.subjAltExtPattern_1= > > policyset.CSCertSet.7.default.params.subjAltExtPattern_2= > > policyset.CSCertSet.7.default.params.subjAltExtPattern_3= > > policyset.CSCertSet.7.default.params.subjAltExtPattern_4= > > policyset.CSCertSet.7.default.params.subjAltExtType_0=DirectoryName > > policyset.CSCertSet.7.default.params.subjAltExtType_1=RFC822Name > > policyset.CSCertSet.7.default.params.subjAltExtType_2=RFC822Name > > policyset.CSCertSet.7.default.params.subjAltExtType_3=RFC822Name > > policyset.CSCertSet.7.default.params.subjAltExtType_4=RFC822Name > > policyset.CSCertSet.7.default.params.subjAltNameExtCritical=false > > The issue that arises here is the CA fails with an IO exception from > the $request.pkisponsordn$ format. That value is a user DN, similar to > > CN=FIRSTNAME.LASTNAME, OU=ORGANIZATION, OU=ORGANIZATION2, O=COUNTRY, > C=COUNTRYCODE. The CA's debug log shows the '=' and the ',' being > escaped by backslashes. The CA then fails to populate the Subject Alt > Name due to the following error: > > SubjectAltNameExtDefault: populate java.io.IOException: Unknown AVA > keyword 'CN\'. > > Is there a way to properly escape the user DN so it can be used in the > Subject Alt Name? Again, the ultimate goal being the user DN could be > populated or not. If populated, it is included as the Subject Alt > Name. If not populated, the Subject Alt Name is left blank when the > certificate is generated. > > Thank you, > > Ryan Millay > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: