From jnimeh at gmail.com Sun Aug 5 19:21:50 2012 From: jnimeh at gmail.com (Jamil Nimeh) Date: Sun, 05 Aug 2012 12:21:50 -0700 Subject: [Pki-users] Backup/restore of Dogtag servers when migrating FC15 to FC17 Message-ID: <501EC7CE.5010403@gmail.com> Hi all, I was looking at migrating the OS I run the CA, RA and OCSP on from Fedora 15 servers to Fedora 17. I saw the section in the admin guide relating to backup/restore (sec 12.10 in the 8.1 guide) and wanted to know if this approach will work when the restore is happening on a different target OS than the source OS (i.e. FC17 from a FC15 source). Has anyone tried it? Any pitfalls I need to be aware of above and beyond the stuff outlined in the documentation? Thank you, Jamil From alee at redhat.com Tue Aug 7 13:44:08 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 07 Aug 2012 09:44:08 -0400 Subject: [Pki-users] Backup/restore of Dogtag servers when migrating FC15 to FC17 In-Reply-To: <501EC7CE.5010403@gmail.com> References: <501EC7CE.5010403@gmail.com> Message-ID: <1344347049.6933.3.camel@aleeredhat.laptop> What versions of dogtag are you running? On Sun, 2012-08-05 at 12:21 -0700, Jamil Nimeh wrote: > Hi all, I was looking at migrating the OS I run the CA, RA and OCSP on > from Fedora 15 servers to Fedora 17. I saw the section in the admin > guide relating to backup/restore (sec 12.10 in the 8.1 guide) and wanted > to know if this approach will work when the restore is happening on a > different target OS than the source OS (i.e. FC17 from a FC15 source). > > Has anyone tried it? Any pitfalls I need to be aware of above and > beyond the stuff outlined in the documentation? > > Thank you, > Jamil > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From Jamil.Nimeh at viasat.com Tue Aug 7 16:37:39 2012 From: Jamil.Nimeh at viasat.com (Nimeh, Jamil) Date: Tue, 7 Aug 2012 16:37:39 +0000 Subject: [Pki-users] Backup/restore of Dogtag servers when migrating FC15 to FC17 In-Reply-To: <1344347049.6933.3.camel@aleeredhat.laptop> References: <501EC7CE.5010403@gmail.com> <1344347049.6933.3.camel@aleeredhat.laptop> Message-ID: <6A95FA630FB5124C886BAD159CDBA1F011A53EEA@wdc1exchmbxp02.hq.corp.viasat.com> Sorry, I forgot to mention that. I'm running the 9.0 (pki-ca-9.0.20, specifically) -------------- Jamil Nimeh (760) 476-2130 (U) The information contained herein that is marked (U//FOUO) is for the exclusive use of Government and Contractor personnel with a need-to-know the information. Such information is specifically prohibited from posting on unrestricted bulletin boards or other unlimited access applications. -----Original Message----- From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Ade Lee Sent: Tuesday, August 07, 2012 6:44 AM To: Jamil Nimeh Cc: pki-users at redhat.com Subject: Re: [Pki-users] Backup/restore of Dogtag servers when migrating FC15 to FC17 What versions of dogtag are you running? On Sun, 2012-08-05 at 12:21 -0700, Jamil Nimeh wrote: > Hi all, I was looking at migrating the OS I run the CA, RA and OCSP on > from Fedora 15 servers to Fedora 17. I saw the section in the admin > guide relating to backup/restore (sec 12.10 in the 8.1 guide) and > wanted to know if this approach will work when the restore is > happening on a different target OS than the source OS (i.e. FC17 from a FC15 source). > > Has anyone tried it? Any pitfalls I need to be aware of above and > beyond the stuff outlined in the documentation? > > Thank you, > Jamil > > _______________________________________________ > 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 alee at redhat.com Fri Aug 10 13:39:54 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 10 Aug 2012 09:39:54 -0400 Subject: [Pki-users] Backup/restore of Dogtag servers when migrating FC15 to FC17 In-Reply-To: <6A95FA630FB5124C886BAD159CDBA1F011A53EEA@wdc1exchmbxp02.hq.corp.viasat.com> References: <501EC7CE.5010403@gmail.com> <1344347049.6933.3.camel@aleeredhat.laptop> <6A95FA630FB5124C886BAD159CDBA1F011A53EEA@wdc1exchmbxp02.hq.corp.viasat.com> Message-ID: <1344606000.21349.54.camel@aleeredhat.laptop> One of the tricky things about going from f15 to f17 is that the mechanism of starting dogtag (and other services) has changed. F15 (if I recall correctly) uses init5, but F17 uses systemd. I would try the following approach: 1. Create a new instance with the same name as your previous instance. This will create all the relevant systemd files to allow the server to start up. In particular, this will also create the symbolic link - /var/lib//. Note where this link points. 2. Backup and restore the old instance as described in the docs. You will be essentially replacing the data in the security databases, config files etc. You will likely need to fix the link mentioned above as it needs to point to the tomcat6 systemd startup script rather than the init5 one. Let us know how it goes. Ade On Tue, 2012-08-07 at 16:37 +0000, Nimeh, Jamil wrote: > Sorry, I forgot to mention that. I'm running the 9.0 (pki-ca-9.0.20, specifically) > > -------------- > Jamil Nimeh > (760) 476-2130 > > (U) The information contained herein that is marked (U//FOUO) is for the exclusive use of Government and Contractor personnel with a need-to-know the information. Such information is specifically prohibited from posting on unrestricted bulletin boards or other unlimited access applications. > -----Original Message----- > From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Ade Lee > Sent: Tuesday, August 07, 2012 6:44 AM > To: Jamil Nimeh > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] Backup/restore of Dogtag servers when migrating FC15 to FC17 > > What versions of dogtag are you running? > > On Sun, 2012-08-05 at 12:21 -0700, Jamil Nimeh wrote: > > Hi all, I was looking at migrating the OS I run the CA, RA and OCSP on > > from Fedora 15 servers to Fedora 17. I saw the section in the admin > > guide relating to backup/restore (sec 12.10 in the 8.1 guide) and > > wanted to know if this approach will work when the restore is > > happening on a different target OS than the source OS (i.e. FC17 from a FC15 source). > > > > Has anyone tried it? Any pitfalls I need to be aware of above and > > beyond the stuff outlined in the documentation? > > > > Thank you, > > Jamil > > > > _______________________________________________ > > 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 helm at fionn.es.net Tue Aug 14 22:26:45 2012 From: helm at fionn.es.net (Mike Helm) Date: Tue, 14 Aug 2012 15:26:45 -0700 Subject: [Pki-users] setting DNSName in subjectAltName extension Message-ID: <201208142226.q7EMQjsG012453@fionn.es.net> I need to set DNSName in server subjectAltname extensions, but having difficulty getting the server's name into this field. I've read this: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Certificate_System/8.0/html/Admin_Guide/Certificate_and_CRL_Extensions.html#Subject_Alternative_Name_Extension_Default I can set the RFC822name value using this (see table B-15) $request.requestor_email$ by making sure there's a requestor_email=something in the GET from the RA. There really isn;t anything that corresponds to what DNSName should be but I expected $request.subject$ would do; I added subject=some.thing.dom, but no, I get "$request.subject$" as a literal string. I also tried the obviously wrong example in Example B.1 (before the table) - policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.SAN1$ same thing, $request.SAN1$ literal. I can set subjAltExtPattern_1 to my own literal string, but obviously that's counterproductive. I can set it to $request.requestor_email$ and get the email address in DNSName - if I didn't have cases where BOTH subjectAltName fields were needed I'd just re-purpose requestor_email. So - what works and how? I'm stumped. Any ideas appreciated. Thanks, ==mwh From msauton at redhat.com Tue Aug 14 23:05:57 2012 From: msauton at redhat.com (Marc Sauton) Date: Tue, 14 Aug 2012 16:05:57 -0700 Subject: [Pki-users] setting DNSName in subjectAltName extension In-Reply-To: <201208142226.q7EMQjsG012453@fionn.es.net> References: <201208142226.q7EMQjsG012453@fionn.es.net> Message-ID: <502AD9D5.2040402@redhat.com> On 08/14/2012 03:26 PM, Mike Helm wrote: > > I need to set DNSName in server subjectAltname extensions, but > having difficulty getting the server's name into this field. > > I've read this: > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Certificate_System/8.0/html/Admin_Guide/Certificate_and_CRL_Extensions.html#Subject_Alternative_Name_Extension_Default > > I can set the RFC822name value using this (see table B-15) > $request.requestor_email$ > by making sure there's a requestor_email=something in the GET from the > RA. There really isn;t anything that corresponds to what DNSName should > be but I expected $request.subject$ would do; I added subject=some.thing.dom, > but no, I get "$request.subject$" as a literal string. > > I also tried the obviously wrong example in Example B.1 (before the table) - > policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.SAN1$ > same thing, $request.SAN1$ literal. > > I can set subjAltExtPattern_1 to my own literal string, but obviously that's > counterproductive. I can set it to $request.requestor_email$ and get the email > address in DNSName - if I didn't have cases where BOTH subjectAltName fields > were needed I'd just re-purpose requestor_email. > > So - what works and how? I'm stumped. Any ideas appreciated. Thanks, ==mwh > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users something like this should work fine: policyset.encryptionCertSet.8.constraint.class_id=noConstraintImpl policyset.encryptionCertSet.8.constraint.name=No Constraint policyset.encryptionCertSet.8.default.class_id=subjectAltNameExtDefaultImpl policyset.encryptionCertSet.8.default.name=Subject Alt Name Constraint policyset.encryptionCertSet.8.default.params.subjAltNameExtCritical=true policyset.encryptionCertSet.8.default.params.subjAltNameNumGNs=8 # policyset.encryptionCertSet.8.default.params.subjAltExtGNEnable_0=true policyset.encryptionCertSet.8.default.params.subjAltExtType_0=IPAddress policyset.encryptionCertSet.8.default.params.subjAltExtPattern_0=10.1.2.3 # policyset.encryptionCertSet.8.default.params.subjAltExtGNEnable_1=true policyset.encryptionCertSet.8.default.params.subjAltExtType_1=RFC822Name policyset.encryptionCertSet.8.default.params.subjAltExtPattern_1=$request.SAN1$ # policyset.encryptionCertSet.8.default.params.subjAltExtGNEnable_2=true policyset.encryptionCertSet.8.default.params.subjAltExtType_2=RFC822Name policyset.encryptionCertSet.8.default.params.subjAltExtPattern_2=$request.requestor_email$ From helm at fionn.es.net Wed Aug 15 15:16:07 2012 From: helm at fionn.es.net (Mike Helm) Date: Wed, 15 Aug 2012 08:16:07 -0700 Subject: [Pki-users] setting DNSName in subjectAltName extension In-Reply-To: Your message of "Tue, 14 Aug 2012 16:05:57 PDT." <502AD9D5.2040402@redhat.com> Message-ID: <201208151516.q7FFG7Df025046@fionn.es.net> Marc Sauton writes: > > I need to set DNSName in server subjectAltname extensions, but > > having difficulty getting the server's name into this field. ... > > I also tried the obviously wrong example in Example B.1 (before the table) - > > policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.SAN1$ > > same thing, $request.SAN1$ literal. > something like this should work fine: > > policyset.encryptionCertSet.8.constraint.class_id=noConstraintImpl > policyset.encryptionCertSet.8.constraint.name=No Constraint > policyset.encryptionCertSet.8.default.class_id=subjectAltNameExtDefaultImpl > policyset.encryptionCertSet.8.default.name=Subject Alt Name Constraint > policyset.encryptionCertSet.8.default.params.subjAltNameExtCritical=true > policyset.encryptionCertSet.8.default.params.subjAltNameNumGNs=8 > # > policyset.encryptionCertSet.8.default.params.subjAltExtGNEnable_0=true > policyset.encryptionCertSet.8.default.params.subjAltExtType_0=IPAddress > policyset.encryptionCertSet.8.default.params.subjAltExtPattern_0=10.1.2.3 > # > policyset.encryptionCertSet.8.default.params.subjAltExtGNEnable_1=true > policyset.encryptionCertSet.8.default.params.subjAltExtType_1=RFC822Name > policyset.encryptionCertSet.8.default.params.subjAltExtPattern_1=$request.SAN1$ I tried exactly this (see above). I think it is probably wrong, because they probably meant something else other than SAN1, like subject, but neither will work. (Look at the table that follows in the doc, or look at the 8.1 doc where I believe the example is corrected). The only variable I've succeeded in getting values passed thru is "requestor_email". Why? What am I missing? These variables arrive thru the GET list from the RA, btw. > # > policyset.encryptionCertSet.8.default.params.subjAltExtGNEnable_2=true > policyset.encryptionCertSet.8.default.params.subjAltExtType_2=RFC822Name > policyset.encryptionCertSet.8.default.params.subjAltExtPattern_2=$request.requestor_email$ Thanks, ==mwh From riccardo.brunetti at to.infn.it Mon Aug 20 10:45:45 2012 From: riccardo.brunetti at to.infn.it (Riccardo Brunetti) Date: Mon, 20 Aug 2012 12:45:45 +0200 Subject: [Pki-users] Using SPKAC with DogTag Command line API Message-ID: <50321559.6010909@to.infn.it> Dear pki-users. We would like to use the CMCEnroll and HttpClient commands to send a certificate request to the CA backend and retrieve the certificate. We succeeded in doing this using a PKCS10 certificate request, but we need to do the same using a SPKAC request format (like the one originally produced by Firefox). As far as we understood the RA subsystem is able to somehow convert the SPKAC in PKCS10 but in our setup the RA susbsystem is not used. Does anybody of you have some suggestions? Thank you very much Cheers R. Brunetti -- ------------------- Riccardo Brunetti INFN - Torino Tel: +390116707295 Skype: rbrunetti ------------------- From awnuk at redhat.com Mon Aug 20 18:47:55 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Mon, 20 Aug 2012 11:47:55 -0700 Subject: [Pki-users] Using SPKAC with DogTag Command line API In-Reply-To: <50321559.6010909@to.infn.it> References: <50321559.6010909@to.infn.it> Message-ID: <5032865B.90103@redhat.com> On 08/20/2012 03:45 AM, Riccardo Brunetti wrote: > > Dear pki-users. > We would like to use the CMCEnroll and HttpClient commands to send a > certificate request to the CA backend and retrieve the certificate. > We succeeded in doing this using a PKCS10 certificate request, but we > need to do the same using a SPKAC request format (like the one > originally produced by Firefox). > > As far as we understood the RA subsystem is able to somehow convert the > SPKAC in PKCS10 but in our setup the RA susbsystem is not used. I do not believe that any of the existing subsystems provide this type of request conversion. However, since the Dogtag CA is currently processing keygen tag requests properly, it should be possible to modify the CA UI to provide the proper keygen tag to support enabling request generation on Chrome, Opera, and Safari. > > > Does anybody of you have some suggestions? > Thank you very much > > Cheers > R. Brunetti >