From msauton at redhat.com Thu May 1 01:25:04 2008 From: msauton at redhat.com (Marc Sauton) Date: Wed, 30 Apr 2008 18:25:04 -0700 Subject: [Pki-users] Modify Certificate Profies - include SubjectAltName In-Reply-To: References: Message-ID: <48191BF0.80007@redhat.com> Ebbe Hansen wrote: > I have succeeded adding the SubjectAltName extension - it turns out the > Policy settings in the DogTac CA is set to capture the "Requestor Email" > field while the Subject's Email field is the value that go into the 'E=' > part of the DN! > > Is this by "intend" or can/should the Profile file(s) be modified to > guarantee the email values in the DN and the SubjectAltName cannot be > different (i.e. abounding a typical user-introduced error). > The dn can be customized in a profile, e.g.: policyset.userCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.userCertSet.1.constraint.name=Subject Name Constraint policyset.userCertSet.1.constraint.params.pattern=UID=.* The SubjectAltName extension configuration in a profile has just a default value for an example which you can tune to your needs in a profile, e.g.: policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$ Profiles and the web ui can be customized. Some doc links: http://www.redhat.com/docs/manuals/cert-system/7.3/html/Administration_Guide/Certificate_Profiles-About_Certificate_Profiles.html http://www.redhat.com/docs/manuals/cert-system/7.3/html/Administration_Guide/Defaults_Reference-Subject_Alternative_Name_Extension_Default.html M. > Ebbe @ SPYRUS > > "This message and any attached documents contain SPYRUS confidential > and/or proprietary information and may be subject to privilege or exempt > from disclosure under applicable law. These materials are intended only > for the use of the intended recipient. If you are not the intended > recipient of this electronic message, you are hereby notified that any > use of this message is strictly prohibited. Delivery of this message to > any person other than the intended recipient shall not constitute any > waiver of any privilege. If you have received this message in error, > please delete this message from your system and notify the sender > immediately. Thank you." > > > -----Original Message----- > From: Marc Sauton [mailto:msauton at redhat.com] > Sent: Wednesday, April 30, 2008 10:17 AM > To: Ebbe Hansen > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] Modify Certificate Profies - include > SubjectAltName > > If in /var/lib/pki-ca/profiles/ca/caUserCert.cfg > has > policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requ > estor_email$ > policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true > and the enrollment request has an e-mail, the subject alt name extension > > field should be correctly initialized upon certificate issuance. > You may want to turn on some debug in CS.cfg > debug.enabled=true > debug.level=0 > and see your debug log for more details. > M. > > It depends how the request hadEbbe Hansen wrote: > >> Looking at the 'CAUserCert.cfg' profile (first profile on the WEB >> Agent profile-list) it appears it should trigger the inclusion of the >> "SubjectAltName" extension. I have not been successful generating any >> certicites where the SubjectAltName extension is included! >> >> In the Agents display the SubjectAltName is listed as 'Null' - even >> after editing the 'Null' to the desired RFC822 value, the issued >> certificate always comes without any SubjectAtltName extension? >> >> What can I do to get the CA to include the SubjectAltName extension? I >> > > >> am always specifying an email value in the request field! >> >> Ebbe >> >> "This message and any attached documents contain SPYRUS confidential >> and/or proprietary information and may be subject to privilege or >> exempt from disclosure under applicable law. These materials are >> intended only for the use of the intended recipient. If you are not >> the intended recipient of this electronic message, you are hereby >> notified that any use of this message is strictly prohibited. Delivery >> > > >> of this message to any person other than the intended recipient shall >> not constitute any waiver of any privilege. If you have received this >> message in error, please delete this message from your system and >> notify the sender immediately. Thank you." >> >> >> > ------------------------------------------------------------------------ > >> *From:* pki-users-bounces at redhat.com >> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Chris >> *Sent:* Wednesday, April 09, 2008 10:10 PM >> *To:* pki-users at redhat.com >> *Subject:* Re: [Pki-users] Modify Certificate Profies >> >> Thanks. That worked. >> >> On Wed, Apr 9, 2008 at 12:10 PM, Christina Fu > > wrote: >> >> Profiles can be configured in /profiles/ca. If >> you add your own new profiles, you need to modify > root>//conf/CS.cfg "profile.list" to contain the new profile name, and >> > > >> add the corresponding "class_id" and "config" (see the existing >> entries in CS.cfg as example), and restart the CA. >> >> In addition, Dogtag provides flexible plugin infrastructure that >> allows people to customize various areas. Profile is one of them. >> The standard profile related polugins code is in >> pki/base/common/src/com/netscape/cms/profile/. That's for advanced >> users who know what they are doing. Make sure the certs produced still >> > > >> comply. >> >> hope this helps. >> Christina >> >> Chris wrote: >> >> >> Sorry, hit the send by mistake.... >> >> I've succesfully installed Dogtag. The documentation was clear and I >> didn't have any issues. >> My question is in regards to customizing certificate profiles. In the >> current CA environment I manager, I deal with customizing profiles. Is >> > > >> there a way to create customized certificate profiles? >> The fields which apply are: >> CertificatePolicies >> - Policy Identifier >> - User Notice with custom text >> ExtendedKeyUsage >> - New Key Usage OID >> Also, in one profile, we've created a new field that programically >> ties to the EKU >> >> On our current CA software, a config file is modified to customize >> profiles. Also there is some DER encoding required to convert the >> appropriate text. >> >> Is this feature available? >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> > > From msauton at redhat.com Thu May 1 02:56:09 2008 From: msauton at redhat.com (Marc Sauton) Date: Wed, 30 Apr 2008 19:56:09 -0700 Subject: [Pki-users] Modify Certificate Profies - removing 'Critical' key-usage indication In-Reply-To: References: Message-ID: <48193149.8070904@redhat.com> Ebbe Hansen wrote: > While attempting to test various Email clients in a windows environment > (including Outlook Express and Outlook), I am having trouble getting the > Email client (Outlook Express) to accept the certificates generated by > the RedHat/DogTag CA. I am using the 'CAUserCert.cfg' profile and I am > adding a SubjectAltName extension as described in my earlier message. > However, I am still not successful getting the Email client to use the > DogTag user certificates for signature purposes. > > Is there a documented procedure that describes how to generate user > certificates accepted by the windows-based Outlook Express client? > > Comparing the RadHat user certificate with a Microsoft user certificate > reveals that the RedHat CA sets the 'KeyUsage' extension to 'Critical' > -- while the Microsoft CA does not! After modifying the DogTag CA > Profile ('CAUserCert.cfg') to specify a "non critical" 'KeyUsage' > extension, any new request using the modified profile fails - error > message is: > > "Sorry, your request has been rejected. The reason is "Request Rejected > - Criticality Not Matched". > I can see the error in the agent web ui > Are there multiple places I need to adjust the Profile -- so far I have > only modified the 'CAUserCert.cfg' file in the > '/profiles/ca' directory. > This should be the one place. > Ebbe @ SPYRUS > > > "This message and any attached documents contain SPYRUS confidential > and/or proprietary information and may be subject to privilege or exempt > from disclosure under applicable law. These materials are intended only > for the use of the intended recipient. If you are not the intended > recipient of this electronic message, you are hereby notified that any > use of this message is strictly prohibited. Delivery of this message to > any person other than the intended recipient shall not constitute any > waiver of any privilege. If you have received this message in error, > please delete this message from your system and notify the sender > immediately. Thank you." > > > -----Original Message----- > From: Marc Sauton [mailto:msauton at redhat.com] > Sent: Wednesday, April 30, 2008 10:17 AM > To: Ebbe Hansen > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] Modify Certificate Profies - include > SubjectAltName > > If in /var/lib/pki-ca/profiles/ca/caUserCert.cfg > has > policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requ > estor_email$ > policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true > and the enrollment request has an e-mail, the subject alt name extension > > field should be correctly initialized upon certificate issuance. > You may want to turn on some debug in CS.cfg > debug.enabled=true > debug.level=0 > and see your debug log for more details. > M. > > It depends how the request hadEbbe Hansen wrote: > >> Looking at the 'CAUserCert.cfg' profile (first profile on the WEB >> Agent profile-list) it appears it should trigger the inclusion of the >> "SubjectAltName" extension. I have not been successful generating any >> certicites where the SubjectAltName extension is included! >> >> In the Agents display the SubjectAltName is listed as 'Null' - even >> after editing the 'Null' to the desired RFC822 value, the issued >> certificate always comes without any SubjectAtltName extension? >> >> What can I do to get the CA to include the SubjectAltName extension? I >> > > >> am always specifying an email value in the request field! >> >> Ebbe >> >> "This message and any attached documents contain SPYRUS confidential >> and/or proprietary information and may be subject to privilege or >> exempt from disclosure under applicable law. These materials are >> intended only for the use of the intended recipient. If you are not >> the intended recipient of this electronic message, you are hereby >> notified that any use of this message is strictly prohibited. Delivery >> > > >> of this message to any person other than the intended recipient shall >> not constitute any waiver of any privilege. If you have received this >> message in error, please delete this message from your system and >> notify the sender immediately. Thank you." >> >> >> > ------------------------------------------------------------------------ > >> *From:* pki-users-bounces at redhat.com >> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Chris >> *Sent:* Wednesday, April 09, 2008 10:10 PM >> *To:* pki-users at redhat.com >> *Subject:* Re: [Pki-users] Modify Certificate Profies >> >> Thanks. That worked. >> >> On Wed, Apr 9, 2008 at 12:10 PM, Christina Fu > > wrote: >> >> Profiles can be configured in /profiles/ca. If >> you add your own new profiles, you need to modify > root>//conf/CS.cfg "profile.list" to contain the new profile name, and >> > > >> add the corresponding "class_id" and "config" (see the existing >> entries in CS.cfg as example), and restart the CA. >> >> In addition, Dogtag provides flexible plugin infrastructure that >> allows people to customize various areas. Profile is one of them. >> The standard profile related polugins code is in >> pki/base/common/src/com/netscape/cms/profile/. That's for advanced >> users who know what they are doing. Make sure the certs produced still >> > > >> comply. >> >> hope this helps. >> Christina >> >> Chris wrote: >> >> >> Sorry, hit the send by mistake.... >> >> I've succesfully installed Dogtag. The documentation was clear and I >> didn't have any issues. >> My question is in regards to customizing certificate profiles. In the >> current CA environment I manager, I deal with customizing profiles. Is >> > > >> there a way to create customized certificate profiles? >> The fields which apply are: >> CertificatePolicies >> - Policy Identifier >> - User Notice with custom text >> ExtendedKeyUsage >> - New Key Usage OID >> Also, in one profile, we've created a new field that programically >> ties to the EKU >> >> On our current CA software, a config file is modified to customize >> profiles. Also there is some DER encoding required to convert the >> appropriate text. >> >> Is this feature available? >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From ehansen at spyrus.com Thu May 1 16:26:56 2008 From: ehansen at spyrus.com (Ebbe Hansen) Date: Thu, 1 May 2008 09:26:56 -0700 Subject: [Pki-users] Modify Certificate Profies - removing 'Critical' key-usage indication In-Reply-To: <48193149.8070904@redhat.com> Message-ID: Pki-users support, Does your message "I can see the error in the agent web ui" indicate you were able to replicate the problem? I still do not know how to generate user certicites without the "criticality" bit set in the 'KeyUsage' extension? Ebbe -----Original Message----- From: Marc Sauton [mailto:msauton at redhat.com] Sent: Wednesday, April 30, 2008 7:56 PM To: Ebbe Hansen Cc: pki-users at redhat.com Subject: Re: [Pki-users] Modify Certificate Profies - removing 'Critical' key-usage indication Ebbe Hansen wrote: > While attempting to test various Email clients in a windows environment > (including Outlook Express and Outlook), I am having trouble getting the > Email client (Outlook Express) to accept the certificates generated by > the RedHat/DogTag CA. I am using the 'CAUserCert.cfg' profile and I am > adding a SubjectAltName extension as described in my earlier message. > However, I am still not successful getting the Email client to use the > DogTag user certificates for signature purposes. > > Is there a documented procedure that describes how to generate user > certificates accepted by the windows-based Outlook Express client? > > Comparing the RadHat user certificate with a Microsoft user certificate > reveals that the RedHat CA sets the 'KeyUsage' extension to 'Critical' > -- while the Microsoft CA does not! After modifying the DogTag CA > Profile ('CAUserCert.cfg') to specify a "non critical" 'KeyUsage' > extension, any new request using the modified profile fails - error > message is: > > "Sorry, your request has been rejected. The reason is "Request Rejected > - Criticality Not Matched". > I can see the error in the agent web ui > Are there multiple places I need to adjust the Profile -- so far I have > only modified the 'CAUserCert.cfg' file in the > '/profiles/ca' directory. > This should be the one place. > Ebbe @ SPYRUS > > > "This message and any attached documents contain SPYRUS confidential > and/or proprietary information and may be subject to privilege or exempt > from disclosure under applicable law. These materials are intended only > for the use of the intended recipient. If you are not the intended > recipient of this electronic message, you are hereby notified that any > use of this message is strictly prohibited. Delivery of this message to > any person other than the intended recipient shall not constitute any > waiver of any privilege. If you have received this message in error, > please delete this message from your system and notify the sender > immediately. Thank you." > > > -----Original Message----- > From: Marc Sauton [mailto:msauton at redhat.com] > Sent: Wednesday, April 30, 2008 10:17 AM > To: Ebbe Hansen > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] Modify Certificate Profies - include > SubjectAltName > > If in /var/lib/pki-ca/profiles/ca/caUserCert.cfg > has > policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requ > estor_email$ > policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true > and the enrollment request has an e-mail, the subject alt name extension > > field should be correctly initialized upon certificate issuance. > You may want to turn on some debug in CS.cfg > debug.enabled=true > debug.level=0 > and see your debug log for more details. > M. > > It depends how the request hadEbbe Hansen wrote: > >> Looking at the 'CAUserCert.cfg' profile (first profile on the WEB >> Agent profile-list) it appears it should trigger the inclusion of the >> "SubjectAltName" extension. I have not been successful generating any >> certicites where the SubjectAltName extension is included! >> >> In the Agents display the SubjectAltName is listed as 'Null' - even >> after editing the 'Null' to the desired RFC822 value, the issued >> certificate always comes without any SubjectAtltName extension? >> >> What can I do to get the CA to include the SubjectAltName extension? I >> > > >> am always specifying an email value in the request field! >> >> Ebbe >> >> "This message and any attached documents contain SPYRUS confidential >> and/or proprietary information and may be subject to privilege or >> exempt from disclosure under applicable law. These materials are >> intended only for the use of the intended recipient. If you are not >> the intended recipient of this electronic message, you are hereby >> notified that any use of this message is strictly prohibited. Delivery >> > > >> of this message to any person other than the intended recipient shall >> not constitute any waiver of any privilege. If you have received this >> message in error, please delete this message from your system and >> notify the sender immediately. Thank you." >> >> >> > ------------------------------------------------------------------------ > >> *From:* pki-users-bounces at redhat.com >> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Chris >> *Sent:* Wednesday, April 09, 2008 10:10 PM >> *To:* pki-users at redhat.com >> *Subject:* Re: [Pki-users] Modify Certificate Profies >> >> Thanks. That worked. >> >> On Wed, Apr 9, 2008 at 12:10 PM, Christina Fu > > wrote: >> >> Profiles can be configured in /profiles/ca. If >> you add your own new profiles, you need to modify > root>//conf/CS.cfg "profile.list" to contain the new profile name, and >> > > >> add the corresponding "class_id" and "config" (see the existing >> entries in CS.cfg as example), and restart the CA. >> >> In addition, Dogtag provides flexible plugin infrastructure that >> allows people to customize various areas. Profile is one of them. >> The standard profile related polugins code is in >> pki/base/common/src/com/netscape/cms/profile/. That's for advanced >> users who know what they are doing. Make sure the certs produced still >> > > >> comply. >> >> hope this helps. >> Christina >> >> Chris wrote: >> >> >> Sorry, hit the send by mistake.... >> >> I've succesfully installed Dogtag. The documentation was clear and I >> didn't have any issues. >> My question is in regards to customizing certificate profiles. In the >> current CA environment I manager, I deal with customizing profiles. Is >> > > >> there a way to create customized certificate profiles? >> The fields which apply are: >> CertificatePolicies >> - Policy Identifier >> - User Notice with custom text >> ExtendedKeyUsage >> - New Key Usage OID >> Also, in one profile, we've created a new field that programically >> ties to the EKU >> >> On our current CA software, a config file is modified to customize >> profiles. Also there is some DER encoding required to convert the >> appropriate text. >> >> Is this feature available? >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From cfu at redhat.com Thu May 1 18:23:19 2008 From: cfu at redhat.com (Christina Fu) Date: Thu, 01 May 2008 11:23:19 -0700 Subject: [Pki-users] Modify Certificate Profies - include SubjectAltName In-Reply-To: References: Message-ID: <481A0A97.50409@redhat.com> Ebbe Hansen wrote: > I have succeeded adding the SubjectAltName extension - it turns out the > Policy settings in the DogTac CA is set to capture the "Requestor Email" > field while the Subject's Email field is the value that go into the 'E=' > part of the DN! > > Is this by "intend" or can/should the Profile file(s) be modified to > guarantee the email values in the DN and the SubjectAltName cannot be > different (i.e. abounding a typical user-introduced error). > > Ebbe @ SPYRUS > > Hi Ebbe, I noticed that you have posted a few questions in the profile area and I intended to answer them one by one. First of all, our enrollment profile feature is a very flexible system that allows administrators to configure the enrollment pages and how certificates are produced and validated to their will (to a certain extend, of course ;-). Here is something that's not in the document that'll help you do what you want with SubjectAltName. There is an "Input" implementation called "genericInputImpl" that allows the admin to place any number of input boxes on the enrollment page, add their own parameter names, and take whatever input from the user and these input will end up in the "request." What this means is, you can then use $request.$ in things in the profile such as dnpattern, subjAltExtPattern, etc. Without going into detail on how to configure this, how about take a look of the DomainController.cfg, look specifically at input.i3 and notice how it defines "ccm" and later it refers to "$request.ccm$ in both the dnpattern and subjAltExtPattern. Go to the enrollment page and look at "Domain Controller" enrollment page and you'll see the correspondence between what's specified in the profile and what will automatically show up on the enrollment page (yes, the enrollment page is automatically configured to your specification in the profile!). Please let me know if this works for you. If you have trouble figure it out, feel free to give me a copy of your profile and I can edit it for you. Christina > "This message and any attached documents contain SPYRUS confidential > and/or proprietary information and may be subject to privilege or exempt > from disclosure under applicable law. These materials are intended only > for the use of the intended recipient. If you are not the intended > recipient of this electronic message, you are hereby notified that any > use of this message is strictly prohibited. Delivery of this message to > any person other than the intended recipient shall not constitute any > waiver of any privilege. If you have received this message in error, > please delete this message from your system and notify the sender > immediately. Thank you." > > > -----Original Message----- > From: Marc Sauton [mailto:msauton at redhat.com] > Sent: Wednesday, April 30, 2008 10:17 AM > To: Ebbe Hansen > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] Modify Certificate Profies - include > SubjectAltName > > If in /var/lib/pki-ca/profiles/ca/caUserCert.cfg > has > policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requ > estor_email$ > policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true > and the enrollment request has an e-mail, the subject alt name extension > > field should be correctly initialized upon certificate issuance. > You may want to turn on some debug in CS.cfg > debug.enabled=true > debug.level=0 > and see your debug log for more details. > M. > > It depends how the request hadEbbe Hansen wrote: > >> Looking at the 'CAUserCert.cfg' profile (first profile on the WEB >> Agent profile-list) it appears it should trigger the inclusion of the >> "SubjectAltName" extension. I have not been successful generating any >> certicites where the SubjectAltName extension is included! >> >> In the Agents display the SubjectAltName is listed as 'Null' - even >> after editing the 'Null' to the desired RFC822 value, the issued >> certificate always comes without any SubjectAtltName extension? >> >> What can I do to get the CA to include the SubjectAltName extension? I >> > > >> am always specifying an email value in the request field! >> >> Ebbe >> >> "This message and any attached documents contain SPYRUS confidential >> and/or proprietary information and may be subject to privilege or >> exempt from disclosure under applicable law. These materials are >> intended only for the use of the intended recipient. If you are not >> the intended recipient of this electronic message, you are hereby >> notified that any use of this message is strictly prohibited. Delivery >> > > >> of this message to any person other than the intended recipient shall >> not constitute any waiver of any privilege. If you have received this >> message in error, please delete this message from your system and >> notify the sender immediately. Thank you." >> >> >> > ------------------------------------------------------------------------ > >> *From:* pki-users-bounces at redhat.com >> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Chris >> *Sent:* Wednesday, April 09, 2008 10:10 PM >> *To:* pki-users at redhat.com >> *Subject:* Re: [Pki-users] Modify Certificate Profies >> >> Thanks. That worked. >> >> On Wed, Apr 9, 2008 at 12:10 PM, Christina Fu > > wrote: >> >> Profiles can be configured in /profiles/ca. If >> you add your own new profiles, you need to modify > root>//conf/CS.cfg "profile.list" to contain the new profile name, and >> > > >> add the corresponding "class_id" and "config" (see the existing >> entries in CS.cfg as example), and restart the CA. >> >> In addition, Dogtag provides flexible plugin infrastructure that >> allows people to customize various areas. Profile is one of them. >> The standard profile related polugins code is in >> pki/base/common/src/com/netscape/cms/profile/. That's for advanced >> users who know what they are doing. Make sure the certs produced still >> > > >> comply. >> >> hope this helps. >> Christina >> >> Chris wrote: >> >> >> Sorry, hit the send by mistake.... >> >> I've succesfully installed Dogtag. The documentation was clear and I >> didn't have any issues. >> My question is in regards to customizing certificate profiles. In the >> current CA environment I manager, I deal with customizing profiles. Is >> > > >> there a way to create customized certificate profiles? >> The fields which apply are: >> CertificatePolicies >> - Policy Identifier >> - User Notice with custom text >> ExtendedKeyUsage >> - New Key Usage OID >> Also, in one profile, we've created a new field that programically >> ties to the EKU >> >> On our current CA software, a config file is modified to customize >> profiles. Also there is some DER encoding required to convert the >> appropriate text. >> >> Is this feature available? >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From cfu at redhat.com Thu May 1 18:59:23 2008 From: cfu at redhat.com (Christina Fu) Date: Thu, 01 May 2008 11:59:23 -0700 Subject: [Pki-users] Modify Certificate Profies - removing 'Critical' key-usage indication In-Reply-To: References: Message-ID: <481A130B.6060509@redhat.com> Hi Ebbe, Two major lists of items in an enrollment profile are the "default" and "constraint." They correspond to each other and are tied in by the same set name and id. e.g. policyset.userCertSet.6.default.params.keyUsageCritical=true for default, would have a corresponding constraint: policyset.userCertSet.6.constraint.params.keyUsageCritical=true What the above example shows is, by default, the keyUsageCritical is true, and when it is run through the constraint for validation, it expects it to be true. If you want it to be "false," then you'll need to change the constraint value to be "false." Here is the doc that describes the default fields for Key Usage Extension: http://www.redhat.com/docs/manuals/cert-system/7.3/html/Administration_Guide/Defaults_Reference-Key_Usage_Extension_Default.html Here is the doc that describes the constraint fields for Key Usage Extension: If you don't care about the values (no validation), then you need to specifically set no constraint: e.g. policyset.userCertSet.7.constraint.class_id=noConstraintImpl policyset.userCertSet.7.constraint.name=No Constraint ... Hope this helps. Christina Ebbe Hansen wrote: > While attempting to test various Email clients in a windows environment > (including Outlook Express and Outlook), I am having trouble getting the > Email client (Outlook Express) to accept the certificates generated by > the RedHat/DogTag CA. I am using the 'CAUserCert.cfg' profile and I am > adding a SubjectAltName extension as described in my earlier message. > However, I am still not successful getting the Email client to use the > DogTag user certificates for signature purposes. > > Is there a documented procedure that describes how to generate user > certificates accepted by the windows-based Outlook Express client? > > Comparing the RadHat user certificate with a Microsoft user certificate > reveals that the RedHat CA sets the 'KeyUsage' extension to 'Critical' > -- while the Microsoft CA does not! After modifying the DogTag CA > Profile ('CAUserCert.cfg') to specify a "non critical" 'KeyUsage' > extension, any new request using the modified profile fails - error > message is: > > "Sorry, your request has been rejected. The reason is "Request Rejected > - Criticality Not Matched". > > Are there multiple places I need to adjust the Profile -- so far I have > only modified the 'CAUserCert.cfg' file in the > '/profiles/ca' directory. > > Ebbe @ SPYRUS > > > "This message and any attached documents contain SPYRUS confidential > and/or proprietary information and may be subject to privilege or exempt > from disclosure under applicable law. These materials are intended only > for the use of the intended recipient. If you are not the intended > recipient of this electronic message, you are hereby notified that any > use of this message is strictly prohibited. Delivery of this message to > any person other than the intended recipient shall not constitute any > waiver of any privilege. If you have received this message in error, > please delete this message from your system and notify the sender > immediately. Thank you." > > > -----Original Message----- > From: Marc Sauton [mailto:msauton at redhat.com] > Sent: Wednesday, April 30, 2008 10:17 AM > To: Ebbe Hansen > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] Modify Certificate Profies - include > SubjectAltName > > If in /var/lib/pki-ca/profiles/ca/caUserCert.cfg > has > policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requ > estor_email$ > policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true > and the enrollment request has an e-mail, the subject alt name extension > > field should be correctly initialized upon certificate issuance. > You may want to turn on some debug in CS.cfg > debug.enabled=true > debug.level=0 > and see your debug log for more details. > M. > > It depends how the request hadEbbe Hansen wrote: > >> Looking at the 'CAUserCert.cfg' profile (first profile on the WEB >> Agent profile-list) it appears it should trigger the inclusion of the >> "SubjectAltName" extension. I have not been successful generating any >> certicites where the SubjectAltName extension is included! >> >> In the Agents display the SubjectAltName is listed as 'Null' - even >> after editing the 'Null' to the desired RFC822 value, the issued >> certificate always comes without any SubjectAtltName extension? >> >> What can I do to get the CA to include the SubjectAltName extension? I >> > > >> am always specifying an email value in the request field! >> >> Ebbe >> >> "This message and any attached documents contain SPYRUS confidential >> and/or proprietary information and may be subject to privilege or >> exempt from disclosure under applicable law. These materials are >> intended only for the use of the intended recipient. If you are not >> the intended recipient of this electronic message, you are hereby >> notified that any use of this message is strictly prohibited. Delivery >> > > >> of this message to any person other than the intended recipient shall >> not constitute any waiver of any privilege. If you have received this >> message in error, please delete this message from your system and >> notify the sender immediately. Thank you." >> >> >> > ------------------------------------------------------------------------ > >> *From:* pki-users-bounces at redhat.com >> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Chris >> *Sent:* Wednesday, April 09, 2008 10:10 PM >> *To:* pki-users at redhat.com >> *Subject:* Re: [Pki-users] Modify Certificate Profies >> >> Thanks. That worked. >> >> On Wed, Apr 9, 2008 at 12:10 PM, Christina Fu > > wrote: >> >> Profiles can be configured in /profiles/ca. If >> you add your own new profiles, you need to modify > root>//conf/CS.cfg "profile.list" to contain the new profile name, and >> > > >> add the corresponding "class_id" and "config" (see the existing >> entries in CS.cfg as example), and restart the CA. >> >> In addition, Dogtag provides flexible plugin infrastructure that >> allows people to customize various areas. Profile is one of them. >> The standard profile related polugins code is in >> pki/base/common/src/com/netscape/cms/profile/. That's for advanced >> users who know what they are doing. Make sure the certs produced still >> > > >> comply. >> >> hope this helps. >> Christina >> >> Chris wrote: >> >> >> Sorry, hit the send by mistake.... >> >> I've succesfully installed Dogtag. The documentation was clear and I >> didn't have any issues. >> My question is in regards to customizing certificate profiles. In the >> current CA environment I manager, I deal with customizing profiles. Is >> > > >> there a way to create customized certificate profiles? >> The fields which apply are: >> CertificatePolicies >> - Policy Identifier >> - User Notice with custom text >> ExtendedKeyUsage >> - New Key Usage OID >> Also, in one profile, we've created a new field that programically >> ties to the EKU >> >> On our current CA software, a config file is modified to customize >> profiles. Also there is some DER encoding required to convert the >> appropriate text. >> >> Is this feature available? >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From aleksander.adamowski at altkom.pl Thu May 15 17:48:57 2008 From: aleksander.adamowski at altkom.pl (Aleksander Adamowski) Date: Thu, 15 May 2008 19:48:57 +0200 Subject: [Pki-users] Anybody got dual kay certs and key archiving working with Dogtag? Message-ID: <482C7789.6000202@altkom.pl> Hi! I've set up pki-ca, pki-ocsp, pki-ra and pki-kra. However, it seems that pki-kra doesn't archive any keys. I've tested it with the following profiles when issuing certificates: Using the CA instance: * caUserCert (Manual User Dual-Use Certificate Enrollment) - I know, it won't work, it's Dual-Use, not Dual-Key. However, the protocol used is CRMF. * caDirUserCert (Directory-Authenticated User Dual-Use Certificate Enrollment) - another Dual-Use, not Dual-Key. But CRMF-based. * caDualRAuserCert (RA Agent-Authenticated User Certificate Enrollment) - they don't write what "Dual" means here. Is it Dual-Use too? Using the RA instance: * caDualRAuserCert (RA Agent-Authenticated User Certificate Enrollment) - it has "Dual" in its name... So it seems that there's potential confusion over which "Dual" is implied in the profile names (does it correspond to key usage, or the amount of keys?). Based on my experiments, either all those profiles are single key, or my client doesn't support dual key generation (it's Firefox 3 nightly build). So the question is - what combination of certificate profiles and client (web browser) versions allows for generating dual key certificates whose keys will be correctly archived by KRA/DRM? -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl -- Aleksander Adamowski Administrator system?w korporacyjnych; Instruktor Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Ch?odna 51 tel. brak kom. +48 601-318-080 S?d Rejonowy dla m.st. Warszawy w Warszawie, XII Wydzia? Gospodarczy Krajowego Rejestru S?dowego, KRS: 0000120139, NIP 118-00-08-391, Kapita? zak?adowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomo?? zawiera informacje zastrze?one i stanowi?ce tajemnic? przedsi?biorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do w?asnych cel?w jest zabronione. Je?eli otrzymali?cie Pa?stwo niniejsz? wiadomo?? omy?kowo, prosimy o niezw?oczne skontaktowanie si? z nadawc? oraz usuni?cie wszelkich kopii niniejszej wiadomo?ci. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message. From cfu at redhat.com Thu May 15 18:46:29 2008 From: cfu at redhat.com (Christina Fu) Date: Thu, 15 May 2008 11:46:29 -0700 Subject: [Pki-users] Anybody got dual kay certs and key archiving working with Dogtag? In-Reply-To: <482C7789.6000202@altkom.pl> References: <482C7789.6000202@altkom.pl> Message-ID: <482C8505.4050105@redhat.com> There could be multiple issues. First thing you want to check is whether your ca is configured correctly with connection to KRA. To check this, look into your CS.cfg file in /conf/CS.cfg, and look for CA.connector.KRA.enable=true If it's not there, or is false, then you probably did not set it up correctly. There are several other parameters there that were supposed to be added automatically during installation, if you had picked the right options. If you missed, you can reinstall again. If your KRA is set up correctly, then test it out with caDualCert.cfg, which will generate a signing cert and an encryption cert for you. The encryption cert is the one whose private key will be archived. hope this helps, Christina Aleksander Adamowski wrote: > Hi! > > I've set up pki-ca, pki-ocsp, pki-ra and pki-kra. > > However, it seems that pki-kra doesn't archive any keys. > > I've tested it with the following profiles when issuing certificates: > > Using the CA instance: > * caUserCert (Manual User Dual-Use Certificate Enrollment) - I know, > it won't work, it's Dual-Use, not Dual-Key. However, the protocol used > is CRMF. > * caDirUserCert (Directory-Authenticated User Dual-Use Certificate > Enrollment) - another Dual-Use, not Dual-Key. But CRMF-based. > * caDualRAuserCert (RA Agent-Authenticated User Certificate > Enrollment) - they don't write what "Dual" means here. Is it Dual-Use > too? > > Using the RA instance: > * caDualRAuserCert (RA Agent-Authenticated User Certificate > Enrollment) - it has "Dual" in its name... > > > So it seems that there's potential confusion over which "Dual" is > implied in the profile names (does it correspond to key usage, or the > amount of keys?). > > Based on my experiments, either all those profiles are single key, or > my client doesn't support dual key generation (it's Firefox 3 nightly > build). > > > > So the question is - what combination of certificate profiles and > client (web browser) versions allows for generating dual key > certificates whose keys will be correctly archived by KRA/DRM? > > > From aleksander.adamowski.dogtag at altkom.pl Fri May 16 10:08:50 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Fri, 16 May 2008 12:08:50 +0200 Subject: [Pki-users] Anybody got dual kay certs and key archiving working with Dogtag? In-Reply-To: <482C8505.4050105@redhat.com> References: <482C7789.6000202@altkom.pl> <482C8505.4050105@redhat.com> Message-ID: <482D5D32.3030803@altkom.pl> Christina Fu wrote: > There could be multiple issues. > > First thing you want to check is whether your ca is configured > correctly with connection to KRA. To check this, look into your > CS.cfg file in /conf/CS.cfg, and look for > CA.connector.KRA.enable=true I've already checked that, it's there. Also, in pkiconsole for the CA instance, I can see "Data Recovery Manager Connector" in "Certificate Manager" -> "Connectors". When I click "Edit", and check its configuration, it corresponds to the configuration of the pki-kra instance (port number etc.). > > If your KRA is set up correctly, then test it out with caDualCert.cfg, > which will generate a signing cert and an encryption cert for you. > The encryption cert is the one whose private key will be archived. OK, this is what I was looking for! When I use the caDualCert profile, the browser asks me for confirmation/permisson for the CA to make a backup of my encryption private key - here's a screenshot of how it looks like: https://olo.org.pl/files/pki/encryption_key_copy.png Then I can see that _two_ key generation progress dialogs are displayed consecutively. So two keys and CSRs are indeed generated, and two certificate requests are added to the CA's request queue. The remaining question I have is - can I customise the LDAP-based enrollment profile (caDirUserCert) to generate dual keys just like caDualCert does? -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From msauton at redhat.com Fri May 16 17:09:49 2008 From: msauton at redhat.com (Marc Sauton) Date: Fri, 16 May 2008 10:09:49 -0700 Subject: [Pki-users] Anybody got dual kay certs and key archiving working with Dogtag? In-Reply-To: <482D5D32.3030803@altkom.pl> References: <482C7789.6000202@altkom.pl> <482C8505.4050105@redhat.com> <482D5D32.3030803@altkom.pl> Message-ID: <482DBFDD.6080901@redhat.com> Aleksander Adamowski wrote: > Christina Fu wrote: >> There could be multiple issues. >> >> First thing you want to check is whether your ca is configured >> correctly with connection to KRA. To check this, look into your >> CS.cfg file in /conf/CS.cfg, and look for >> CA.connector.KRA.enable=true > I've already checked that, it's there. Also, in pkiconsole for the CA > instance, I can see "Data Recovery Manager Connector" in "Certificate > Manager" -> "Connectors". > > When I click "Edit", and check its configuration, it corresponds to > the configuration of the pki-kra instance (port number etc.). > >> >> If your KRA is set up correctly, then test it out with >> caDualCert.cfg, which will generate a signing cert and an encryption >> cert for you. The encryption cert is the one whose private key will >> be archived. > OK, this is what I was looking for! > > When I use the caDualCert profile, the browser asks me for > confirmation/permisson for the CA to make a backup of my encryption > private key - here's a screenshot of how it looks like: > https://olo.org.pl/files/pki/encryption_key_copy.png > > Then I can see that _two_ key generation progress dialogs are > displayed consecutively. So two keys and CSRs are indeed generated, > and two certificate requests are added to the CA's request queue. > That's correct. > The remaining question I have is - can I customise the LDAP-based > enrollment profile (caDirUserCert) to generate dual keys just like > caDualCert does? > Yes, all the pages are customizable, with templates, see for example: /var/lib/pki-/webapps/ca/ee/ca/ and DirUserEnroll.html Also: http://www.redhat.com/docs/manuals/cert-system/7.3/html/Administration_Guide/Administration_Guide-Setting_up_Certificate_Profiles-Customizing_the_Enrollment_Form.html M. From aleksander.adamowski.dogtag at altkom.pl Thu May 22 13:54:04 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Thu, 22 May 2008 15:54:04 +0200 Subject: [Pki-users] Anybody got dual kay certs and key archiving working with Dogtag? In-Reply-To: <482DBFDD.6080901@redhat.com> References: <482C7789.6000202@altkom.pl> <482C8505.4050105@redhat.com> <482D5D32.3030803@altkom.pl> <482DBFDD.6080901@redhat.com> Message-ID: <48357AFC.1060604@altkom.pl> Marc Sauton wrote: >> The remaining question I have is - can I customise the LDAP-based >> enrollment profile (caDirUserCert) to generate dual keys just like >> caDualCert does? >> > Yes, all the pages are customizable, with templates, see for example: > /var/lib/pki-/webapps/ca/ee/ca/ > and > DirUserEnroll.html > Also: > http://www.redhat.com/docs/manuals/cert-system/7.3/html/Administration_Guide/Administration_Guide-Setting_up_Certificate_Profiles-Customizing_the_Enrollment_Form.html > > M. Thanks for the hint! However, it wasn't what I were looking for. Note that I wanted to customise the enrollment *profile*, not *page*. I had a look at DirUserEnroll.html and decided that customising it won't probably allow me to implement directory-populated dual certs since they require a new profile on the CA server and the page is static, so it's executed purely on the client. Even if my browser did submit dual certificate request, it wouldnt have a corresponding profile on the server. Also, analysing a spaghetti of VBScript and old Netscape-specific JS didn't seem inspiring. Instead, I've figured out that it's sufficient to modify certificate profiles (placed /var/lib/pki-/profiles/ca/) and register the changes in /etc/pki-/CS.cfg. So I've made a copy caDualCert.cfg named caDualDirUserCert.cfg and made some changes inspired by caDirUserCert.cfg. In other words, I did a semantic merge of caDualCert.cfg and caDirUserCert.cfg. Here's the unified diff describing the changes (may get messed up by my automatic line wrap, so I'm also sending it as an attachment): --- caDualCert.cfg 2008-05-09 14:40:09.000000000 +0200 +++ caDualDirUserCert.cfg 2008-05-22 14:12:47.000000000 +0200 @@ -1,13 +1,11 @@ -desc=This certificate profile is for enrolling dual user certificates. It works only with Netscape 7.0 or later. +desc=This certificate profile is for enrolling dual user certificates (encryption/signing certificate pairs) with directory-based authentication. visible=true enable=true enableBy=admin -name=Manual User Signing & Encryption Certificates Enrollment -auth.class_id= -input.list=i1,i2,i3 +name=Directory-Authenticated User Dual-key Certificate Enrollment +auth.instance_id=UserDirEnrollment +input.list=i1 input.i1.class_id=dualKeyGenInputImpl -input.i2.class_id=subjectNameInputImpl -input.i3.class_id=submitterInfoInputImpl output.list=o1 output.o1.class_id=certOutputImpl policyset.list=encryptionCertSet,signingCertSet @@ -16,7 +14,7 @@ policyset.encryptionCertSet.1.constraint.name=Subject Name Constraint policyset.encryptionCertSet.1.constraint.params.pattern=UID=.* policyset.encryptionCertSet.1.constraint.params.accept=true -policyset.encryptionCertSet.1.default.class_id=userSubjectNameDefaultImpl +policyset.encryptionCertSet.1.default.class_id=authTokenSubjectNameDefaultImpl policyset.encryptionCertSet.1.default.name=Subject Name Default policyset.encryptionCertSet.1.default.params.name= policyset.encryptionCertSet.2.constraint.class_id=validityConstraintImpl @@ -85,7 +83,7 @@ policyset.encryptionCertSet.8.default.name=Subject Alt Name Constraint policyset.encryptionCertSet.8.default.params.subjAltNameExtCritical=false policyset.encryptionCertSet.8.default.params.subjAltExtType_0=RFC822Name -policyset.encryptionCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$ +policyset.encryptionCertSet.8.default.params.subjAltExtPattern_0=$request.auth_token.mail[0]$ policyset.encryptionCertSet.8.default.params.subjAltExtGNEnable_0=true policyset.encryptionCertSet.8.default.params.subjAltNameNumGNs=1 policyset.encryptionCertSet.9.constraint.class_id=signingAlgConstraintImpl @@ -99,7 +97,7 @@ policyset.signingCertSet.1.constraint.name=Subject Name Constraint policyset.signingCertSet.1.constraint.params.pattern=UID=.* policyset.signingCertSet.1.constraint.params.accept=true -policyset.signingCertSet.1.default.class_id=userSubjectNameDefaultImpl +policyset.signingCertSet.1.default.class_id=authTokenSubjectNameDefaultImpl policyset.signingCertSet.1.default.name=Subject Name Default policyset.signingCertSet.1.default.params.name= policyset.signingCertSet.2.constraint.class_id=validityConstraintImpl @@ -158,7 +156,7 @@ policyset.signingCertSet.8.default.name=Subject Alt Name Constraint policyset.signingCertSet.8.default.params.subjAltNameExtCritical=false policyset.signingCertSet.8.default.params.subjAltExtType_0=RFC822Name -policyset.signingCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$ +policyset.signingCertSet.8.default.params.subjAltExtPattern_0=$request.auth_token.mail[0]$ policyset.signingCertSet.8.default.params.subjAltExtGNEnable_0=true policyset.signingCertSet.8.default.params.subjAltNameNumGNs=1 policyset.signingCertSet.9.constraint.class_id=signingAlgConstraintImpl Registering a new profile requires corresponding changes in CS.cfg: Index: CS.cfg =================================================================== --- CS.cfg (revision 983) +++ CS.cfg (revision 985) @@ -781,7 +781,7 @@ oidmap.subject_info_access.class=netscape.security.extensions.SubjectInfoAccessExtension oidmap.subject_info_access.oid=1.3.6.1.5.5.7.1.11 os.userid=nobody -profile.list=caUserCert,caDualCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caOtherCert,caCACert,caInstallCACert,caRACert,caOCSPCert,caTransportCert,caDirUserCert,caAgentServerCert,caAgentFileSigning,caCMCUserCert,caFullCMCUserCert,caSimpleCMCUserCert,caTokenDeviceKeyEnrollment,caTokenUserEncryptionKeyEnrollment,caTokenUserSigningKeyEnrollment,caTempTokenDeviceKeyEnrollment,caTempTokenUserEncryptionKeyEnrollment,caTempTokenUserSigningKeyEnrollment,caAdminCert,caInternalAuthServerCert,caInternalAuthTransportCert,caInternalAuthDRMstorageCert,caInternalAuthSubsystemCert,caInternalAuthOCSPCert,DomainController,caDualRAuserCert,caRAagentCert,caRAserverCert +profile.list=caDualDirUserCert profile.DomainController.class_id=caEnrollImpl profile.DomainController.config=/var/lib/pki-ca/profiles/ca/DomainController.cfg profile.caAdminCert.class_id=caEnrollImpl @@ -852,6 +852,8 @@ profile.caTransportCert.config=/var/lib/pki-ca/profiles/ca/caTransportCert.cfg profile.caUserCert.class_id=caEnrollImpl profile.caUserCert.config=/var/lib/pki-ca/profiles/ca/caUserCert.cfg +profile.caDualDirUserCert.class_id=caEnrollImpl +profile.caDualDirUserCert.config=/var/lib/pki-ca/profiles/ca/caDualDirUserCert.cfg registry.file=/var/lib/pki-ca/conf/registry.cfg request.assignee.enable=true securitydomain.flushinterval=86400000 Note that additionally I've removed all the other profiles from the list and left only my profile as active (profile.list=caDualDirUserCert). You may not want to do this in your case. After restarting pki-ca instance, I can visit https://CA_SERVER:9443/ca/ee/ca/profileList and I can see only my new profile. Then I can visit https://CA_SERVER:9443/ca/ee/ca/profileSelect?profileId=caDualDirUserCert and, as expected, I have a LDAP directory-based authentication form and the generated certificate will be dual: =============== Authentication - LDAP UID & Password Authentication This plugin authenticates the username and password provided by the user against an LDAP directory. It works with the Dir-Based Enrollment HTML form. # LDAP User ID [ ] # LDAP User Password [ ] Inputs Dual Key Generation # Key Generation Request Type crmf # Key Generation Request 1024 (Encryption), 1024 (Signing) =============== This is exactly what I were trying to accomplish. BTW, this procedure deserves a detailed documentation on http://www.redhat.com/docs/manuals/cert-system/. I've also found a problem with generating subject names from LDAP, but this is a different, unrelated story, so I'll post it as a new thread. Thanks for your suggestions! -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: caDualCert-caDualDirUserCert.cfg.patch Type: text/x-diff Size: 3232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: adding_caDualDirUserCert_profile_to_CS.cfg.patch Type: text/x-diff Size: 1668 bytes Desc: not available URL: From aleksander.adamowski.dogtag at altkom.pl Thu May 22 14:14:22 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Thu, 22 May 2008 16:14:22 +0200 Subject: [Pki-users] Does AuthTokenSubjectNameDefault plugin derive SubjectName incorrectly? Message-ID: <48357FBE.1030803@altkom.pl> Hi! I've noticed that with out LDAP directory, using the caDirUserCert profile, we get incorrect SubjectNames - they aren't populated with requesting users' commonName (cn) or e-mail (LDAP "mail" -> x.509 "E"). After closer inspection and brief analysis of Dogtag Certificate System's source code I've identified that the authTokenSubjectNameDefaultImpl plugin is responsible for this task and its implementation is in the AuthTokenSubjectNameDefault class (https://pki.fedoraproject.org/svn/pki/trunk/pki/base/common/src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java). The problem seems to be in this code fragment (line 134): X500Name name = new X500Name( request.getExtDataInString(IProfileAuthenticator.AUTHENTICATED_NAME)); The plug-in uses the $request.authenticatedname$ value from the request, which contains the authenticated user's DN. If the DN doesn't contain the cn and mail attribute, those attributed won't be propagated to resulting certificate's subject name. I think this plugin should use the $request.auth_token.tokencertsubject$ value. After all, the UidPwdDiraAuth plugin's documentation (http://www.redhat.com/docs/manuals/cert-system/pdf/cms601plugin.pdf) implies that this value will be used to formulate the certificate's subject name: "dnpattern: Specifies a string representing a subject name pattern to formulate from the directory attributes and entry DN." So the code should probably be change to something like this: Index: src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java =================================================================== --- src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java (revision 47) +++ src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java (working copy) @@ -131,7 +131,7 @@ // to the certinfo try { X500Name name = new X500Name( - request.getExtDataInString(IProfileAuthenticator.AUTHENTICATED_NAME)); + request.getExtDataInAuthToken(AuthToken.TOKEN_CERT_SUBJECT)); info.set(X509CertInfo.SUBJECT, new CertificateSubjectName(name)); } catch (Exception e) { (note: I didn't test whether it works, I'd have to check out the whole >130MB SVN repository and set up the complex Dogtag build infrastructure for this...) What you think? -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From aleksander.adamowski.dogtag at altkom.pl Thu May 22 14:18:10 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Thu, 22 May 2008 16:18:10 +0200 Subject: [Pki-users] What happened to Netscape Certificate Management System Plug-Ins Guide? Message-ID: <483580A2.2090802@altkom.pl> Hi! I can see that the complete documentation to old Netscape releases of the Certificate System is published on Red Hat's site, including the Plug-Ins Guide (unfortunately in PDF form only): http://www.redhat.com/docs/manuals/cert-system/pdf/cms601plugin.pdf However, for the newer Red Hat's releases there's no Plug-Ins Guide anymore: http://www.redhat.com/docs/manuals/cert-system/ Why has the Plug-Ins Guide been discontinued? I find it to be quite useful. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From aleksander.adamowski.dogtag at altkom.pl Thu May 22 14:20:12 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Thu, 22 May 2008 16:20:12 +0200 Subject: [Pki-users] What happened to Netscape Certificate Management System Plug-Ins Guide? In-Reply-To: <483580A2.2090802@altkom.pl> References: <483580A2.2090802@altkom.pl> Message-ID: <4835811C.6080109@altkom.pl> Aleksander Adamowski wrote: > Hi! > > I can see that the complete documentation to old Netscape releases of > the Certificate System is published on Red Hat's site, including the > Plug-Ins Guide (unfortunately in PDF form only): > > http://www.redhat.com/docs/manuals/cert-system/pdf/cms601plugin.pdf > > However, for the newer Red Hat's releases there's no Plug-Ins Guide > anymore: > http://www.redhat.com/docs/manuals/cert-system/ > > Why has the Plug-Ins Guide been discontinued? I find it to be quite > useful. > BTW I sometimes find the Sun's fork's documentation to be useful and contain information that Red Hat's docs lack, e.g.: http://docs.sun.com/source/816-5531-10/auth_plu.htm -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From bob.lord at gmail.com Thu May 22 15:44:50 2008 From: bob.lord at gmail.com (Bob Lord) Date: Thu, 22 May 2008 08:44:50 -0700 Subject: [Pki-users] Does AuthTokenSubjectNameDefault plugin derive SubjectName incorrectly? In-Reply-To: <48357FBE.1030803@altkom.pl> References: <48357FBE.1030803@altkom.pl> Message-ID: Hi Aleksander, Can you file a bug report and include that patch as an attachment? If you need help, please let me know. Regards, -Bob On Thu, May 22, 2008 at 7:14 AM, Aleksander Adamowski wrote: > Hi! > > I've noticed that with out LDAP directory, using the caDirUserCert profile, > we get incorrect SubjectNames - they aren't populated with requesting users' > commonName (cn) or e-mail (LDAP "mail" -> x.509 "E"). > > After closer inspection and brief analysis of Dogtag Certificate System's > source code I've identified that the authTokenSubjectNameDefaultImpl plugin > is responsible for this task and its implementation is in the > AuthTokenSubjectNameDefault class ( > https://pki.fedoraproject.org/svn/pki/trunk/pki/base/common/src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java > ). > > The problem seems to be in this code fragment (line 134): > > X500Name name = new X500Name( > request.getExtDataInString(IProfileAuthenticator.AUTHENTICATED_NAME)); > > The plug-in uses the $request.authenticatedname$ value from the request, > which contains the authenticated user's DN. If the DN doesn't contain the cn > and mail attribute, those attributed won't be propagated to resulting > certificate's subject name. > > I think this plugin should use the $request.auth_token.tokencertsubject$ > value. > After all, the UidPwdDiraAuth plugin's documentation ( > http://www.redhat.com/docs/manuals/cert-system/pdf/cms601plugin.pdf) > implies that this value will be used to formulate the certificate's subject > name: > > "dnpattern: Specifies a string representing a subject name pattern to > formulate from the > directory attributes and entry DN." > > So the code should probably be change to something like this: > > Index: src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java > =================================================================== > --- src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java > (revision 47) > +++ src/com/netscape/cms/profile/def/AuthTokenSubjectNameDefault.java > (working copy) > @@ -131,7 +131,7 @@ > // to the certinfo > try { > X500Name name = new X500Name( > - > request.getExtDataInString(IProfileAuthenticator.AUTHENTICATED_NAME)); > + > request.getExtDataInAuthToken(AuthToken.TOKEN_CERT_SUBJECT)); > > info.set(X509CertInfo.SUBJECT, new > CertificateSubjectName(name)); > } catch (Exception e) { > > > (note: I didn't test whether it works, I'd have to check out the whole > >130MB SVN repository and set up the complex Dogtag build infrastructure for > this...) > > What you think? > > -- > Best Regards, > Aleksander Adamowski > GG#: 274614 > ICQ UIN: 19780575 http://olo.org.pl > > _______________________________________________ > 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: From aleksander.adamowski.dogtag at altkom.pl Fri May 23 10:32:37 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Fri, 23 May 2008 12:32:37 +0200 Subject: [Pki-users] Does AuthTokenSubjectNameDefault plugin derive SubjectName incorrectly? In-Reply-To: References: <48357FBE.1030803@altkom.pl> Message-ID: <48369D45.6000604@altkom.pl> Bob Lord wrote: > Hi Aleksander, > > Can you file a bug report and include that patch as an attachment? Sure: https://bugzilla.redhat.com/show_bug.cgi?id=448005 -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From aleksander.adamowski.dogtag at altkom.pl Fri May 23 14:27:13 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Fri, 23 May 2008 16:27:13 +0200 Subject: [Pki-users] Does AuthTokenSubjectNameDefault plugin derive SubjectName incorrectly? In-Reply-To: <48369D45.6000604@altkom.pl> References: <48357FBE.1030803@altkom.pl> <48369D45.6000604@altkom.pl> Message-ID: <4836D441.5070305@altkom.pl> Aleksander Adamowski wrote: > Sure: > https://bugzilla.redhat.com/show_bug.cgi?id=448005 Just for the record, I've made a patch that actually works and has been tested for your testing pleasure, it's attached in the Bugzilla bug and I'm attaching it here just in case. There's one gotcha: since with this patch applied the subjectName generation started working properly, the old default configuration for certificate profiles will reject the certificates because they expect the incorrect subject name (userDN - based). Now you'll have to customise the LDAP-based certificate profiles to accomodate this - notably the "Subject Name Constraint". Dogtag's default profile had the following subject name constraint pattern: UID=.* While the subjectNames generated by UidPwdDirAuth plugin looks more like this by default: "E=$attr.mail, CN=$attr.cn, O=$dn.o, C=$dn.c" so they won't ever match the constraint's pattern since they cannot possibly begin with "UID=". In my configuration, I've changed the pattern to this and then the new LDAP-based subject names got accepted: .*CN=.* So in short, my caDirUserCert.cfg has the following now: ... policyset.userCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.userCertSet.1.constraint.name=Subject Name Constraint policyset.userCertSet.1.constraint.params.pattern=.*CN=.* policyset.userCertSet.1.constraint.params.accept=true ... instead of the official default: ... policyset.userCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.userCertSet.1.constraint.name=Subject Name Constraint policyset.userCertSet.1.constraint.params.pattern=UID=.* policyset.userCertSet.1.constraint.params.accept=true ... -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: AuthTokenSubjectNameDefault-fix2.patch Type: text/x-diff Size: 2202 bytes Desc: not available URL: From aleksander.adamowski.dogtag at altkom.pl Mon May 26 12:17:24 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Mon, 26 May 2008 14:17:24 +0200 Subject: [Pki-users] SELinux policy for dogtag? Message-ID: <483AAA54.1030206@altkom.pl> Hi! Did anyone try to have a shot at creating a SELinux policy for dogtag certificate system? -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From aleksander.adamowski.dogtag at altkom.pl Mon May 26 12:20:58 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Mon, 26 May 2008 14:20:58 +0200 Subject: [Pki-users] SELinux policy for dogtag? In-Reply-To: <483AAA54.1030206@altkom.pl> References: <483AAA54.1030206@altkom.pl> Message-ID: <483AAB2A.4080600@altkom.pl> Aleksander Adamowski wrote: > Did anyone try to have a shot at creating a SELinux policy for dogtag > certificate system? BTW, yes, I've noticed the http://pki.fedoraproject.org/wiki/PKI_TechNote_SE_Linux page. The problem is that the link has been lost in translation of some internal documentation to Wiki: "The current policy files are located here TBD" - there's no hyperlink to the files. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From aleksander.adamowski.dogtag at altkom.pl Mon May 26 12:38:13 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Mon, 26 May 2008 14:38:13 +0200 Subject: [Pki-users] Tomcat version information disclosure in default dogtag installation Message-ID: <483AAF35.4090104@altkom.pl> Hi! I've noticed that it's trivial to discover the exact version information about the servlet container that runs a particular CA instance, one only has to visit an invalid URL for a given instance, e.g.: https://CA_SERVER:9443/qwerty =================== HTTP Status 404 - /qwerty type Status report message /qwerty description The requested resource (/qwerty) is not available. Apache Tomcat/5.5.26 =================== Security by obscurity arguments aside, IMHO it's not so wise to immediately provide exact version information for the server running such security critical service. This information isn't a vulnerability in itself, but makes it so much easier to plan an attack strategy for a potential intruder. In Apache, it's enough to use the "ServerTokens" configuration directive to suppress giving out the exact server version, but AFAIK in Tomcat one has to prepare a customised error page and configure it in web app's web.xml (the element - http://www.apache-korea.org/tomcat/faq/misc.html#error). With Tomact, most admins won't bother since it requires so much labour. I think it would be nice to package simple error pages that don't divulge version information in the pki RPMs by default - do you agree? That would require modifying the following (all webapps' contexts have to be customised): /usr/share/pki/INSTANCE_NAME/conf/web.xml /usr/share/pki/INSTANCE_NAME/webapps/ROOT/WEB-INF/web.xml /usr/share/pki/INSTANCE_NAME/webapps/INSTANCE_NAME/WEB-INF/web.xml -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From pequenaxete at gmail.com Wed May 28 10:44:08 2008 From: pequenaxete at gmail.com (Nacho) Date: Wed, 28 May 2008 12:44:08 +0200 Subject: [Pki-users] Help with the dogtag certificate system Message-ID: <3e13dfae0805280344ha51324lbdffc4648560c5b1@mail.gmail.com> Hi all.My name is Nacho.I'm trying to install the dogtag certificate system on fedora 8. All packages have been installed perfectly but when I try to run the CA, the following error occurs: May 28, 2008 8:16:45 AM org.apache.catalina.core.ApplicationContext log SEVERE: Servlet castart threw unload() exception javax.servlet.ServletException: Servlet.destroy() for servlet castart threw exception at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1373) at org.apache.catalina.core.StandardWrapper.stop(StandardWrapper.java:1688) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4350) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:893) at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1191) at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1162) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:313) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1055) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1067) at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:448) at org.apache.catalina.core.StandardService.stop(StandardService.java:510) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:734) at org.apache.catalina.startup.Catalina.stop(Catalina.java:602) at org.apache.catalina.startup.Catalina.start(Catalina.java:577) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:623) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) I took this error from the file "catalina.out" of the CA because the browser was closed instantly Does anyone have any idea how to fix it? Thank you very much! -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksander.adamowski.dogtag at altkom.pl Thu May 29 09:27:18 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Thu, 29 May 2008 11:27:18 +0200 Subject: [Pki-users] Help with the dogtag certificate system In-Reply-To: <3e13dfae0805290143g65c8f53bx94ab42630af2a248@mail.gmail.com> References: <3e13dfae0805280344ha51324lbdffc4648560c5b1@mail.gmail.com> <483D5C3D.6010405@altkom.pl> <3e13dfae0805290143g65c8f53bx94ab42630af2a248@mail.gmail.com> Message-ID: <483E76F6.2020307@altkom.pl> Nacho wrote: > > CMS Warning: FAILURE: Cannot build CA chain. Error > java.security.cert.CertificateException: Certificate is not a PKCS #11 cer > tificate|FAILURE: authz instance DirAclAuthz initialization failed and > skipped, error=Property internaldb.ldapconn.port missi > ng value| I think this last line give us a hint. It seems that internaldb.ldapconn.port is not set - it controls the port for internal LDAP connection. What port is your LDAP that holds CMS's internal database listening on? I have my LDAP server listening on localhost on port 389, so in /etc/pki-ca/CS.cfg I have: authz.instance.DirAclAuthz.ldap.ldapconn.port=389 .... internaldb.ldapconn.port=389 Make sure all the .*ldapconn.* settings are correctly set and then restart pki-ca. In case of further problems, analyze /var/log/pki-ca/debug first, because catalina.out only contains servlet container's errors and servlet container is quite unlikely to malfunction (its role is quite simple here). -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From aleksander.adamowski.dogtag at altkom.pl Thu May 29 09:27:44 2008 From: aleksander.adamowski.dogtag at altkom.pl (Aleksander Adamowski) Date: Thu, 29 May 2008 11:27:44 +0200 Subject: [Pki-users] Help with the dogtag certificate system In-Reply-To: <3e13dfae0805280344ha51324lbdffc4648560c5b1@mail.gmail.com> References: <3e13dfae0805280344ha51324lbdffc4648560c5b1@mail.gmail.com> Message-ID: <483E7710.30808@altkom.pl> Nacho wrote: > I took this error from the file "catalina.out" of the CA because the > browser was closed instantly > Does anyone have any idea how to fix it? > Thank you very much! Hi! Could you post the full catalina.out file? I'm not sure that this exception reveals the cause. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From stephen.hamilton at us.army.mil Thu May 29 20:38:56 2008 From: stephen.hamilton at us.army.mil (Stephen Hamilton) Date: Thu, 29 May 2008 15:38:56 -0500 Subject: [Pki-users] Help with Dogtag Message-ID: <1212093536.14534.8.camel@rauchbier.charter.net> I just recently installed dogtag on my Fedora 9 system and I've gotten nearly all of it working, except for one module that seems to crash the http-worker process. After copying some jar's, editing a Modutil.pm to remove a syntax error, I have singled this error down to one thing--loading of the mod_tps.so in the pki-tps httpd.conf file. I can comment this out and get TPS to work, but I get stuck on the security modules page in the config wizard with it not finding any, or only finding ones in the Other. The next button keeps me on this page. Any help would be appreciated. Also, any ideas on how to load a cert onto an Axalto 64kv2 card without loading dogtag would be just as helpful--I feel like I'm reinventing the wheel just trying to get some certs on a new card. I've gotten an old muscle applet loaded on the card, and most recently have the coolkey applet loaded, and ESC is recognizing it as a new card, hence why I'm loading dogtag to register it. Thanks in advance. Stephen From jmagne at redhat.com Thu May 29 20:49:26 2008 From: jmagne at redhat.com (Jack Magne) Date: Thu, 29 May 2008 13:49:26 -0700 Subject: [Pki-users] Help with Dogtag In-Reply-To: <1212093536.14534.8.camel@rauchbier.charter.net> References: <1212093536.14534.8.camel@rauchbier.charter.net> Message-ID: <483F16D6.1050703@redhat.com> Stephen: Thanks for the interest. Fedora 8 was the current flavor when we put Dogtag out. You might have better success with trying Fedora 8 for now. As for the certificates, right now the accepted method is to use TPS to get them on your token. thanks, jack Stephen Hamilton wrote: > I just recently installed dogtag on my Fedora 9 system and I've gotten > nearly all of it working, except for one module that seems to crash the > http-worker process. After copying some jar's, editing a Modutil.pm to > remove a syntax error, I have singled this error down to one > thing--loading of the mod_tps.so in the pki-tps httpd.conf file. I can > comment this out and get TPS to work, but I get stuck on the security > modules page in the config wizard with it not finding any, or only > finding ones in the Other. The next button keeps me on this page. > > Any help would be appreciated. Also, any ideas on how to load a cert > onto an Axalto 64kv2 card without loading dogtag would be just as > helpful--I feel like I'm reinventing the wheel just trying to get some > certs on a new card. I've gotten an old muscle applet loaded on the > card, and most recently have the coolkey applet loaded, and ESC is > recognizing it as a new card, hence why I'm loading dogtag to register > it. > > Thanks in advance. > Stephen > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From ehansen at spyrus.com Thu May 29 22:00:47 2008 From: ehansen at spyrus.com (Ebbe Hansen) Date: Thu, 29 May 2008 15:00:47 -0700 Subject: [Pki-users] Failing to install directory server on Fedora9-live USB-stick using the Data Persistence option. Message-ID: The "livecd-iso-to-disk" command appears to work OK when loading Fedora9 on-to a USB thumb-drive with "persistence" option (with an appropriately sized overlay - I used 1 GBY overlay). Custom changes to file-system and installation of new applications appears to survive subsequent reboot sessions. However, while attempting to install the DogTag system on the "persistent" USB, I run unto trouble getting the Directory Server to startup properly. The log-file indicates the configuration session went OK - but the resulting instance does not start (or remain on running state) - the log-file does not indicate any errors! Have anyone on the list been successful getting the Directory Server (and DogTag PKI) to install on a "persistent" live USB? I am using fedora9 version 2.6.25-14.fc9.i686 - downloaded a few days ago. Any comments & suggestions appreciated! E. Hansen @ SPYRUS -------------- next part -------------- An HTML attachment was scrubbed... URL: From ehansen at spyrus.com Sat May 31 00:39:40 2008 From: ehansen at spyrus.com (Ebbe Hansen) Date: Fri, 30 May 2008 17:39:40 -0700 Subject: [Pki-users] RE: Failing to install directory server on Fedora9-live USB-stick using the Data Persistence option. In-Reply-To: Message-ID: I finally succeeded getting a Fedora Directory service installed on a "persistent" Fedora9 USB drive (DNS lookup issues caused previous reported startup problem). I am now attempting to install the DogTag PKI package on the USB drive using 'yum' -- but is prevented to do so - apparently a PKI repository for Fedora9 has not yet been built. Any suggestions? Should I may attempt a manual "piecemeal" type installation of individual PKI-RPM packages - if I knew the dependency-sequence, such task may be easier? Even if successful with such "piecemeal" installation, I assume there is no guarantee the Fedora8 built DogTag PKI system will "behave" properly under Fedora9! When can I expect a Fedora9 version of the DogTag PKI to become available? E. Hansen @ SPYRUS _____ From: Ebbe Hansen Sent: Thursday, May 29, 2008 3:01 PM To: 'pki-users at redhat.com' Subject: Failing to install directory server on Fedora9-live USB-stick using the Data Persistence option. The "livecd-iso-to-disk" command appears to work OK when loading Fedora9 on-to a USB thumb-drive with "persistence" option (with an appropriately sized overlay - I used 1 GBY overlay). Custom changes to file-system and installation of new applications appears to survive subsequent reboot sessions. However, while attempting to install the DogTag system on the "persistent" USB, I run unto trouble getting the Directory Server to startup properly. The log-file indicates the configuration session went OK - but the resulting instance does not start (or remain on running state) - the log-file does not indicate any errors! Have anyone on the list been successful getting the Directory Server (and DogTag PKI) to install on a "persistent" live USB? I am using fedora9 version 2.6.25-14.fc9.i686 - downloaded a few days ago. Any comments & suggestions appreciated! E. Hansen @ SPYRUS -------------- next part -------------- An HTML attachment was scrubbed... URL: