From fabeisageek at googlemail.com Tue Feb 15 14:38:23 2011 From: fabeisageek at googlemail.com (Fabian Bertholm) Date: Tue, 15 Feb 2011 15:38:23 +0100 Subject: [Pki-users] TPS with sub CA or with root CA? Message-ID: Hi, When running multiple sub CAs with one common root CA. Do I attach one TPS to the Root CA or do I attach multiple TPS systems to each Sub CA? Best regards, fabe From msauton at redhat.com Tue Feb 15 17:30:12 2011 From: msauton at redhat.com (Marc Sauton) Date: Tue, 15 Feb 2011 09:30:12 -0800 Subject: [Pki-users] TPS with sub CA or with root CA? In-Reply-To: References: Message-ID: <4D5AB824.40606@redhat.com> It all depends on what may be needed for scalability, fail over, both are possible, but I would probably keep the root CA separate / standalone. One TPS can use several CA's, or several TPS instances can work with a CA. The main idea is to use the "security domains", TPS will look for CA's to use in their security domain, and use their "trusted managers". May want to see: http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.0/html-single/Deployment_Guide/index.html#Certificate_Manager-Security_Domains http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.0/html-single/Admin_Guide/index.html#Working_with_Multiple_Instances_of_a_Subsystem M. On 02/15/2011 06:38 AM, Fabian Bertholm wrote: > Hi, > > When running multiple sub CAs with one common root CA. > Do I attach one TPS to the Root CA or do I attach multiple TPS systems > to each Sub CA? > > Best regards, > fabe > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From davea at ingraftedsoftware.com Wed Feb 16 14:36:50 2011 From: davea at ingraftedsoftware.com (Dave Augustus) Date: Wed, 16 Feb 2011 08:36:50 -0600 Subject: [Pki-users] Exporting Keys from a Software Database Message-ID: <4D5BE102.80908@ingraftedsoftware.com> Hello All, Section 6.2 of the Install Guide discusses "Exporting Keys from a Software Database". The command to do this is: PKCS12Export -debug -d /var/lib/subsystem_name/alias -w p12pwd.txt -p internal.txt -o master.p12 The manual never specifies "what" p12pwd.txt should contain. Same for "internal.txt". Of course, I know that these are passwords used during the installation process... But which ones? Thanks, Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: davea.vcf Type: text/x-vcard Size: 284 bytes Desc: not available URL: From kchamart at redhat.com Wed Feb 16 15:15:01 2011 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 16 Feb 2011 20:45:01 +0530 Subject: [Pki-users] Exporting Keys from a Software Database In-Reply-To: <4D5BE102.80908@ingraftedsoftware.com> References: <4D5BE102.80908@ingraftedsoftware.com> Message-ID: <4D5BE9F5.9020402@redhat.com> On 02/16/2011 08:06 PM, Dave Augustus wrote: > Hello All, > > > Section 6.2 of the Install Guide discusses "Exporting Keys from a Software Database". The > command to do this is: > > PKCS12Export -debug -d /var/lib/subsystem_name/alias -w p12pwd.txt -p internal.txt -o > master.p12 > > The manual never specifies "what" p12pwd.txt should contain. Same for "internal.txt". > > Of course, I know that these are passwords used during the installation process... > > But which ones? p12pwd.txt == password(of your choice) for the PKCS12 file which contains the exported certificates. internal.txt == password of your alias db for the subsystem. This can be noted from `/var/lib/pki-ca/conf/password.conf` and provide the value from this directive internal=392978483900 (internal == internal NSS token db) I believe they're explained in the 'Usage' when you run PKCS12Export on command line. hope that helps /kashyap > > Thanks, > Dave > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From davea at ingraftedsoftware.com Thu Feb 17 03:55:49 2011 From: davea at ingraftedsoftware.com (Dave Augustus) Date: Wed, 16 Feb 2011 21:55:49 -0600 Subject: [Pki-users] Exporting Keys from a Software Database In-Reply-To: <4D5BE9F5.9020402@redhat.com> References: <4D5BE102.80908@ingraftedsoftware.com> <4D5BE9F5.9020402@redhat.com> Message-ID: <4D5C9C45.10002@ingraftedsoftware.com> On 02/16/2011 09:15 AM, Kashyap Chamarthy wrote: > I believe they're explained in the 'Usage' when you run PKCS12Export > on command line. > > hope that helps Thank you very much. I appreciate the details. I will try that. Thanks, Dave From davea at ingraftedsoftware.com Thu Feb 17 04:15:58 2011 From: davea at ingraftedsoftware.com (Dave Augustus) Date: Wed, 16 Feb 2011 22:15:58 -0600 Subject: [Pki-users] Best High Availability Design Message-ID: <4D5CA0FE.5000306@ingraftedsoftware.com> We are in the planning stages of deploying a CA using dogtags. Here is what we know we need and what resources we have to work with. Any suggestions are welcome! A primary CA - only used to create the subordinate CAs. A subordinate CA - this would actually create the certs. We have 2 servers with shared fiber channel storage. Each currently has LDAP (389 project) installed and are replicating between themselves. The LDAP servers run on their own IPs. Also, these 2 servers are a corosync cluster with 4 resource groups: puppet, mysql, apache, snmptrapd and syslog-ng. Each of these have their own IP as well. None of these services are load-balanced. They are either on one or the other servers- all the files these services need are supported with fibre channel storage. Now the CA. Here is what I have considered: 1) CA1 runs on server1- it uses the local LDAP server for storage 2) CA2 runs on server2- it uses the local LDAP server for storage 3) A clone of CA1 runs on server2 using server2's LDAP storage 4) A clone of CA2 runs on server1 using server1's LDAP storage Ideally, we would run the service like we do apache. It would run on either host, but only one a time. It would have its files on shared storage to support this. The problem with this setup is the LDAP storage is the single point of failure as I cannot refer to 2 LDAP servers at the same time, afaik. For HA, it seems that the best I could do would be to have both LDAP servers and all 4 PKI instances installed on shared storage. Any thoughts on this are greatly appreciated. Thanks, Dave From fabeisageek at googlemail.com Thu Feb 17 10:10:45 2011 From: fabeisageek at googlemail.com (Fabian Bertholm) Date: Thu, 17 Feb 2011 11:10:45 +0100 Subject: [Pki-users] Security Officer Mode enabling - where does the ldap auth come from? Message-ID: Hi, Im a little bit stuck on enabling the Security Officer Mode, I'm following the guide at: http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.0/html/Managing_Smart_Cards_with_the_Enterprise_Security_Client/Using_the_Enterprise_Security_Client-Security_Officer_Mode.html#enabling-secmod When formating the blank token my TPS likes to have authentication by default on soKey format operations. This does not work, the tps-debug.log says RA_Processor::RequestExtendedLogin - No Extended Login Response Msg Received and aborts. I wonder where the login data should come from as the ESC is not prompting for a ldap user/pw in this case. btw. I did not use the absolut path /var/lib/pki-tps/cgi-bin/so/index.cgi as stated in guide but the http url as this made more sendse to me. When disabling the authentication for soKey format within the CS.cfg then the formating runs through until the error: RA:tdb_update - failed to add tokendb entry RA_Format_Processor::Process - Failed to update the token database I sniffed with wireshatk and I can see that the ldap addRequest to the tokendb is failing with a syntax error: tokenUserID: value #0 invalid per syntax. And indeed it is missing in the addRequest. I think this is because the auth is disabled and now there is no UserID. How to continue? Best regards, fabe From fabeisageek at googlemail.com Thu Feb 17 11:25:26 2011 From: fabeisageek at googlemail.com (Fabian Bertholm) Date: Thu, 17 Feb 2011 12:25:26 +0100 Subject: [Pki-users] Security Officer Mode enabling - where does the ldap auth come from? In-Reply-To: References: Message-ID: Got it: nsslapd-syntaxcheck: off ;) 2011/2/17 Fabian Bertholm : > Hi, > > Im a little bit stuck on enabling the Security Officer Mode, I'm > following the guide at: > http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.0/html/Managing_Smart_Cards_with_the_Enterprise_Security_Client/Using_the_Enterprise_Security_Client-Security_Officer_Mode.html#enabling-secmod > > When formating the blank token my TPS likes to have authentication by > default on soKey format operations. This does not work, the > tps-debug.log says RA_Processor::RequestExtendedLogin - No Extended > Login Response Msg Received and aborts. I wonder where the login data > should come from as the ESC is not prompting for a ldap user/pw in > this case. > btw. I did not use the absolut path > /var/lib/pki-tps/cgi-bin/so/index.cgi as stated in guide but the http > url as this made more sendse to me. > > When disabling the authentication for soKey format within the CS.cfg > then the formating runs through until the error: > > RA:tdb_update - failed to add tokendb entry > RA_Format_Processor::Process - Failed to update the token database > > I sniffed with wireshatk and I can see that the ldap addRequest to the > tokendb is failing with a syntax error: tokenUserID: value #0 invalid > per syntax. And indeed it is missing in the addRequest. I think this > is because the auth is disabled and now there is no UserID. > > How to continue? > > Best regards, > fabe > From jmagne at redhat.com Thu Feb 17 18:32:16 2011 From: jmagne at redhat.com (Jack Magne) Date: Thu, 17 Feb 2011 10:32:16 -0800 Subject: [Pki-users] Security Officer Mode enabling - where does the ldap auth come from? In-Reply-To: References: Message-ID: <4D5D69B0.40102@redhat.com> On 02/17/2011 03:25 AM, Fabian Bertholm wrote: > Got it: > > nsslapd-syntaxcheck: off ;) > > 2011/2/17 Fabian Bertholm: > >> Hi, >> >> Im a little bit stuck on enabling the Security Officer Mode, I'm >> following the guide at: >> http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.0/html/Managing_Smart_Cards_with_the_Enterprise_Security_Client/Using_the_Enterprise_Security_Client-Security_Officer_Mode.html#enabling-secmod >> >> When formating the blank token my TPS likes to have authentication by >> default on soKey format operations. This does not work, the >> tps-debug.log says RA_Processor::RequestExtendedLogin - No Extended >> Login Response Msg Received and aborts. I wonder where the login data >> should come from as the ESC is not prompting for a ldap user/pw in >> this case. >> btw. I did not use the absolut path >> /var/lib/pki-tps/cgi-bin/so/index.cgi as stated in guide but the http >> url as this made more sendse to me. >> >> When disabling the authentication for soKey format within the CS.cfg >> then the formating runs through until the error: >> >> RA:tdb_update - failed to add tokendb entry >> RA_Format_Processor::Process - Failed to update the token database >> >> I sniffed with wireshatk and I can see that the ldap addRequest to the >> tokendb is failing with a syntax error: tokenUserID: value #0 invalid >> per syntax. And indeed it is missing in the addRequest. I think this >> is because the auth is disabled and now there is no UserID. >> >> How to continue? >> >> Best regards, >> fabe >> >> Hello: I will certainly take a look at your issue and come back with some ideas... If you could, could you possibly submit the relevant piece of the log file "/var/lib/pki-tps/logs/tps-debug.log". This could give me a clearer idea as to what is going on. thanks, jack > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From jmagne at redhat.com Thu Feb 17 18:33:07 2011 From: jmagne at redhat.com (Jack Magne) Date: Thu, 17 Feb 2011 10:33:07 -0800 Subject: [Pki-users] Security Officer Mode enabling - where does the ldap auth come from? In-Reply-To: References: Message-ID: <4D5D69E3.3060407@redhat.com> On 02/17/2011 03:25 AM, Fabian Bertholm wrote: > Got it: > > nsslapd-syntaxcheck: off ;) > > 2011/2/17 Fabian Bertholm: > >> Hi, >> >> Im a little bit stuck on enabling the Security Officer Mode, I'm >> following the guide at: >> http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.0/html/Managing_Smart_Cards_with_the_Enterprise_Security_Client/Using_the_Enterprise_Security_Client-Security_Officer_Mode.html#enabling-secmod >> >> When formating the blank token my TPS likes to have authentication by >> default on soKey format operations. This does not work, the >> tps-debug.log says RA_Processor::RequestExtendedLogin - No Extended >> Login Response Msg Received and aborts. I wonder where the login data >> should come from as the ESC is not prompting for a ldap user/pw in >> this case. >> btw. I did not use the absolut path >> /var/lib/pki-tps/cgi-bin/so/index.cgi as stated in guide but the http >> url as this made more sendse to me. >> >> When disabling the authentication for soKey format within the CS.cfg >> then the formating runs through until the error: >> >> RA:tdb_update - failed to add tokendb entry >> RA_Format_Processor::Process - Failed to update the token database >> >> I sniffed with wireshatk and I can see that the ldap addRequest to the >> tokendb is failing with a syntax error: tokenUserID: value #0 invalid >> per syntax. And indeed it is missing in the addRequest. I think this >> is because the auth is disabled and now there is no UserID. >> >> How to continue? >> >> Best regards, >> fabe >> >> > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > My apologies :) I read the problem portion and missed the solution part! thanks again, jack From davea at ingraftedsoftware.com Sat Feb 19 19:24:06 2011 From: davea at ingraftedsoftware.com (Dave Augustus) Date: Sat, 19 Feb 2011 13:24:06 -0600 Subject: [Pki-users] Best High Availability Design In-Reply-To: References: <4D5CA0FE.5000306@ingraftedsoftware.com> Message-ID: <4D6018D6.3020308@ingraftedsoftware.com> Hi Erwin, I appreciate your response. The primary reason for wanting to a PKI was to alleviate all the self-signed certs that we are/will be using. Then I realized that it could be expanded to include user authentication to our NOC web sites. So this is how it has evolved. Currently, I have a primary CA with a secondary CA. * The primary CA is all hosted on a single host, host A, including LDAP storage. * The secondary CA is all hosted on a single host, host B, including LDAP storage. * The 2 LDAP servers are in a multi-master config with replication agreements for the User database, not the CAs though. * I will create all the certs from the secondary CA. * We will create user certs * We will create server certs * Both hosts are in a 2-node corosync cluster. So we have numerous single points of failure in this setup, hence my questions. With I think of HA for this project, I think more along the lines of availability and less about performance. I have 2 physical hosts to work with, along with fibre channel with an OCFS2 volume available to both hosts. So I would think that what I am looking for is that all services could be running on a single host, in case the other host failed. Dogtags supports cloning and so for each service that I need (CA1,CA2, OCSP ), I can use cloning with manual assistance. I just designate one of host A or B to be the primary host for a given service. Them clone them to the other host. Thanks, Dave On 02/17/2011 11:42 AM, Erwin Himawan wrote: > Hi Dave, > > Since PKI is so much flexible, your PKI architecture would be > influenced by many factors such as number of subscribers, the > diversity of your subscribers PKI needs, real time access, initial and > operating cost, etc. Also, when you mentioned "HA", what kind of "HA" > it is; e.g. HA for obtaining new cert, renewal cert, obtaining the > latest revocation status information? HA for certificate publication > in the repository? HA for CA access to the repository? What is the > requirement in your PKI CP? > > Not knowing these factors are, it would be very difficult to come up > with the "best" "HA" design for your circumstances. > > Regards, > Erwin > > > On Wed, Feb 16, 2011 at 10:15 PM, Dave Augustus > > wrote: > > We are in the planning stages of deploying a CA using dogtags. > Here is what we know we need and what resources we have to work > with. Any suggestions are welcome! > > A primary CA - only used to create the subordinate CAs. > A subordinate CA - this would actually create the certs. > > We have 2 servers with shared fiber channel storage. Each > currently has LDAP (389 project) installed and are replicating > between themselves. The LDAP servers run on their own IPs. Also, > these 2 servers are a corosync cluster with 4 resource groups: > puppet, mysql, apache, snmptrapd and syslog-ng. Each of these have > their own IP as well. None of these services are load-balanced. > They are either on one or the other servers- all the files these > services need are supported with fibre channel storage. > > Now the CA. Here is what I have considered: > 1) CA1 runs on server1- it uses the local LDAP server for storage > 2) CA2 runs on server2- it uses the local LDAP server for storage > 3) A clone of CA1 runs on server2 using server2's LDAP storage > 4) A clone of CA2 runs on server1 using server1's LDAP storage > > Ideally, we would run the service like we do apache. It would run > on either host, but only one a time. It would have its files on > shared storage to support this. The problem with this setup is the > LDAP storage is the single point of failure as I cannot refer to 2 > LDAP servers at the same time, afaik. > > For HA, it seems that the best I could do would be to have both > LDAP servers and all 4 PKI instances installed on shared storage. > > Any thoughts on this are greatly appreciated. > > Thanks, > Dave > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: davea.vcf Type: text/x-vcard Size: 284 bytes Desc: not available URL: From davea at ingraftedsoftware.com Sat Feb 19 19:56:21 2011 From: davea at ingraftedsoftware.com (Dave Augustus) Date: Sat, 19 Feb 2011 13:56:21 -0600 Subject: [Pki-users] anyone had a challenge getting crts to publish to the file system? Message-ID: <4D602065.8020408@ingraftedsoftware.com> I have a brand new install on Centos 5.5 64. I can't get it to publish certs to the file system, only LDAP. In pkiconsole, when I first access the Publishing area, I get an error message about not being authorized. I am using the CA admin account to do this. Any ideas? Thanks, Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: davea.vcf Type: text/x-vcard Size: 284 bytes Desc: not available URL: From kchamart at redhat.com Mon Feb 21 06:54:14 2011 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Mon, 21 Feb 2011 12:24:14 +0530 Subject: [Pki-users] anyone had a challenge getting crts to publish to the file system? In-Reply-To: <4D602065.8020408@ingraftedsoftware.com> References: <4D602065.8020408@ingraftedsoftware.com> Message-ID: <4D620C16.7020503@redhat.com> On 02/20/2011 01:26 AM, Dave Augustus wrote: > I have a brand new install on Centos 5.5 64. > > I can't get it to publish certs to the file system, only LDAP. In pkiconsole, when I first > access the Publishing area, I get an error message about not being authorized. I am using > the CA admin account to do this. Dave, It'd be more helpful here, if you can provide the log info(CA debug log ideally) when you see this. > > Any ideas? Though I'm not sure at this point what's blocking you, however I was able to previously publish Certs(and CRLs) to file system successfully using below procedure: --------------------------------------------------------------------------------------- 1/ Configure CA 2/ Fire up pkiconsole, go to 'Publishing' 3/ Configure a filebased 'Publisher' + Add a 'FileBasedPublisher'(say with id 'filepub') with a directory '/var/lib/pki-ca/filepublishing' Note:Ensure to create this directory 'filepublishing' under /var/lib/pki* tree, so that SELinux doesn't complain. If you're creating this directory elsewhere on the file system, be sure to relabel your SELinux context 4/ Configure 'Rules' + Add a new 'Rule'(say "filerule") and select the type as 'certs' , mapper as 'NoMap' and publisher as 'filepub'(the one we created in step 3 above) 5/ Enable Publshing in pkiconsole 6/ Restart CA instance (do not miss this) ---------------------------------------------------------------------------------------- Now, new certs should be published to your 'var/lib/pki-ca/filepublishing' directory. hope that helps. > > Thanks, > Dave > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -- /kashyap From davea at ingraftedsoftware.com Mon Feb 21 15:45:45 2011 From: davea at ingraftedsoftware.com (Dave Augustus) Date: Mon, 21 Feb 2011 09:45:45 -0600 Subject: [Pki-users] anyone had a challenge getting crts to publish to the file system? In-Reply-To: <4D620C16.7020503@redhat.com> References: <4D602065.8020408@ingraftedsoftware.com> <4D620C16.7020503@redhat.com> Message-ID: <808DCBAD-2566-440A-827E-B21A2E4FF8E8@ingraftedsoftware.com> On Feb 21, 2011, at 12:54 AM, Kashyap Chamarthy wrote: > On 02/20/2011 01:26 AM, Dave Augustus wrote: >> I have a brand new install on Centos 5.5 64. >> >> I can't get it to publish certs to the file system, only LDAP. In pkiconsole, when I first >> access the Publishing area, I get an error message about not being authorized. I am using >> the CA admin account to do this. > > Dave, > It'd be more helpful here, if you can provide the log info(CA debug log ideally) when you see this. >> >> Any ideas? > > Though I'm not sure at this point what's blocking you, however I was able to previously publish Certs(and CRLs) to file system successfully using below procedure: > > --------------------------------------------------------------------------------------- > 1/ Configure CA > > 2/ Fire up pkiconsole, go to 'Publishing' This is where I get the error "you are not authorized to perform this operation". I disabled selinux still got same error. Are you on irc? > > 3/ Configure a filebased 'Publisher' > + Add a 'FileBasedPublisher'(say with id 'filepub') with a directory '/var/lib/pki-ca/filepublishing' > > Note:Ensure to create this directory 'filepublishing' under /var/lib/pki* tree, so that SELinux doesn't complain. If you're creating this directory elsewhere on the file system, be sure to relabel your SELinux context > > 4/ Configure 'Rules' > + Add a new 'Rule'(say "filerule") and select the type as 'certs' , mapper as 'NoMap' and publisher as 'filepub'(the one we created in step 3 above) > > 5/ Enable Publshing in pkiconsole > > 6/ Restart CA instance (do not miss this) > ---------------------------------------------------------------------------------------- > > Now, new certs should be published to your 'var/lib/pki-ca/filepublishing' directory. > > hope that helps. > > > >> >> Thanks, >> Dave >> >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > > > -- > /kashyap From fabeisageek at googlemail.com Mon Feb 21 16:08:57 2011 From: fabeisageek at googlemail.com (Fabian Bertholm) Date: Mon, 21 Feb 2011 17:08:57 +0100 Subject: [Pki-users] TPS with sub CA or with root CA? In-Reply-To: <4D5AB824.40606@redhat.com> References: <4D5AB824.40606@redhat.com> Message-ID: Hi, Well please correct me if i am wrong. If I run one TPS with multiple Sub CAs (all in the same security domain) then I need to do the mapping to the different tokens by using the token CUID. I would then add an extra token type and ca connection per CUID range. What I did not understand, how can I fix the CUID. To me it seems they are rather random and predefiend by the token itsself. I did not find a place where I can specify a range on formating. Looks like this is not the right approach.. Best regards, Fabe 2011/2/15 Marc Sauton : > It all depends on what may be needed for scalability, fail over, both are > possible, but I would probably keep the root CA separate / standalone. > One TPS can use several CA's, or several TPS instances can work with a CA. > The main idea is to use the "security domains", TPS will look for CA's to > use in their security domain, and use their "trusted managers". > > May want to see: > http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.0/html-single/Deployment_Guide/index.html#Certificate_Manager-Security_Domains > > http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.0/html-single/Admin_Guide/index.html#Working_with_Multiple_Instances_of_a_Subsystem > > M. > > On 02/15/2011 06:38 AM, Fabian Bertholm wrote: >> >> Hi, >> >> When running multiple sub CAs with one common root CA. >> Do I attach one TPS to the Root CA or do I attach multiple TPS systems >> to each Sub CA? >> >> Best regards, >> fabe >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > > From mmercier at gmail.com Fri Feb 25 17:51:19 2011 From: mmercier at gmail.com (Mike Mercier) Date: Fri, 25 Feb 2011 12:51:19 -0500 Subject: [Pki-users] Migration documentation Message-ID: Hello, I have a dogtag-1.1.0 with fedora-ds-base-1.2.0 installed on Fedora 10. I would like to migrate this system to CentOS 5.5 using the latest EPEL distribution without losing any data. Is there any documentation available to accomplish this? A bit of background: 2 servers with the following: fedora-ds installed with replication between the two (using certificates generated from dogtag) self-signed CA on dogtag dogtag installed on both with the second install joined to the security domain of the first If more details are required, please let me know. Thanks, Mike From WilliamC.Elliott at s-itsolutions.at Mon Feb 28 14:06:06 2011 From: WilliamC.Elliott at s-itsolutions.at (Elliott William C OSS sIT) Date: Mon, 28 Feb 2011 14:06:06 -0000 Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error In-Reply-To: <5E904A528F23FA469961CECAC5F4178702CBA2B2@NDHMC4SXCH.gdc4s.com> References: <4CC15FCC.6030903@x-zone.org> <5E904A528F23FA469961CECAC5F4178702C6E5C1@NDHMC4SXCH.gdc4s.com> <4CC89770.1050504@x-zone.org> <5E904A528F23FA469961CECAC5F4178702CBA2B2@NDHMC4SXCH.gdc4s.com> Message-ID: <85C87A9995875247B2DD471950E0AE4D012DDE@M0181.s-mxs.net> Hallo, I have exactly the same problem described in October in the Pki-users mailing list. In the list, there is no resolution. Was someone able to work around the problem? We are running Dogtag on RHEL5 64-bit. The beautiful thing is, the profile works in RH CS 8.0, but throws the java error with Dogtag. The java is slightly newer on the Dogtag system: 1.6.0_24 (where the error occurs) vs. 1.6.0_21 on the CS 8.0. Dogtag version is pki-common-1.3.8-1.el5. Any Ideas? Thanks in advance, Bill -----Original Message----- From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of sean.veale at gdc4s.com Sent: Freitag, 29. Oktober 2010 15:21 To: fdh at x-zone.org Cc: pki-users at redhat.com Subject: Re: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] Hi I'm using RH Enterprise Linux 5.3 Java -version gives Java Version "1.6.0.0" OpenJDK Runtime Environment (IcedTea6 1.6) (rhel-1.11.b16.el5-x86_64) OpenJDK 64 Bit Server VM (build 14.0-b16, mixed mode) Looks like I'm running a slightly older version of the OpenJDK vm, and I'm on a 64 bit platform instead of the 32 bit one you are on. A red-hat rep would have to weigh in if either would be significant in this case. Sean On 10/22/2010 03:14 PM, sean.veale at gdc4s.com wrote: > Hi, Usually there is a reference to a Impl classID so the CA knows what > to function/class to call when generating this part of the cert. > > For my system (built on Redhat CS 8.0 instead of dogtag but those > codebases are very similar) I have this in my cert profiles and it > generates the Crl dp entry in the cert without errors. > > policyset.userCertSet.13.constraint.class_id=noConstraintImpl > policyset.userCertSet.13constraint.name=No Constraint > policyset.userCertSet.13.default.class_id=crlDistributionPointsExtDefaul > tImpl > policyset.userCertSet.13.default.name=CRL Distribution Points Extension > Default > policyset.userCertSet.13.default.params.crlDistPointsCritical=false > policyset.userCertSet.13.default.params.crlDistPointsNum=1 > policyset.userCertSet.13.default.params.crlDistPointsEnable_0=true > policyset.userCertSet.13.default.params.crlDistPointsPointName_0=http:// > xxx.xxx.xxx/crl/xxx.crl > > > I don't believe you need to specify the No Constraint fields, as I just > have them in there if later I wanted to enforce a specific CRL > distribution point, it would require less updates to the profile. > > This line here is the one I think you need. > policyset.userCertSet.13.default.class_id=crlDistributionPointsExtDefaul > tImpl > > As it tells the CA what class to call into when generating this part of > the cert. > > I don't think this is needed either, but it was in the example certs > from the CS 8.0 install so I left it. > policyset.userCertSet.13.default.params.crlDistPointsNum=1 > > I presume it is just letting the CA know after you added one CRL to the > cert you can move on but I have dug into the code to find out. > > Sean > > > This message and/or attachments may include information subject to GDC4S > O.M. 1.8.6 and GD Corporate Policy 07-105 and are intended to be > accessed only by authorized recipients. Use, storage and transmission > are governed by General Dynamics and its policies. Contractual > restrictions apply to third parties. Recipients should refer to the > policies or contract to determine proper handling. Unauthorized review, > use, disclosure or distribution is prohibited. If you are not an > intended recipient, please contact the sender and destroy all copies of > the original message. > > > -----Original Message----- > From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] > On Behalf Of Frederic d'Huart > Sent: Friday, October 22, 2010 5:56 AM > To: pki-users at redhat.com > Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: > Type_0 : URIName error > > Hello Pki users, > > > Section B.1.4. of the RH admin guide refers to the following acceptable > values > for crlDistributionPoint Type: > > DirectoryName > URIName > RelativeToIssuer > > > > Using PKIConsole, I have added to the caUserCert profile a policy for > include a CDP as follow: > > policyset.userCertSet.13.default.name=CRL Distribution Points Extension > Default > policyset.userCertSet.13.default.params.crlDistPointsCritical=false > policyset.userCertSet.13.default.params.crlDistPointsEnable_0=true > policyset.userCertSet.13.default.params.crlDistPointsPointType_0=URIName > policyset.userCertSet.13.default.params.crlDistPointsPointName_0=http:// > xxx.xxx.xxx/crl/xxx.crl > policyset.userCertSet.13.default.params.crlDistPointsReasons_0= > > after profile re-activated, and new request generated, I get the > following error on the agent interface: > > The Certificate System has encountered an unrecoverable error. > > Error Message: > /java.lang.ClassCastException: netscape.security.x509.Extension cannot > be cast to netscape.security.x509.CRLDistributionPointsExtension/ > > Please contact your local administrator for assistance. > > > Any Ideas what could be wrong ? > > > Thank you. > > > _______________________________________________ > 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