From pieter.baele at gmail.com Tue May 2 09:45:49 2017 From: pieter.baele at gmail.com (Pieter Baele) Date: Tue, 02 May 2017 09:45:49 +0000 Subject: [Pki-users] Dogtag rootCA or subCA Message-ID: We will start setting up IDM/FreeIPA for a specific linux subdomain in our enterprise. But how can we best integrate Dogtag with the enterprise CA infrastructure (MS Certificate Services)? Option 1: Dogtag as the rootCA (?) We can use FreeIPA for all certificates where we need to encrypt end-to-end communication between servers (as example) And websites by external CA's or the the enterprise CA infrastructure for which the issuing subca's are published to all cleints... What about the principle of an offline rootCA in that case? Is that possible with Dogtag? Option 2: Dogtag (RH IDM) as a subordinate CA of MS CA. Is there a specific reason that a subordinate CA is a better idea? Our PKI administrator's do not really like an additional subCA, because it is difficult to limit exposure/risks? We still need to publish the subca to clients? What's your opinion: rootCA, or subordinate CA signed by the existing MS Certificate Services PKI? -- Pieter -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue May 2 10:55:34 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 2 May 2017 20:55:34 +1000 Subject: [Pki-users] Dogtag rootCA or subCA In-Reply-To: References: Message-ID: <20170502105534.GB19119@dhcp-40-8.bne.redhat.com> On Tue, May 02, 2017 at 09:45:49AM +0000, Pieter Baele wrote: > We will start setting up IDM/FreeIPA for a specific linux subdomain in our > enterprise. > > But how can we best integrate Dogtag with the enterprise CA infrastructure > (MS Certificate Services)? > > Option 1: Dogtag as the rootCA (?) > We can use FreeIPA for all certificates where we need to encrypt end-to-end > communication between servers (as example) > And websites by external CA's or the the enterprise CA infrastructure for > which the issuing subca's are published to all cleints... > > What about the principle of an offline rootCA in that case? Is that > possible with Dogtag? > > Option 2: Dogtag (RH IDM) as a subordinate CA of MS CA. > Is there a specific reason that a subordinate CA is a better idea? > Our PKI administrator's do not really like an additional subCA, because it > is difficult to limit exposure/risks? > We still need to publish the subca to clients? > > What's your opinion: rootCA, or subordinate CA signed by the existing MS > Certificate Services PKI? > If you already have an MS CA securing your infrastructre, with the CA cert distribututed to clients / AD-enrolled machines, then the best approach is making the IPA CA subordinate to your MS CA. Then you don't need to distribute the IPA CA certificate to Windows clients, because they already trust the root MS CA. TLS servers with certificates signed by the IPA CA will need to include the IPA CA intermediate certificate in their certificate chain. Hope that helps, Fraser From pieter.baele at gmail.com Tue May 2 11:54:06 2017 From: pieter.baele at gmail.com (Pieter Baele) Date: Tue, 02 May 2017 11:54:06 +0000 Subject: [Pki-users] Dogtag rootCA or subCA In-Reply-To: <20170502105534.GB19119@dhcp-40-8.bne.redhat.com> References: <20170502105534.GB19119@dhcp-40-8.bne.redhat.com> Message-ID: Hi Fraser, Maybe I am not interpreting this 100% correctly.... Using a subCA: in which cases / direction it is not necessary to deploy the IPA intermediate CA cert? AFAIK, all issuing (sub) CA's certs are deployed to (windows) clients. So in fact this is not (always) necessary? On Tue, May 2, 2017 at 12:55 PM Fraser Tweedale wrote: > On Tue, May 02, 2017 at 09:45:49AM +0000, Pieter Baele wrote: > > We will start setting up IDM/FreeIPA for a specific linux subdomain in > our > > enterprise. > > > > But how can we best integrate Dogtag with the enterprise CA > infrastructure > > (MS Certificate Services)? > > > > Option 1: Dogtag as the rootCA (?) > > We can use FreeIPA for all certificates where we need to encrypt > end-to-end > > communication between servers (as example) > > And websites by external CA's or the the enterprise CA infrastructure for > > which the issuing subca's are published to all cleints... > > > > What about the principle of an offline rootCA in that case? Is that > > possible with Dogtag? > > > > Option 2: Dogtag (RH IDM) as a subordinate CA of MS CA. > > Is there a specific reason that a subordinate CA is a better idea? > > Our PKI administrator's do not really like an additional subCA, because > it > > is difficult to limit exposure/risks? > > We still need to publish the subca to clients? > > > > What's your opinion: rootCA, or subordinate CA signed by the existing MS > > Certificate Services PKI? > > > If you already have an MS CA securing your infrastructre, with the > CA cert distribututed to clients / AD-enrolled machines, then the > best approach is making the IPA CA subordinate to your MS CA. Then > you don't need to distribute the IPA CA certificate to Windows > clients, because they already trust the root MS CA. > > TLS servers with certificates signed by the IPA CA will need to > include the IPA CA intermediate certificate in their certificate > chain. > > Hope that helps, > Fraser > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue May 2 13:57:16 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 2 May 2017 23:57:16 +1000 Subject: [Pki-users] Dogtag rootCA or subCA In-Reply-To: References: <20170502105534.GB19119@dhcp-40-8.bne.redhat.com> Message-ID: <20170502135716.GE19119@dhcp-40-8.bne.redhat.com> On Tue, May 02, 2017 at 11:54:06AM +0000, Pieter Baele wrote: > Hi Fraser, > > Maybe I am not interpreting this 100% correctly.... > Using a subCA: in which cases / direction it is not necessary to deploy the > IPA intermediate CA cert? > If Windows clients trust the root CA, they do not need to trust or even know about intermediate CA certs (such as the IPA CA), to trust service certs issued by the intermediate CA. As long as the TLS server is configured to deliver the intermediate cert(s) along with the end-entity cert, everything will work just fine. Hope that clarifies things. > AFAIK, all issuing (sub) CA's certs are deployed to (windows) clients. So > in fact this is not (always) necessary? > I do not know much about the behaviour of AD / MS CA in this regard, i.e. whether it delivers sub-CA certificates to clients as trusted issuing certificates or not. But see above; it is not necessary as long as the server is configured properly. Cheers, Fraser > > > > On Tue, May 2, 2017 at 12:55 PM Fraser Tweedale wrote: > > > On Tue, May 02, 2017 at 09:45:49AM +0000, Pieter Baele wrote: > > > We will start setting up IDM/FreeIPA for a specific linux subdomain in > > our > > > enterprise. > > > > > > But how can we best integrate Dogtag with the enterprise CA > > infrastructure > > > (MS Certificate Services)? > > > > > > Option 1: Dogtag as the rootCA (?) > > > We can use FreeIPA for all certificates where we need to encrypt > > end-to-end > > > communication between servers (as example) > > > And websites by external CA's or the the enterprise CA infrastructure for > > > which the issuing subca's are published to all cleints... > > > > > > What about the principle of an offline rootCA in that case? Is that > > > possible with Dogtag? > > > > > > Option 2: Dogtag (RH IDM) as a subordinate CA of MS CA. > > > Is there a specific reason that a subordinate CA is a better idea? > > > Our PKI administrator's do not really like an additional subCA, because > > it > > > is difficult to limit exposure/risks? > > > We still need to publish the subca to clients? > > > > > > What's your opinion: rootCA, or subordinate CA signed by the existing MS > > > Certificate Services PKI? > > > > > If you already have an MS CA securing your infrastructre, with the > > CA cert distribututed to clients / AD-enrolled machines, then the > > best approach is making the IPA CA subordinate to your MS CA. Then > > you don't need to distribute the IPA CA certificate to Windows > > clients, because they already trust the root MS CA. > > > > TLS servers with certificates signed by the IPA CA will need to > > include the IPA CA intermediate certificate in their certificate > > chain. > > > > Hope that helps, > > Fraser > > From cfu at redhat.com Tue May 2 21:12:45 2017 From: cfu at redhat.com (Christina Fu) Date: Tue, 2 May 2017 14:12:45 -0700 Subject: [Pki-users] Dogtag rootCA or subCA In-Reply-To: References: Message-ID: <065a6a88-8b96-d030-8525-0877686a6e33@redhat.com> It's unclear from what's described to have the whole context to answer your specific questions, but I can answer the question regarding Dogtag. See below. On 05/02/2017 02:45 AM, Pieter Baele wrote: > We will start setting up IDM/FreeIPA for a specific linux subdomain > in our enterprise. > > But how can we best integrate Dogtag with the enterprise CA > infrastructure (MS Certificate Services)? > > Option 1: Dogtag as the rootCA (?) > We can use FreeIPA for all certificates where we need to encrypt > end-to-end communication between servers (as example) > And websites by external CA's or the the enterprise CA infrastructure > for which the issuing subca's are published to all cleints... > > What about the principle of an offline rootCA in that case? Is that > possible with Dogtag? Offline rootCA is actually what we'd recommend for large secure deployment sites, where you would setup a Dogtag root CA and issue one or more subordinate CA's. I think you could also set up an OCSP subsystem that's paired up with the root CA to serve revocation information once you bring the root CA offline. You would only need to bring up the rootCA when you need to install more subordinate CA's or revoke one. > > Option 2: Dogtag (RH IDM) as a subordinate CA of MS CA. > Is there a specific reason that a subordinate CA is a better idea? > Our PKI administrator's do not really like an additional subCA, > because it is difficult to limit exposure/risks? > We still need to publish the subca to clients? > > What's your opinion: rootCA, or subordinate CA signed by the existing > MS Certificate Services PKI? > > -- Pieter > > > _______________________________________________ > 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 pieter.baele at gmail.com Wed May 3 10:36:38 2017 From: pieter.baele at gmail.com (Pieter Baele) Date: Wed, 03 May 2017 10:36:38 +0000 Subject: [Pki-users] Dogtag rootCA or subCA In-Reply-To: <065a6a88-8b96-d030-8525-0877686a6e33@redhat.com> References: <065a6a88-8b96-d030-8525-0877686a6e33@redhat.com> Message-ID: On Tue, May 2, 2017 at 11:13 PM Christina Fu wrote: > It's unclear from what's described to have the whole context to answer > your specific questions, but I can answer the question regarding Dogtag. > See below. > I got perfect answers from both Fraser and you. Thanks a lot. As I initially thought, a FreeIPA ( or Dogtag with less features....(?)) is still the best idea. But our (MS) AD/PKI admins had some doubts, and were convinced you have to deploy subCA CA certificates to clients. To conclude: - it is much simpler for our team to setup FreeIPA CA services as a subCA also because we don't need to create and secure and offline CA in that case. - we don't need to distribute certs to windows clients - the rootCA (AD PKI) can always revoke our subCA when there is a problem/breach. Correct? -- Pieter -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Wed May 3 13:50:48 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 3 May 2017 23:50:48 +1000 Subject: [Pki-users] Dogtag rootCA or subCA In-Reply-To: References: <065a6a88-8b96-d030-8525-0877686a6e33@redhat.com> Message-ID: <20170503135048.GL19119@dhcp-40-8.bne.redhat.com> On Wed, May 03, 2017 at 10:36:38AM +0000, Pieter Baele wrote: > On Tue, May 2, 2017 at 11:13 PM Christina Fu wrote: > > > It's unclear from what's described to have the whole context to answer > > your specific questions, but I can answer the question regarding Dogtag. > > See below. > > > > I got perfect answers from both Fraser and you. Thanks a lot. > > As I initially thought, a FreeIPA ( or Dogtag with less features....(?)) is > still the best idea. > > But our (MS) AD/PKI admins had some doubts, and were convinced you have to > deploy subCA CA certificates to clients. > > To conclude: > - it is much simpler for our team to setup FreeIPA CA services as a subCA > also because we don't need to create and secure and offline CA in that case. > Yes, creating a sub-CA of the organisation's existing CA avoid this duplicate effort. There may be some good reasons to want a separate root for IDM, but where there is an existing PKI, most organisations choose to chain IDM into it. > - we don't need to distribute certs to windows clients > That's right. > - the rootCA (AD PKI) can always revoke our subCA when there is a > problem/breach. Correct? > Yes. The usual caveats around CRLs, OCSP etc apply. Cheers, Fraser From Florian.Supper at s-itsolutions.at Fri May 5 12:24:26 2017 From: Florian.Supper at s-itsolutions.at (Supper Florian 6342 sIT) Date: Fri, 5 May 2017 14:24:26 +0200 Subject: [Pki-users] Subject Alt names concate Message-ID: Hi, related to RFC6125 ( Best practice checking server identities) i have to create a cert profile which adds the Common name from the subject into a SAN. So far so good, this works now with this config. policyset.cmcServerCert.10.constraint.class_id=noConstraintImpl policyset. cmcServerCert.10.constraint.name=No Constraint policyset. cmcServerCert.10.default.class_id=subjectAltNameExtDefaultImpl policyset. cmcServerCert.10.default.name=Subject Alt Name Constraint policyset. cmcServerCert.10.default.params.subjAltNameExtCritical=false policyset. cmcServerCert.10.default.params.subjAltExtGNEnable=true policyset. cmcServerCert.10.default.params.subjAltExtGNEnable_0=true policyset. cmcServerCert.10.default.params.subjAltExtType_0=DNSName policyset. cmcServerCert.10.default.params.subjAltExtPattern_0=$request.req_subject_name.cn$ policyset. cmcServerCert.10.default.params.subjAltNameNumGNs=1 Now I have to add additional SANS if the user sends them in the request. CSR part: Requested Extensions: X509v3 Subject Alternative Name: DNS:mywebservice.example.com, DNS:mywebservicealias.example.com With this config, it is possible to take the SANS out of the csr and bring that in the cert.. policyset. cmcServerCert.9.constraint.class_id=noConstraintImpl policyset. cmcServerCert.9.constraint.name=No Constraint policyset. cmcServerCert.9.constraint.subjAltNameExtCritical=false policyset. cmcServerCert.9.default.class_id=userExtensionDefaultImpl policyset. cmcServerCert.9.default.name=User Supplied Extension Default policyset. cmcServerCert.9.default.params.userExtOID=2.5.29.17 The problem what I had is that I had to take the SANS out of the request and then ADD the cn out of the subjet as SAN too. I'm not able to get this working. Please help. Thanks in advanced. Br florian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Fri May 5 23:43:09 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sat, 6 May 2017 09:43:09 +1000 Subject: [Pki-users] Subject Alt names concate In-Reply-To: References: Message-ID: <20170505234309.GT19119@dhcp-40-8.bne.redhat.com> On Fri, May 05, 2017 at 02:24:26PM +0200, Supper Florian 6342 sIT wrote: > Hi, > > related to RFC6125 ( Best practice checking server identities) i have to create a cert profile which adds the Common name from the subject into a SAN. > > So far so good, this works now with this config. > > policyset.cmcServerCert.10.constraint.class_id=noConstraintImpl > policyset. cmcServerCert.10.constraint.name=No Constraint > policyset. cmcServerCert.10.default.class_id=subjectAltNameExtDefaultImpl > policyset. cmcServerCert.10.default.name=Subject Alt Name Constraint > policyset. cmcServerCert.10.default.params.subjAltNameExtCritical=false > policyset. cmcServerCert.10.default.params.subjAltExtGNEnable=true > policyset. cmcServerCert.10.default.params.subjAltExtGNEnable_0=true > policyset. cmcServerCert.10.default.params.subjAltExtType_0=DNSName > policyset. cmcServerCert.10.default.params.subjAltExtPattern_0=$request.req_subject_name.cn$ > policyset. cmcServerCert.10.default.params.subjAltNameNumGNs=1 > > > Now I have to add additional SANS if the user sends them in the request. > > CSR part: > Requested Extensions: > X509v3 Subject Alternative Name: > DNS:mywebservice.example.com, DNS:mywebservicealias.example.com > > > With this config, it is possible to take the SANS out of the csr and bring that in the cert.. > > policyset. cmcServerCert.9.constraint.class_id=noConstraintImpl > policyset. cmcServerCert.9.constraint.name=No Constraint > policyset. cmcServerCert.9.constraint.subjAltNameExtCritical=false > policyset. cmcServerCert.9.default.class_id=userExtensionDefaultImpl > policyset. cmcServerCert.9.default.name=User Supplied Extension Default > policyset. cmcServerCert.9.default.params.userExtOID=2.5.29.17 > > > The problem what I had is that I had to take the SANS out of the request and then ADD the cn out of the subjet as SAN too. > > I'm not able to get this working. > > Please help. > > Thanks in advanced. > > Br > florian Hi Florian, In the 10.4 release, we added a new profile component specifically for adding the CN (if it looks like a DNS name) to the SAN extension (creating it if necessary). It is called CommonNameToSANDefault. See https://bugzilla.redhat.com/show_bug.cgi?id=1429492 for more details. Thanks, Fraser From mw at flanga.io Sun May 7 16:43:38 2017 From: mw at flanga.io (Moritz Wirth) Date: Sun, 07 May 2017 18:43:38 +0200 Subject: [Pki-users] Use Dogtag with external Root CA - CS.cfg is missing Message-ID: <5C924DBF-9370-44AE-87A6-265BFAD41CC4@flanga.io> Hello, I installed Dogtag and tried to create a new PKI Instance for the intermediate CA. I used this tutorial (http://pki.fedoraproject.org/wiki/Installing_CA_with_Externaly-Signed_CA_Certificate) with the same configuration file (I changed the passwords and the ldap/ds configuration). The Root CA is stored offline and not managed through Dogtag. I ran pkispawn which failed with the following error: [root at ca ~]# pkispawn -f flanga-ssl-g1.conf Subsystem (CA/KRA/OCSP/TKS/TPS) [CA]: CA Begin installation (Yes/No/Quit)? yes Log file: /var/log/pki/pki-ca-spawn.20170507183908.log Loading deployment configuration from flanga-ssl-g1.conf. pkispawn??? : ERROR??? ....... File '/etc/pki/pki-tomcat/ca/CS.cfg' is either missing or is NOT a regular file! Traceback (most recent call last): ? File "/usr/sbin/pkispawn", line 817, in ??? main(sys.argv) ? File "/usr/sbin/pkispawn", line 501, in main ??? create_master_dictionary(parser) ? File "/usr/sbin/pkispawn", line 641, in create_master_dictionary ??? parser.compose_pki_master_dictionary() ? File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", line 690, in compose_pki_master_dictionary ??? raise Exception(log.PKI_FILE_MISSING_OR_NOT_A_FILE_1) Exception: File '%s' is either missing or is NOT a regular file! I did not create another Dogtag instance before. Thank you for the help! Best regards, Moritz -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn at rloteck.net Sun May 28 05:29:03 2017 From: spawn at rloteck.net (Rafael Leiva-Ochoa) Date: Sat, 27 May 2017 22:29:03 -0700 Subject: [Pki-users] Dogtag Cert Lauch Page Renewal Message-ID: Hi Everyone, I am was looking through the Dogtag CA documentation, and I was not able to find the process for renewing the Dogtag Web page certificate. I wanted to update the cert since all browser now required a SAN on the cert. Any help would be great. Thanks, Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn at rloteck.net Wed May 31 01:29:58 2017 From: spawn at rloteck.net (Rafael Leiva-Ochoa) Date: Tue, 30 May 2017 18:29:58 -0700 Subject: [Pki-users] Dogtag Cert Lauch Page Renewal In-Reply-To: References: Message-ID: Any takers? Rafael On Sat, May 27, 2017 at 10:29 PM, Rafael Leiva-Ochoa wrote: > Hi Everyone, > > I am was looking through the Dogtag CA documentation, and I was not > able to find the process for renewing the Dogtag Web page certificate. I > wanted to update the cert since all browser now required a SAN on the cert. > Any help would be great. > > Thanks, > > Rafael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Wed May 31 21:31:31 2017 From: cfu at redhat.com (Christina Fu) Date: Wed, 31 May 2017 14:31:31 -0700 Subject: [Pki-users] Dogtag Cert Lauch Page Renewal In-Reply-To: References: Message-ID: <034773bd-3756-73df-8c77-7dd1ebe93082@redhat.com> Hi Rafael, I think the following should work for you in theory (Note: I have not tried it myself). If you mean the web server cert, by default it uses the caServerCert profile. So to add SAN you would want to add Subject Alt Name Default and possibly constraint to that profile. You can look up how other default profiles. Here is an example policy you could add: policyset.serverCertSet.9.constraint.class_id=noConstraintImpl policyset.serverCertSet.9.constraint.name=No Constraint policyset.serverCertSet.9.default.class_id=subjectAltNameExtDefaultImpl policyset.serverCertSet.9.default.name=Subject Alternative Name Extension Default policyset.serverCertSet.9.default.params.subjAltExtGNEnable_0=true policyset.serverCertSet.9.default.params.subjAltExtPattern_0=yourServer.example.com policyset.serverCertSet.9.default.params.subjAltExtType_0=DNSName policyset.serverCertSet.9.default.params.subjAltNameNumGNs=1 Make sure you add the set id "9" (if unique..you can change it to another unique id) to policyset.serverCertSet.list= It is important that you add that to the profile before you proceed with the renewal instruction (under the assumption that you wish to reuse keys), because the instruction I am about to give you will use the same profile that the original cert was issued through. Restart the CA after the above config change. About renewal, if you want to reuse the same keys of the original web server certificate, you could try going to the ee page Enrollment/Renewal tab. Where you would find on the last link of the page to be Renewal: Renew certificate to be manually approved by agents. Enter the current (to be replaced) server cert serial number and submit. Have the CA agent approve the request. Download and update your server cert, restart the intended web server. If you don't want to reuse keys, then simply enroll through the Manual Server Certificate Enrollment, which uses the profile that you just modified, but will expect a whole new csr to be the input (rekey). Incidentally, if you happen to have the original CSR (hence preserving the same keys), you would end up having the same keys with the new update profile (with SAN) as well, which would effectively give you the same result. Let us know if that works for you. Christina On 05/30/2017 06:29 PM, Rafael Leiva-Ochoa wrote: > Any takers? > > Rafael > > On Sat, May 27, 2017 at 10:29 PM, Rafael Leiva-Ochoa > > wrote: > > Hi Everyone, > > I am was looking through the Dogtag CA documentation, and I > was not able to find the process for renewing the Dogtag Web page > certificate. I wanted to update the cert since all browser now > required a SAN on the cert. Any help would be great. > > Thanks, > > Rafael > > > > > _______________________________________________ > 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: