From abowles at hireology.com Tue Jun 11 19:53:57 2019 From: abowles at hireology.com (Allyson Bowles) Date: Tue, 11 Jun 2019 14:53:57 -0500 Subject: [Pki-users] Adding a signing certificate to an existing Dogtag instance Message-ID: <20190611195356.3yf4ynt233jhmb3y@localhost> Hey folks, Awhile back, I set up an internal CA signing certificate for the purpose of issuing certificates used for RabbitMQ connections, Sensu, Consul, etc. I would now like to add that signing certificate to my existing Dogtag instance (created as part of an IPA server installation), so that I can configure clients to automatically renew these certificates using Certmonger. This signing certificate would not be used for anything IPA related, only the abovementioned third-party utilities requiring an internally trusted SSL certificate for authentication. I have managed to perform the pkispawn step using a PKCS12 file containing the signing certificate and key as well as a pkispawn config file that looks something like this: #### [DEFAULT] pki_instance_name=pki-tomcat pki_admin_password=secret pki_client_pkcs12_password=secret pki_ds_password=secret pki_ds_ldap_port=389 pki_existing=True [CA] pki_ca_signing_nickname=MyInternalCA pki_ca_signing_csr_path=req/ca.csr pki_pkcs12_path=ca.p12 pki_pkcs12_password=secret pki_serial_number_range_start=90 pki_request_number_range_start=90 pki_master_crl_enable=False pki_external_step_one=False pki_external_step_two=True ### The output I get is as follows: ``` # pkispawn -s CA -f pkispawn.cfg Log file: /var/log/pki/pki-ca-spawn.20190611180347.log Loading deployment configuration from pkispawn.cfg. Installing CA into /var/lib/pki/pki-tomcat. --------------- Import complete --------------- Installation failed: com.netscape.certsrv.base.BadRequestException: System is already configured Please check the CA logs in /var/log/pki/pki-tomcat/ca. ``` The pki-ca-spawn logfile doesn't contain anything interesting, and neither could I find anything terribly noteworthy in either /var/log/pki/pki-tomcat/ca/{debug,system}. The certificate and key do show up in certutil -L and -K, so my plan was to try carrying on with getting a client to use Certmonger to renew its certificate against this signing certificate. To do /that/, it looks like I need to create or modify an existing CA profile per https://www.dogtagpki.org/wiki/PKI_CA_Profile_CLI. However, this doc expects the operator to have a user certificate with the nickname 'caadmin' and a password. I don't seem to have a certificate with that nickname and I'm not sure which certificate to look for. Further documentation https://www.dogtagpki.org/wiki/CA_Admin_Setup#Retrieving_CA_Admin_Certificate suggests that I could create a new CA admin user...but this requires having access to the existing one. Which brings us to my actual questions. 1) Am I trying to do a reasonable thing by importing an existing signing certificate into an existing Dogtag instance? If not, what's a better way to achieve the ability to autorenew client certificates? 2) How can I either reset the existing CA admin credentials (given that I have system root) or force creation of a new user without nuking my current instance? Ideas about where I could look for the existing CA admin credentials would work as well but I understand this is highly dependent on how the system was set up initially. 3) Is there something else I should be doing, after the pkispawn partial failure, to troubleshoot? I figured attempting to carry on with an autorenew might at least get me more information about what's happening, but I'm very open to other approaches as well. Thank you for your time, Ally -- Allyson Bowles | Senior Site Reliability Engineer e: abowles at hireology.com | 7C2D 671B 08A2 0D8A AD52 540E 1FB2 B534 ECD5 4608 http://www.hireology.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ftweedal at redhat.com Wed Jun 12 05:03:37 2019 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 12 Jun 2019 15:03:37 +1000 Subject: [Pki-users] Adding a signing certificate to an existing Dogtag instance In-Reply-To: <20190611195356.3yf4ynt233jhmb3y@localhost> References: <20190611195356.3yf4ynt233jhmb3y@localhost> Message-ID: <20190612050337.GD3547@T470s> Hi Allyson, pkispawn is not the right approach. You can't "add" a signing certificate to an existing IPA / Dogtag deployment in that way. You could create Certmonger tracking requests for the end-entity certs, configuring them to use the IPA CA when renewal is needed. It is fine for a end-entity certificate to be renewed with a different issuer. As a transitional measure the current issuer certificate can be added to the IPA trust store so that IPA-enrolled machines will trust it. If you wish to continue issing those EE certs with a dedicated sub-CA, create one with the 'ipa ca-add' command and use the Certmonger `--issuer' option to refer to it. Cheers, Fraser On Tue, Jun 11, 2019 at 02:53:57PM -0500, Allyson Bowles wrote: > Hey folks, > > Awhile back, I set up an internal CA signing certificate for the purpose > of issuing certificates used for RabbitMQ connections, Sensu, Consul, > etc. I would now like to add that signing certificate to my existing > Dogtag instance (created as part of an IPA server installation), so that > I can configure clients to automatically renew these certificates using > Certmonger. This signing certificate would not be used for anything IPA > related, only the abovementioned third-party utilities requiring an > internally trusted SSL certificate for authentication. > > I have managed to perform the pkispawn step using a PKCS12 file > containing the signing certificate and key as well as a pkispawn config > file that looks something like this: > > #### > [DEFAULT] > pki_instance_name=pki-tomcat > pki_admin_password=secret > pki_client_pkcs12_password=secret > pki_ds_password=secret > pki_ds_ldap_port=389 > pki_existing=True > > [CA] > pki_ca_signing_nickname=MyInternalCA > pki_ca_signing_csr_path=req/ca.csr > pki_pkcs12_path=ca.p12 > pki_pkcs12_password=secret > pki_serial_number_range_start=90 > pki_request_number_range_start=90 > pki_master_crl_enable=False > pki_external_step_one=False > pki_external_step_two=True > ### > > The output I get is as follows: > > ``` > # pkispawn -s CA -f pkispawn.cfg > Log file: /var/log/pki/pki-ca-spawn.20190611180347.log > Loading deployment configuration from pkispawn.cfg. > Installing CA into /var/lib/pki/pki-tomcat. > --------------- > Import complete > --------------- > > Installation failed: > com.netscape.certsrv.base.BadRequestException: System is already > configured > > Please check the CA logs in /var/log/pki/pki-tomcat/ca. > ``` > > The pki-ca-spawn logfile doesn't contain anything interesting, and > neither could I find anything terribly noteworthy in either > /var/log/pki/pki-tomcat/ca/{debug,system}. > > The certificate and key do show up in certutil -L and -K, so my plan was > to try carrying on with getting a client to use Certmonger to renew its > certificate against this signing certificate. To do /that/, it looks > like I need to create or modify an existing CA profile per > https://www.dogtagpki.org/wiki/PKI_CA_Profile_CLI. However, this doc > expects the operator to have a user certificate with the nickname > 'caadmin' and a password. I don't seem to have a certificate with that > nickname and I'm not sure which certificate to look for. Further > documentation > https://www.dogtagpki.org/wiki/CA_Admin_Setup#Retrieving_CA_Admin_Certificate > suggests that I could create a new CA admin user...but this requires > having access to the existing one. > > Which brings us to my actual questions. > > 1) Am I trying to do a reasonable thing by importing an existing signing > certificate into an existing Dogtag instance? If not, what's a better > way to achieve the ability to autorenew client certificates? > > 2) How can I either reset the existing CA admin credentials (given that > I have system root) or force creation of a new user without nuking my > current instance? Ideas about where I could look for the existing CA > admin credentials would work as well but I understand this is highly > dependent on how the system was set up initially. > > 3) Is there something else I should be doing, after the pkispawn partial > failure, to troubleshoot? I figured attempting to carry on with an > autorenew might at least get me more information about what's happening, > but I'm very open to other approaches as well. > > Thank you for your time, > Ally > > -- > Allyson Bowles | Senior Site Reliability Engineer > e: abowles at hireology.com | 7C2D 671B 08A2 0D8A AD52 540E 1FB2 B534 ECD5 4608 > http://www.hireology.com > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From abowles at hireology.com Wed Jun 12 15:45:52 2019 From: abowles at hireology.com (Allyson Bowles) Date: Wed, 12 Jun 2019 10:45:52 -0500 Subject: [Pki-users] Adding a signing certificate to an existing Dogtag instance In-Reply-To: <20190612050337.GD3547@T470s> References: <20190611195356.3yf4ynt233jhmb3y@localhost> <20190612050337.GD3547@T470s> Message-ID: <20190612154551.2sva6msm7a2hs7uy@localhost> Hi Fraser, Thanks so much for your response, this is really helpful. The primary reason I've been avoiding using the IPA CA as the renewing issuer for the EE certs is that I currently have the 'cacert' params for the utilities that use the certs pointed to the signing cert for "MyInternalCA". Assuming all of my servers are IPA enrolled, will using the IPA CA allow me to get rid of this parameter completely? All my research to date on how an individual server's cert trust store works has been flawed at best and flat out incorrect at worst - I have found that update-ca-trust enable / add cert to /etc/pki/ca-trust/source/anchors / update-ca-trust extract does not seem to be applied to everything on the system. This is to say that I still have to specify a 'cacert' parameter for anything that uses my internal CA, or the EE cert is not trusted. Can I expect this to be the case with the IPA trust store? Any documentation you can point me to on this topic would be much appreciated. Thank you, Allyson On 12 Jun 15:37, Fraser Tweedale wrote: > Hi Allyson, > > pkispawn is not the right approach. You can't "add" a signing > certificate to an existing IPA / Dogtag deployment in that way. > > You could create Certmonger tracking requests for the end-entity > certs, configuring them to use the IPA CA when renewal is needed. > It is fine for a end-entity certificate to be renewed with a > different issuer. As a transitional measure the current issuer > certificate can be added to the IPA trust store so that IPA-enrolled > machines will trust it. > > If you wish to continue issing those EE certs with a dedicated > sub-CA, create one with the 'ipa ca-add' command and use the > Certmonger `--issuer' option to refer to it. > > Cheers, > Fraser > > On Tue, Jun 11, 2019 at 02:53:57PM -0500, Allyson Bowles wrote: > > Hey folks, > > > > Awhile back, I set up an internal CA signing certificate for the purpose > > of issuing certificates used for RabbitMQ connections, Sensu, Consul, > > etc. I would now like to add that signing certificate to my existing > > Dogtag instance (created as part of an IPA server installation), so that > > I can configure clients to automatically renew these certificates using > > Certmonger. This signing certificate would not be used for anything IPA > > related, only the abovementioned third-party utilities requiring an > > internally trusted SSL certificate for authentication. > > > > I have managed to perform the pkispawn step using a PKCS12 file > > containing the signing certificate and key as well as a pkispawn config > > file that looks something like this: > > > > #### > > [DEFAULT] > > pki_instance_name=pki-tomcat > > pki_admin_password=secret > > pki_client_pkcs12_password=secret > > pki_ds_password=secret > > pki_ds_ldap_port=389 > > pki_existing=True > > > > [CA] > > pki_ca_signing_nickname=MyInternalCA > > pki_ca_signing_csr_path=req/ca.csr > > pki_pkcs12_path=ca.p12 > > pki_pkcs12_password=secret > > pki_serial_number_range_start=90 > > pki_request_number_range_start=90 > > pki_master_crl_enable=False > > pki_external_step_one=False > > pki_external_step_two=True > > ### > > > > The output I get is as follows: > > > > ``` > > # pkispawn -s CA -f pkispawn.cfg > > Log file: /var/log/pki/pki-ca-spawn.20190611180347.log > > Loading deployment configuration from pkispawn.cfg. > > Installing CA into /var/lib/pki/pki-tomcat. > > --------------- > > Import complete > > --------------- > > > > Installation failed: > > com.netscape.certsrv.base.BadRequestException: System is already > > configured > > > > Please check the CA logs in /var/log/pki/pki-tomcat/ca. > > ``` > > > > The pki-ca-spawn logfile doesn't contain anything interesting, and > > neither could I find anything terribly noteworthy in either > > /var/log/pki/pki-tomcat/ca/{debug,system}. > > > > The certificate and key do show up in certutil -L and -K, so my plan was > > to try carrying on with getting a client to use Certmonger to renew its > > certificate against this signing certificate. To do /that/, it looks > > like I need to create or modify an existing CA profile per > > https://www.dogtagpki.org/wiki/PKI_CA_Profile_CLI. However, this doc > > expects the operator to have a user certificate with the nickname > > 'caadmin' and a password. I don't seem to have a certificate with that > > nickname and I'm not sure which certificate to look for. Further > > documentation > > https://www.dogtagpki.org/wiki/CA_Admin_Setup#Retrieving_CA_Admin_Certificate > > suggests that I could create a new CA admin user...but this requires > > having access to the existing one. > > > > Which brings us to my actual questions. > > > > 1) Am I trying to do a reasonable thing by importing an existing signing > > certificate into an existing Dogtag instance? If not, what's a better > > way to achieve the ability to autorenew client certificates? > > > > 2) How can I either reset the existing CA admin credentials (given that > > I have system root) or force creation of a new user without nuking my > > current instance? Ideas about where I could look for the existing CA > > admin credentials would work as well but I understand this is highly > > dependent on how the system was set up initially. > > > > 3) Is there something else I should be doing, after the pkispawn partial > > failure, to troubleshoot? I figured attempting to carry on with an > > autorenew might at least get me more information about what's happening, > > but I'm very open to other approaches as well. > > > > Thank you for your time, > > Ally > > > > -- > > Allyson Bowles | Senior Site Reliability Engineer > > e: abowles at hireology.com | 7C2D 671B 08A2 0D8A AD52 540E 1FB2 B534 ECD5 4608 > > http://www.hireology.com > > > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users > -- Allyson Bowles | Senior Site Reliability Engineer e: abowles at hireology.com | 7C2D 671B 08A2 0D8A AD52 540E 1FB2 B534 ECD5 4608 http://www.hireology.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ftweedal at redhat.com Thu Jun 13 00:52:04 2019 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 13 Jun 2019 10:52:04 +1000 Subject: [Pki-users] Adding a signing certificate to an existing Dogtag instance In-Reply-To: <20190612154551.2sva6msm7a2hs7uy@localhost> References: <20190611195356.3yf4ynt233jhmb3y@localhost> <20190612050337.GD3547@T470s> <20190612154551.2sva6msm7a2hs7uy@localhost> Message-ID: <20190613005204.GH3547@T470s> On Wed, Jun 12, 2019 at 10:45:52AM -0500, Allyson Bowles wrote: > Hi Fraser, > > Thanks so much for your response, this is really helpful. The primary > reason I've been avoiding using the IPA CA as the renewing issuer for > the EE certs is that I currently have the 'cacert' params for the > utilities that use the certs pointed to the signing cert for > "MyInternalCA". Assuming all of my servers are IPA enrolled, will using > the IPA CA allow me to get rid of this parameter completely? > > All my research to date on how an individual server's cert trust store works > has been flawed at best and flat out incorrect at worst - I have found > that update-ca-trust enable / add cert to > /etc/pki/ca-trust/source/anchors / update-ca-trust extract does not seem > to be applied to everything on the system. This is to say that I still > have to specify a 'cacert' parameter for anything that uses my internal > CA, or the EE cert is not trusted. Can I expect this to be the case with > the IPA trust store? Any documentation you can point me to on this topic > would be much appreciated. > The IPA trust store just installs the trusted certs, as recorded in the LDAP database, into the system trust stores under /etc/pki/ca-trust/. Most programs on the system should use the system trust by default, but some programs do not, especially when it comes to validing TLS client (not server) certificates. I do not know the behaviour of the utilities you use but it seems they fall into this category. In which case you are left to manually specify the CA(s) to trust. Or perhaps there's a way to configure / alter the utilities to use system trust. There is another way: cross-sign MyInternalCA with the IPA CA, and update the programs that present certificates signed by MyInternalCA to present the IPA-signed MyInteralCA certificate in the chain. That should suffice to allow IPA-enrolled machines to trust those certificates without changing anything about how those EE certs are issued or renewed. Cheers, Fraser > Thank you, > Allyson > > On 12 Jun 15:37, Fraser Tweedale wrote: > > Hi Allyson, > > > > pkispawn is not the right approach. You can't "add" a signing > > certificate to an existing IPA / Dogtag deployment in that way. > > > > You could create Certmonger tracking requests for the end-entity > > certs, configuring them to use the IPA CA when renewal is needed. > > It is fine for a end-entity certificate to be renewed with a > > different issuer. As a transitional measure the current issuer > > certificate can be added to the IPA trust store so that IPA-enrolled > > machines will trust it. > > > > If you wish to continue issing those EE certs with a dedicated > > sub-CA, create one with the 'ipa ca-add' command and use the > > Certmonger `--issuer' option to refer to it. > > > > Cheers, > > Fraser > > > > On Tue, Jun 11, 2019 at 02:53:57PM -0500, Allyson Bowles wrote: > > > Hey folks, > > > > > > Awhile back, I set up an internal CA signing certificate for the purpose > > > of issuing certificates used for RabbitMQ connections, Sensu, Consul, > > > etc. I would now like to add that signing certificate to my existing > > > Dogtag instance (created as part of an IPA server installation), so that > > > I can configure clients to automatically renew these certificates using > > > Certmonger. This signing certificate would not be used for anything IPA > > > related, only the abovementioned third-party utilities requiring an > > > internally trusted SSL certificate for authentication. > > > > > > I have managed to perform the pkispawn step using a PKCS12 file > > > containing the signing certificate and key as well as a pkispawn config > > > file that looks something like this: > > > > > > #### > > > [DEFAULT] > > > pki_instance_name=pki-tomcat > > > pki_admin_password=secret > > > pki_client_pkcs12_password=secret > > > pki_ds_password=secret > > > pki_ds_ldap_port=389 > > > pki_existing=True > > > > > > [CA] > > > pki_ca_signing_nickname=MyInternalCA > > > pki_ca_signing_csr_path=req/ca.csr > > > pki_pkcs12_path=ca.p12 > > > pki_pkcs12_password=secret > > > pki_serial_number_range_start=90 > > > pki_request_number_range_start=90 > > > pki_master_crl_enable=False > > > pki_external_step_one=False > > > pki_external_step_two=True > > > ### > > > > > > The output I get is as follows: > > > > > > ``` > > > # pkispawn -s CA -f pkispawn.cfg > > > Log file: /var/log/pki/pki-ca-spawn.20190611180347.log > > > Loading deployment configuration from pkispawn.cfg. > > > Installing CA into /var/lib/pki/pki-tomcat. > > > --------------- > > > Import complete > > > --------------- > > > > > > Installation failed: > > > com.netscape.certsrv.base.BadRequestException: System is already > > > configured > > > > > > Please check the CA logs in /var/log/pki/pki-tomcat/ca. > > > ``` > > > > > > The pki-ca-spawn logfile doesn't contain anything interesting, and > > > neither could I find anything terribly noteworthy in either > > > /var/log/pki/pki-tomcat/ca/{debug,system}. > > > > > > The certificate and key do show up in certutil -L and -K, so my plan was > > > to try carrying on with getting a client to use Certmonger to renew its > > > certificate against this signing certificate. To do /that/, it looks > > > like I need to create or modify an existing CA profile per > > > https://www.dogtagpki.org/wiki/PKI_CA_Profile_CLI. However, this doc > > > expects the operator to have a user certificate with the nickname > > > 'caadmin' and a password. I don't seem to have a certificate with that > > > nickname and I'm not sure which certificate to look for. Further > > > documentation > > > https://www.dogtagpki.org/wiki/CA_Admin_Setup#Retrieving_CA_Admin_Certificate > > > suggests that I could create a new CA admin user...but this requires > > > having access to the existing one. > > > > > > Which brings us to my actual questions. > > > > > > 1) Am I trying to do a reasonable thing by importing an existing signing > > > certificate into an existing Dogtag instance? If not, what's a better > > > way to achieve the ability to autorenew client certificates? > > > > > > 2) How can I either reset the existing CA admin credentials (given that > > > I have system root) or force creation of a new user without nuking my > > > current instance? Ideas about where I could look for the existing CA > > > admin credentials would work as well but I understand this is highly > > > dependent on how the system was set up initially. > > > > > > 3) Is there something else I should be doing, after the pkispawn partial > > > failure, to troubleshoot? I figured attempting to carry on with an > > > autorenew might at least get me more information about what's happening, > > > but I'm very open to other approaches as well. > > > > > > Thank you for your time, > > > Ally > > > > > > -- > > > Allyson Bowles | Senior Site Reliability Engineer > > > e: abowles at hireology.com | 7C2D 671B 08A2 0D8A AD52 540E 1FB2 B534 ECD5 4608 > > > http://www.hireology.com > > > > > > > > > _______________________________________________ > > > Pki-users mailing list > > > Pki-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-users > > > > -- > Allyson Bowles | Senior Site Reliability Engineer > e: abowles at hireology.com | 7C2D 671B 08A2 0D8A AD52 540E 1FB2 B534 ECD5 4608 > http://www.hireology.com From Stefan.Goeman at dnvgl.com Mon Jun 17 12:30:22 2019 From: Stefan.Goeman at dnvgl.com (Goeman, Stefan) Date: Mon, 17 Jun 2019 12:30:22 +0000 Subject: [Pki-users] CRL Distribution Points Message-ID: Hello, Is it possible with the dogtag PKI to issue certificates have contain a CRL Distribution Point certificate extension? I would like to work with a CRL web server, instead of using OCSP. Much thanks in advance for your feedback! Greetings, Stefan Goeman ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stefan.Goeman at dnvgl.com Mon Jun 17 12:31:02 2019 From: Stefan.Goeman at dnvgl.com (Goeman, Stefan) Date: Mon, 17 Jun 2019 12:31:02 +0000 Subject: [Pki-users] EST certificate enrollment Message-ID: Hello, Is there any chance that the dogtag PKI will support the EST (Enrollment over Secure Transport) certificate enrollment protocol? Much thanks in advance for your feedback! Greetings, Stefan Goeman ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Mon Jun 17 13:39:25 2019 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 17 Jun 2019 23:39:25 +1000 Subject: [Pki-users] CRL Distribution Points In-Reply-To: References: Message-ID: <20190617133925.GU3547@T470s> On Mon, Jun 17, 2019 at 12:30:22PM +0000, Goeman, Stefan wrote: > Hello, > > Is it possible with the dogtag PKI to issue certificates have contain a CRL Distribution Point certificate extension? > I would like to work with a CRL web server, instead of using OCSP. > > Much thanks in advance for your feedback! > > Greetings, > Stefan Goeman > Hi Stefan, Yes, Dogtag supports CRL Distribution Point extension. Example profile configuration: policyset.serverCertSet.9.constraint.class_id=noConstraintImpl policyset.serverCertSet.9.constraint.name=No Constraint policyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl policyset.serverCertSet.9.default.name=CRL Distribution Points Extension Default policyset.serverCertSet.9.default.params.crlDistPointsCritical=false policyset.serverCertSet.9.default.params.crlDistPointsNum=1 policyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate Authority,o=ipaca policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://example.com/ipa/crl/MasterCRL.bin policyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName policyset.serverCertSet.9.default.params.crlDistPointsReasons_0= Hope that helps! Fraser From Stefan.Goeman at dnvgl.com Wed Jun 19 14:48:02 2019 From: Stefan.Goeman at dnvgl.com (Goeman, Stefan) Date: Wed, 19 Jun 2019 14:48:02 +0000 Subject: [Pki-users] scep certificate enrollment Message-ID: Hello, I want to use SCEP certificate enrollment with dogtag PKI. I know more or less how to enable this. However, in the dogtag PKI system there are so many certificate profiles enabled by default. How do I know which certificate profile will be used with SCEP? Or, are these two things unrelated? Much thanks in advance for your feedback! Greetings, Stefan ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From msauton at redhat.com Wed Jun 19 15:43:49 2019 From: msauton at redhat.com (Marc Sauton) Date: Wed, 19 Jun 2019 08:43:49 -0700 Subject: [Pki-users] scep certificate enrollment In-Reply-To: References: Message-ID: it should be caRouterCert see this on-line doc: https://www.dogtagpki.org/wiki/SCEP_Setup /var/lib/pki/pki-tomcat/ca/profiles/ca/caRouterCert.cfg profile configuration may appear somehow confusing at first, that has been a trade off for being very flexible. Thanks, M. On Wed, Jun 19, 2019 at 7:49 AM Goeman, Stefan wrote: > Hello, > > > > I want to use SCEP certificate enrollment with dogtag PKI. I know more or > less how to enable this. > > However, in the dogtag PKI system there are so many certificate profiles > enabled by default. > > How do I know which certificate profile will be used with SCEP? > > Or, are these two things unrelated? > > > > Much thanks in advance for your feedback! > > > > Greetings, > > Stefan > > > > > ************************************************************************************** > This e-mail and any attachments thereto may contain confidential > information and/or information protected by intellectual property rights > for the exclusive attention of the intended addressees named above. If you > have received this transmission in error, please immediately notify the > sender by return e-mail and delete this message and its attachments. > Unauthorized use, copying or further full or partial distribution of this > e-mail or its contents is prohibited. > > ************************************************************************************** > _______________________________________________ > 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 cfu at redhat.com Wed Jun 19 16:30:06 2019 From: cfu at redhat.com (Christina Fu) Date: Wed, 19 Jun 2019 09:30:06 -0700 Subject: [Pki-users] CRL Distribution Points In-Reply-To: <20190617133925.GU3547@T470s> References: <20190617133925.GU3547@T470s> Message-ID: Hi, We also welcome feedback to our documentation: https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/administration_guide/index#CRL_Distribution_Points_Extension_Default thanks, Christina On Mon, Jun 17, 2019 at 6:40 AM Fraser Tweedale wrote: > On Mon, Jun 17, 2019 at 12:30:22PM +0000, Goeman, Stefan wrote: > > Hello, > > > > Is it possible with the dogtag PKI to issue certificates have contain a > CRL Distribution Point certificate extension? > > I would like to work with a CRL web server, instead of using OCSP. > > > > Much thanks in advance for your feedback! > > > > Greetings, > > Stefan Goeman > > > Hi Stefan, > > Yes, Dogtag supports CRL Distribution Point extension. Example > profile configuration: > > policyset.serverCertSet.9.constraint.class_id=noConstraintImpl > policyset.serverCertSet.9.constraint.name=No Constraint > > policyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl > policyset.serverCertSet.9.default.name=CRL Distribution Points Extension > Default > policyset.serverCertSet.9.default.params.crlDistPointsCritical=false > policyset.serverCertSet.9.default.params.crlDistPointsNum=1 > policyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate > Authority,o=ipaca > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0= > http://example.com/ipa/crl/MasterCRL.bin > policyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName > policyset.serverCertSet.9.default.params.crlDistPointsReasons_0= > > Hope that helps! > Fraser > > _______________________________________________ > 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 cfu at redhat.com Wed Jun 19 16:32:31 2019 From: cfu at redhat.com (Christina Fu) Date: Wed, 19 Jun 2019 09:32:31 -0700 Subject: [Pki-users] scep certificate enrollment In-Reply-To: References: Message-ID: Hi, We welcome feedback to our documentation: https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/administration_guide/index#Enrolling_a_Certificate_in_a_Cisco_Router thanks, Christina On Wed, Jun 19, 2019 at 8:44 AM Marc Sauton wrote: > it should be > caRouterCert > see this on-line doc: > https://www.dogtagpki.org/wiki/SCEP_Setup > /var/lib/pki/pki-tomcat/ca/profiles/ca/caRouterCert.cfg > profile configuration may appear somehow confusing at first, that has been > a trade off for being very flexible. > Thanks, > M. > > > On Wed, Jun 19, 2019 at 7:49 AM Goeman, Stefan > wrote: > >> Hello, >> >> >> >> I want to use SCEP certificate enrollment with dogtag PKI. I know more or >> less how to enable this. >> >> However, in the dogtag PKI system there are so many certificate profiles >> enabled by default. >> >> How do I know which certificate profile will be used with SCEP? >> >> Or, are these two things unrelated? >> >> >> >> Much thanks in advance for your feedback! >> >> >> >> Greetings, >> >> Stefan >> >> >> >> >> ************************************************************************************** >> This e-mail and any attachments thereto may contain confidential >> information and/or information protected by intellectual property rights >> for the exclusive attention of the intended addressees named above. If you >> have received this transmission in error, please immediately notify the >> sender by return e-mail and delete this message and its attachments. >> Unauthorized use, copying or further full or partial distribution of this >> e-mail or its contents is prohibited. >> >> ************************************************************************************** >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Wed Jun 19 16:39:46 2019 From: cfu at redhat.com (Christina Fu) Date: Wed, 19 Jun 2019 09:39:46 -0700 Subject: [Pki-users] EST certificate enrollment In-Reply-To: References: Message-ID: Hi, AFAIK, there is no immediate plan to support EST. We do go over RFEs periodically and find ones that provide convincing reasons to discuss. We encourage people to do that. thanks, Christina On Mon, Jun 17, 2019 at 5:32 AM Goeman, Stefan wrote: > Hello, > > > > > > Is there any chance that the dogtag PKI will support the EST (Enrollment > over Secure Transport) certificate enrollment protocol? > > > > Much thanks in advance for your feedback! > > > > Greetings, > > Stefan Goeman > > > ************************************************************************************** > This e-mail and any attachments thereto may contain confidential > information and/or information protected by intellectual property rights > for the exclusive attention of the intended addressees named above. If you > have received this transmission in error, please immediately notify the > sender by return e-mail and delete this message and its attachments. > Unauthorized use, copying or further full or partial distribution of this > e-mail or its contents is prohibited. > > ************************************************************************************** > _______________________________________________ > 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 cfu at redhat.com Wed Jun 19 17:10:40 2019 From: cfu at redhat.com (Christina Fu) Date: Wed, 19 Jun 2019 10:10:40 -0700 Subject: [Pki-users] EST certificate enrollment In-Reply-To: References: Message-ID: btw, for your convenience, here is where you could search for existing issues and file for new ones: https://pagure.io/dogtagpki/issues Note, the "search" box is under "Filter". When filing for non-bug features, I believe the convention is to begin the issue Title with "RFE: ", e.g. "RFE: EST Enrollment protocol support". In the comment area, try to supply as much reasons as you could to support your feature request. regards, Christina On Wed, Jun 19, 2019 at 9:39 AM Christina Fu wrote: > Hi, > AFAIK, there is no immediate plan to support EST. We do go over RFEs > periodically and find ones that provide convincing reasons to discuss. We > encourage people to do that. > > thanks, > Christina > > On Mon, Jun 17, 2019 at 5:32 AM Goeman, Stefan > wrote: > >> Hello, >> >> >> >> >> >> Is there any chance that the dogtag PKI will support the EST (Enrollment >> over Secure Transport) certificate enrollment protocol? >> >> >> >> Much thanks in advance for your feedback! >> >> >> >> Greetings, >> >> Stefan Goeman >> >> >> ************************************************************************************** >> This e-mail and any attachments thereto may contain confidential >> information and/or information protected by intellectual property rights >> for the exclusive attention of the intended addressees named above. If you >> have received this transmission in error, please immediately notify the >> sender by return e-mail and delete this message and its attachments. >> Unauthorized use, copying or further full or partial distribution of this >> e-mail or its contents is prohibited. >> >> ************************************************************************************** >> _______________________________________________ >> 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: