Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates
On Thu, May 26, 2016 at 12:08:11PM +0200, Youenn PIOLET wrote: > Hi there, > > For your information : > I just realised today that the certificate signing using web interface was > still broken. > > I've got 3 caIPAserviceCert.cfg files on my system : > > Locate caIPAserviceCert.cfg output > 1. New profile : /usr/share/ipa/profiles/caIPAserviceCert.cfg > 2. Old broken profile : /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg > 3. Old broken profile : > /var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg > LDAP profile version was not OK, back to the older version of profile. I > fixed it back. > > FreeIPA since v4.2 configures Dogtag to use the LDAPProfileSubsystem > > which stores profile configuration in LDAP. > > > > I think my Dogtag (in IPA web interface) was still using the files (and > replacing the LDAP entry after a while? Or did it happen when a added a new > replica?). > Yes - installing a new replica will re-clobber the profile configuration. Patches to fix the problem are merged upstream and will make their way into an upcoming bugfix release. Thanks, Fraser -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates
Hi there, For your information : I just realised today that the certificate signing using web interface was still broken. I've got 3 caIPAserviceCert.cfg files on my system : Locate caIPAserviceCert.cfg output 1. New profile : /usr/share/ipa/profiles/caIPAserviceCert.cfg 2. Old broken profile : /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg 3. Old broken profile : /var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg LDAP profile version was not OK, back to the older version of profile. I fixed it back. FreeIPA since v4.2 configures Dogtag to use the LDAPProfileSubsystem > which stores profile configuration in LDAP. > I think my Dogtag (in IPA web interface) was still using the files (and replacing the LDAP entry after a while? Or did it happen when a added a new replica?). I've replaced : 2. /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg 3. /var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg with new profile versions. Now everything works, including the web interface. I'll let you know if my profile got changed back again in LDAP after a while, but I guess now I replaced the files there are no risks. I wonder if Thanks again for your previous help Fraser, I hope these information may help you finding the bug that could be related to replica installation with old profiles still present in master filesystem. Cheers, -- Youenn Piolet piole...@gmail.com 2016-05-10 16:23 GMT+02:00 Youenn PIOLET : > Thank you so much Fraser, > My PKI is now working perfectly! > > Cheers > > -- > Youenn Piolet > piole...@gmail.com > > > 2016-05-10 15:01 GMT+02:00 Fraser Tweedale : > >> On Tue, May 10, 2016 at 02:33:43PM +0200, Youenn PIOLET wrote: >> > Hi Fraser, thanks a lot for your quick reply! >> > >> > Could you confirm whether you are on RHEL / CentOS 7.2, and if so, >> > > whether it was installed at 7.2 or an upgrade from 7.1 or an earlier >> > > version? >> > > >> > >> > This is a replica that was previously installed in CentOS 7.1. >> > I don't exactly remember but I think I used COPR repository to install >> > FreeIPA 4.2 and then upgraded CentOS to 7.2. >> > >> > Also, I remember my pki got broken after upgrading this replica in 7.2. >> I >> > had to renew the replica's certificate and force-sync to successfully >> > launch pki-tomcatd. Now this replica is my pki master. >> > >> Thanks for the background. Every piece of evidence can help find >> the bug :) >> >> > >> > > > ### certprofile >> > > > $ ipa certprofile-show --out caIPAserviceCert.cfg caIPAserviceCert >> > > > --- >> > > > Profile configuration stored in file 'caIPAserviceCert.cfg' >> > > > --- >> > > > Profile ID: caIPAserviceCert >> > > > Profile description: Standard profile for network services >> > > > Store issued certificates: TRUE >> > > > >> > > You do not include the caIPAserviceCert.cfg in the diffs below, >> > > however, I suspect you will find it to be identical to >> > > /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg. Could you >> > > please confirm this? >> > > >> > >> > Ah true... I did not realised I was actually writing a new file! >> > And you're right, diff is the same (except 2 profileId/classId lignes >> that >> > don't exist in template + enableBy that differs) >> > >> > FreeIPA since v4.2 configures Dogtag to use the LDAPProfileSubsystem >> > > which stores profile configuration in LDAP. The file output by the >> > > ``ipa certprofile-show`` command will have come from LDAP; this is >> > > the version that's actually in use in your IPA installation. >> > > >> > >> > Thanks a lot for your answers. >> > >> > So now, what would you suggest me to do? >> > Replace my /tmp/caIPAserviceCert.cfg with your suggested values and >> import >> > to LDAP ? >> > >> I'd recommend copying the IPA template from >> /usr/share/ipa/profiles/caIPAserviceCert.cfg, then filling out the >> params manually and updating the profile. There are four config >> params that require substitutions; fill them out like below: >> >> - policyset.serverCertSet.1.default.params.name=CN=$ >> request.req_subject_name.cn$, o=YOUR-DOMAIN >> >> (note the SINGLE '$'s; they are double '$$' in the template) >> >> - policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0= >> http://ipa-ca.YOUR-DOMAIN/ca/ocsp >> >> - >> policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate >> Authority,o=ipaca >> >> - policyset.serverCertSet.9.default.params.crlDistPointsPointName_0= >> http://ipa-ca.YOUR-DOMAIN/ipa/crl/MasterCRL.bin >> >> Leave other values unchanged. Import the updated profile by >> running: >> >> ipa certprofile-mod caIPAserviceCert --file new.cfg >> >> Then certificates should be issued as expected. >> >> Cheers, >> Fraser >> >> >> > Cheers, >> > >> > >> > > > And a diff between them : >> > > > >> > > > $ diff /usr/share/ipa/profiles/caIPAserviceCert.cfg >> > > > /usr/sh
Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates
Thank you so much Fraser, My PKI is now working perfectly! Cheers -- Youenn Piolet piole...@gmail.com 2016-05-10 15:01 GMT+02:00 Fraser Tweedale : > On Tue, May 10, 2016 at 02:33:43PM +0200, Youenn PIOLET wrote: > > Hi Fraser, thanks a lot for your quick reply! > > > > Could you confirm whether you are on RHEL / CentOS 7.2, and if so, > > > whether it was installed at 7.2 or an upgrade from 7.1 or an earlier > > > version? > > > > > > > This is a replica that was previously installed in CentOS 7.1. > > I don't exactly remember but I think I used COPR repository to install > > FreeIPA 4.2 and then upgraded CentOS to 7.2. > > > > Also, I remember my pki got broken after upgrading this replica in 7.2. I > > had to renew the replica's certificate and force-sync to successfully > > launch pki-tomcatd. Now this replica is my pki master. > > > Thanks for the background. Every piece of evidence can help find > the bug :) > > > > > > > ### certprofile > > > > $ ipa certprofile-show --out caIPAserviceCert.cfg caIPAserviceCert > > > > --- > > > > Profile configuration stored in file 'caIPAserviceCert.cfg' > > > > --- > > > > Profile ID: caIPAserviceCert > > > > Profile description: Standard profile for network services > > > > Store issued certificates: TRUE > > > > > > > You do not include the caIPAserviceCert.cfg in the diffs below, > > > however, I suspect you will find it to be identical to > > > /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg. Could you > > > please confirm this? > > > > > > > Ah true... I did not realised I was actually writing a new file! > > And you're right, diff is the same (except 2 profileId/classId lignes > that > > don't exist in template + enableBy that differs) > > > > FreeIPA since v4.2 configures Dogtag to use the LDAPProfileSubsystem > > > which stores profile configuration in LDAP. The file output by the > > > ``ipa certprofile-show`` command will have come from LDAP; this is > > > the version that's actually in use in your IPA installation. > > > > > > > Thanks a lot for your answers. > > > > So now, what would you suggest me to do? > > Replace my /tmp/caIPAserviceCert.cfg with your suggested values and > import > > to LDAP ? > > > I'd recommend copying the IPA template from > /usr/share/ipa/profiles/caIPAserviceCert.cfg, then filling out the > params manually and updating the profile. There are four config > params that require substitutions; fill them out like below: > > - policyset.serverCertSet.1.default.params.name=CN=$ > request.req_subject_name.cn$, o=YOUR-DOMAIN > > (note the SINGLE '$'s; they are double '$$' in the template) > > - policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0= > http://ipa-ca.YOUR-DOMAIN/ca/ocsp > > - > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate > Authority,o=ipaca > > - policyset.serverCertSet.9.default.params.crlDistPointsPointName_0= > http://ipa-ca.YOUR-DOMAIN/ipa/crl/MasterCRL.bin > > Leave other values unchanged. Import the updated profile by > running: > > ipa certprofile-mod caIPAserviceCert --file new.cfg > > Then certificates should be issued as expected. > > Cheers, > Fraser > > > > Cheers, > > > > > > > > And a diff between them : > > > > > > > > $ diff /usr/share/ipa/profiles/caIPAserviceCert.cfg > > > > /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg > > > > 1,2d0 > > > > < profileId=caIPAserviceCert > > > > < classId=caEnrollImpl > > > > 15c13 > > > > < policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11 > > > > --- > > > > > policyset.serverCertSet.list=1,2,3,4,5,6,7,8 > > > > 22c20 > > > > < policyset.serverCertSet.1.default.params.name=CN=$$ > > > > request.req_subject_name.cn$$, $SUBJECT_DN_O > > > > --- > > > > > policyset.serverCertSet.1.default.params.name=CN=$ > > > > request.req_subject_name.cn$, OU=pki-ipa, O=IPA > > > > 48c46 > > > > < > > > > > > > > policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http:// > > > > $IPA_CA_RECORD.$DOMAIN/ca/ocsp > > > > --- > > > > > > policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0= > > > > 95,97c93,95 > > > > < > > > > > > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER > > > > < > > > > > > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName > > > > < > > > > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http:// > > > > $IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin > > > > --- > > > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0= > > > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0= > > > > > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0= > > > > https://ipa.example.com/ipa/crl/MasterCRL.bin > > > > 100,109d97 > > > > < policyset.serverCertSet.10.constraint.class_id=noConstraintImpl > > > > < policyset.s
Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates
On Tue, May 10, 2016 at 02:33:43PM +0200, Youenn PIOLET wrote: > Hi Fraser, thanks a lot for your quick reply! > > Could you confirm whether you are on RHEL / CentOS 7.2, and if so, > > whether it was installed at 7.2 or an upgrade from 7.1 or an earlier > > version? > > > > This is a replica that was previously installed in CentOS 7.1. > I don't exactly remember but I think I used COPR repository to install > FreeIPA 4.2 and then upgraded CentOS to 7.2. > > Also, I remember my pki got broken after upgrading this replica in 7.2. I > had to renew the replica's certificate and force-sync to successfully > launch pki-tomcatd. Now this replica is my pki master. > Thanks for the background. Every piece of evidence can help find the bug :) > > > > ### certprofile > > > $ ipa certprofile-show --out caIPAserviceCert.cfg caIPAserviceCert > > > --- > > > Profile configuration stored in file 'caIPAserviceCert.cfg' > > > --- > > > Profile ID: caIPAserviceCert > > > Profile description: Standard profile for network services > > > Store issued certificates: TRUE > > > > > You do not include the caIPAserviceCert.cfg in the diffs below, > > however, I suspect you will find it to be identical to > > /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg. Could you > > please confirm this? > > > > Ah true... I did not realised I was actually writing a new file! > And you're right, diff is the same (except 2 profileId/classId lignes that > don't exist in template + enableBy that differs) > > FreeIPA since v4.2 configures Dogtag to use the LDAPProfileSubsystem > > which stores profile configuration in LDAP. The file output by the > > ``ipa certprofile-show`` command will have come from LDAP; this is > > the version that's actually in use in your IPA installation. > > > > Thanks a lot for your answers. > > So now, what would you suggest me to do? > Replace my /tmp/caIPAserviceCert.cfg with your suggested values and import > to LDAP ? > I'd recommend copying the IPA template from /usr/share/ipa/profiles/caIPAserviceCert.cfg, then filling out the params manually and updating the profile. There are four config params that require substitutions; fill them out like below: - policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, o=YOUR-DOMAIN (note the SINGLE '$'s; they are double '$$' in the template) - policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.YOUR-DOMAIN/ca/ocsp - policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate Authority,o=ipaca - policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://ipa-ca.YOUR-DOMAIN/ipa/crl/MasterCRL.bin Leave other values unchanged. Import the updated profile by running: ipa certprofile-mod caIPAserviceCert --file new.cfg Then certificates should be issued as expected. Cheers, Fraser > Cheers, > > > > > And a diff between them : > > > > > > $ diff /usr/share/ipa/profiles/caIPAserviceCert.cfg > > > /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg > > > 1,2d0 > > > < profileId=caIPAserviceCert > > > < classId=caEnrollImpl > > > 15c13 > > > < policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11 > > > --- > > > > policyset.serverCertSet.list=1,2,3,4,5,6,7,8 > > > 22c20 > > > < policyset.serverCertSet.1.default.params.name=CN=$$ > > > request.req_subject_name.cn$$, $SUBJECT_DN_O > > > --- > > > > policyset.serverCertSet.1.default.params.name=CN=$ > > > request.req_subject_name.cn$, OU=pki-ipa, O=IPA > > > 48c46 > > > < > > > > > policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http:// > > > $IPA_CA_RECORD.$DOMAIN/ca/ocsp > > > --- > > > > policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0= > > > 95,97c93,95 > > > < > > > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER > > > < > > > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName > > > < > > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http:// > > > $IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin > > > --- > > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0= > > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0= > > > > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0= > > > https://ipa.example.com/ipa/crl/MasterCRL.bin > > > 100,109d97 > > > < policyset.serverCertSet.10.constraint.class_id=noConstraintImpl > > > < policyset.serverCertSet.10.constraint.name=No Constraint > > > < > > > > > policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl > > > < policyset.serverCertSet.10.default.name=Subject Key Identifier > > Extension > > > Default > > > < policyset.serverCertSet.10.default.params.critical=false > > > < policyset.serverCertSet.11.constraint.class_id=noConstraintImpl > > > < policy
Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates
Hi Fraser, thanks a lot for your quick reply! Could you confirm whether you are on RHEL / CentOS 7.2, and if so, > whether it was installed at 7.2 or an upgrade from 7.1 or an earlier > version? > This is a replica that was previously installed in CentOS 7.1. I don't exactly remember but I think I used COPR repository to install FreeIPA 4.2 and then upgraded CentOS to 7.2. Also, I remember my pki got broken after upgrading this replica in 7.2. I had to renew the replica's certificate and force-sync to successfully launch pki-tomcatd. Now this replica is my pki master. > > ### certprofile > > $ ipa certprofile-show --out caIPAserviceCert.cfg caIPAserviceCert > > --- > > Profile configuration stored in file 'caIPAserviceCert.cfg' > > --- > > Profile ID: caIPAserviceCert > > Profile description: Standard profile for network services > > Store issued certificates: TRUE > > > You do not include the caIPAserviceCert.cfg in the diffs below, > however, I suspect you will find it to be identical to > /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg. Could you > please confirm this? > Ah true... I did not realised I was actually writing a new file! And you're right, diff is the same (except 2 profileId/classId lignes that don't exist in template + enableBy that differs) FreeIPA since v4.2 configures Dogtag to use the LDAPProfileSubsystem > which stores profile configuration in LDAP. The file output by the > ``ipa certprofile-show`` command will have come from LDAP; this is > the version that's actually in use in your IPA installation. > Thanks a lot for your answers. So now, what would you suggest me to do? Replace my /tmp/caIPAserviceCert.cfg with your suggested values and import to LDAP ? Cheers, > > And a diff between them : > > > > $ diff /usr/share/ipa/profiles/caIPAserviceCert.cfg > > /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg > > 1,2d0 > > < profileId=caIPAserviceCert > > < classId=caEnrollImpl > > 15c13 > > < policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11 > > --- > > > policyset.serverCertSet.list=1,2,3,4,5,6,7,8 > > 22c20 > > < policyset.serverCertSet.1.default.params.name=CN=$$ > > request.req_subject_name.cn$$, $SUBJECT_DN_O > > --- > > > policyset.serverCertSet.1.default.params.name=CN=$ > > request.req_subject_name.cn$, OU=pki-ipa, O=IPA > > 48c46 > > < > > > policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http:// > > $IPA_CA_RECORD.$DOMAIN/ca/ocsp > > --- > > > policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0= > > 95,97c93,95 > > < > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER > > < > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName > > < > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http:// > > $IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin > > --- > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0= > > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0= > > > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0= > > https://ipa.example.com/ipa/crl/MasterCRL.bin > > 100,109d97 > > < policyset.serverCertSet.10.constraint.class_id=noConstraintImpl > > < policyset.serverCertSet.10.constraint.name=No Constraint > > < > > > policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl > > < policyset.serverCertSet.10.default.name=Subject Key Identifier > Extension > > Default > > < policyset.serverCertSet.10.default.params.critical=false > > < policyset.serverCertSet.11.constraint.class_id=noConstraintImpl > > < policyset.serverCertSet.11.constraint.name=No Constraint > > < policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl > > < policyset.serverCertSet.11.default.name=User Supplied Extension > Default > > < policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 > > > > Thanks by advance for your support, > > Regards > > > > -- > > Youenn Piolet > > piole...@gmail.com > > > > > > 2016-03-31 9:41 GMT+02:00 Fraser Tweedale : > > > > > On Sun, Mar 27, 2016 at 09:14:47PM +0200, Martin Štefany wrote: > > > > Hello, > > > > > > > > I seem to be having some issues with IPA CA feature not generating > > > > certificates with DNS SubjectAltNames. > > > > > > > > I'm sure this worked very well under CentOS 7.1 / IPA 4.0, but now > under > > > > CentOS 7.2 / IPA 4.2 something's different. > > > > > > > > Here are the original steps which worked fine for my first use case > :: > > > > > > > > $ ipa dnsrecord-add example.com mail --a-ip=172.17.100.25 > > > > $ ipa host-add mail.example.com > > > > $ ipa service-add smtp/mail.example.com > > > > $ ipa service-add smtp/mail1.example.com > > > > $ ipa service-add-host smtp/mail.example.com --hosts= > mail1.example.com > > > > $ ipa-getcert request -k /etc/pki/tls/private/postfix.key \ > > > >
Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates
On Tue, May 10, 2016 at 11:51:26AM +0200, Youenn PIOLET wrote: > Hi Fraser, Martin, > > I've got exactly the same problem with no DNS AltName and OU=pki-ipa,O=IPA > in the subject. > Hi Youenn, I'm currently investigating this issue; the state of the system is clear but I'm still trying to work out how it gets there. Could you confirm whether you are on RHEL / CentOS 7.2, and if so, whether it was installed at 7.2 or an upgrade from 7.1 or an earlier version? Further commentary below. > ### certprofile > $ ipa certprofile-show --out caIPAserviceCert.cfg caIPAserviceCert > --- > Profile configuration stored in file 'caIPAserviceCert.cfg' > --- > Profile ID: caIPAserviceCert > Profile description: Standard profile for network services > Store issued certificates: TRUE > You do not include the caIPAserviceCert.cfg in the diffs below, however, I suspect you will find it to be identical to /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg. Could you please confirm this? > > ### My /etc/pki/pki-tomcat/ca/CS.cfg : > http://pastebin.com/wnVWH8bq > Thanks for sharing; everything looks fine here. > ### caIPAserviceCert > I'd like to send you my caIPAserviceCert.cfg, two of them are present on my > system: > > - /usr/share/ipa/profiles/caIPAserviceCert.cfg : > http://pastebin.com/byddqgSF > (The rest of my reply is just an FYI on where FreeIPA/Dogtag stores profile configurtion.) Profile configurations in /usr/share/ipa/profiles/ are templates owned by IPA, with placeholders that get filled out when IPA imports the profile. > - /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg : > http://pastebin.com/FFUTytDq > Profiles stored here are the default profiles added to a Dogtag instance, however, the files at these locations are not used by running instances. But wait, there's more! You should also find /var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg. This one is used by Dogtag if the file-based ProfileSubsystem is used. FreeIPA since v4.2 configures Dogtag to use the LDAPProfileSubsystem which stores profile configuration in LDAP. The file output by the ``ipa certprofile-show`` command will have come from LDAP; this is the version that's actually in use in your IPA installation. Cheers, Fraser > And a diff between them : > > $ diff /usr/share/ipa/profiles/caIPAserviceCert.cfg > /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg > 1,2d0 > < profileId=caIPAserviceCert > < classId=caEnrollImpl > 15c13 > < policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11 > --- > > policyset.serverCertSet.list=1,2,3,4,5,6,7,8 > 22c20 > < policyset.serverCertSet.1.default.params.name=CN=$$ > request.req_subject_name.cn$$, $SUBJECT_DN_O > --- > > policyset.serverCertSet.1.default.params.name=CN=$ > request.req_subject_name.cn$, OU=pki-ipa, O=IPA > 48c46 > < > policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http:// > $IPA_CA_RECORD.$DOMAIN/ca/ocsp > --- > > policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0= > 95,97c93,95 > < > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER > < > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName > < policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http:// > $IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin > --- > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0= > > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0= > > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0= > https://ipa.example.com/ipa/crl/MasterCRL.bin > 100,109d97 > < policyset.serverCertSet.10.constraint.class_id=noConstraintImpl > < policyset.serverCertSet.10.constraint.name=No Constraint > < > policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl > < policyset.serverCertSet.10.default.name=Subject Key Identifier Extension > Default > < policyset.serverCertSet.10.default.params.critical=false > < policyset.serverCertSet.11.constraint.class_id=noConstraintImpl > < policyset.serverCertSet.11.constraint.name=No Constraint > < policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl > < policyset.serverCertSet.11.default.name=User Supplied Extension Default > < policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 > > Thanks by advance for your support, > Regards > > -- > Youenn Piolet > piole...@gmail.com > > > 2016-03-31 9:41 GMT+02:00 Fraser Tweedale : > > > On Sun, Mar 27, 2016 at 09:14:47PM +0200, Martin Štefany wrote: > > > Hello, > > > > > > I seem to be having some issues with IPA CA feature not generating > > > certificates with DNS SubjectAltNames. > > > > > > I'm sure this worked very well under CentOS 7.1 / IPA 4.0, but now under > > > CentOS 7.2 / IPA 4.2 something's different. > > > > > > Here are the original steps which worked fine for my first use case :: > >
Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates
Hi Fraser, Martin, I've got exactly the same problem with no DNS AltName and OU=pki-ipa,O=IPA in the subject. ### certprofile $ ipa certprofile-show --out caIPAserviceCert.cfg caIPAserviceCert --- Profile configuration stored in file 'caIPAserviceCert.cfg' --- Profile ID: caIPAserviceCert Profile description: Standard profile for network services Store issued certificates: TRUE ### My /etc/pki/pki-tomcat/ca/CS.cfg : http://pastebin.com/wnVWH8bq ### caIPAserviceCert I'd like to send you my caIPAserviceCert.cfg, two of them are present on my system: - /usr/share/ipa/profiles/caIPAserviceCert.cfg : http://pastebin.com/byddqgSF - /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg : http://pastebin.com/FFUTytDq And a diff between them : $ diff /usr/share/ipa/profiles/caIPAserviceCert.cfg /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg 1,2d0 < profileId=caIPAserviceCert < classId=caEnrollImpl 15c13 < policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11 --- > policyset.serverCertSet.list=1,2,3,4,5,6,7,8 22c20 < policyset.serverCertSet.1.default.params.name=CN=$$ request.req_subject_name.cn$$, $SUBJECT_DN_O --- > policyset.serverCertSet.1.default.params.name=CN=$ request.req_subject_name.cn$, OU=pki-ipa, O=IPA 48c46 < policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http:// $IPA_CA_RECORD.$DOMAIN/ca/ocsp --- > policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0= 95,97c93,95 < policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER < policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName < policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http:// $IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin --- > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0= > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0= > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0= https://ipa.example.com/ipa/crl/MasterCRL.bin 100,109d97 < policyset.serverCertSet.10.constraint.class_id=noConstraintImpl < policyset.serverCertSet.10.constraint.name=No Constraint < policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl < policyset.serverCertSet.10.default.name=Subject Key Identifier Extension Default < policyset.serverCertSet.10.default.params.critical=false < policyset.serverCertSet.11.constraint.class_id=noConstraintImpl < policyset.serverCertSet.11.constraint.name=No Constraint < policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl < policyset.serverCertSet.11.default.name=User Supplied Extension Default < policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 Thanks by advance for your support, Regards -- Youenn Piolet piole...@gmail.com 2016-03-31 9:41 GMT+02:00 Fraser Tweedale : > On Sun, Mar 27, 2016 at 09:14:47PM +0200, Martin Štefany wrote: > > Hello, > > > > I seem to be having some issues with IPA CA feature not generating > > certificates with DNS SubjectAltNames. > > > > I'm sure this worked very well under CentOS 7.1 / IPA 4.0, but now under > > CentOS 7.2 / IPA 4.2 something's different. > > > > Here are the original steps which worked fine for my first use case :: > > > > $ ipa dnsrecord-add example.com mail --a-ip=172.17.100.25 > > $ ipa host-add mail.example.com > > $ ipa service-add smtp/mail.example.com > > $ ipa service-add smtp/mail1.example.com > > $ ipa service-add-host smtp/mail.example.com --hosts=mail1.example.com > > $ ipa-getcert request -k /etc/pki/tls/private/postfix.key \ > > -f /etc/pki/tls/certs/postfix.pem \ > > -N CN=mail1.example.com,O=EXAMPLE.COM \ > > -D mail1.example.com -D mail.example.com \ > > -K smtp/mail1.example.com > > (and repeat for every next member of the cluster...) > > > > After this, I would get certificate with something like :: > > $ sudo ipa-getcert list > > Number of certificates and requests being tracked: 3. > > Request ID '20150419153933': > > status: MONITORING > > stuck: no > > key pair storage: > > type=FILE,location='/etc/pki/tls/private/postfix.key' > > certificate: type=FILE,location='/etc/pki/tls/certs/postfix.pem' > > CA: IPA > > issuer: CN=Certificate Authority,O=EXAMPLE.COM > > subject: CN=mail1.example.com,O=EXAMPLE.COM > > expires: 2017-04-19 15:39:35 UTC > > dns: mail1.example.com,mail.example.com > > principal name: smtp/mail1.example@example.com > > key usage: > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > > > with Subject line in form of: 'CN=,O=EXAMPLE.COM' and 'dns' > > info line present. > > > > Suddenly, in the
Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates - private files
On 2016-03-31 11:56, Fraser Tweedale wrote: On Thu, Mar 31, 2016 at 09:49:20AM +0200, Martin Štefany wrote: Hello Fraser, here are the files for real, thank you for help. Martin Thanks Martin, So what appears to have happened is somehow the default profile `caIPAserviceCert`, which is shipped with Dogtag, was imported into LDAP instead of the version shipped with IPA. I do not know how this might have occurred - it will help to know the history of your installation e.g. was it a fresh install, upgrade from a Centos/RHEL 7.1, migration (ipa-replica-install) of an earlier version, etc. In any case, how to resolve? You can import a corrected version of the profile. I have attached an example config, but you should check it to make sure it is what you want; in particular check the following values: policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=EXAMPLE.COM policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://ipa-ca.example.com/ipa/crl/MasterCRL.bin policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate Authority,o=ipaca You can update the profile with the new profile data by executing: ipa certprofile-mod caIPAserviceCert --file=/path/to/caIPAserviceCert.cfg Hopefully this fixes the issue. A fallback suggestion: if the above command fails, and if `ipa certprofile-find` shows no objects, then you may be able to resolve the issue by setting, in `/etc/pki/pki-tomcat/ca/CS.cfg`: subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem and then running `ipa-server-upgrade` manually. I am on PTO tomorrow but look forward to learning on Monday how you fared. Others may be able to help in the meantime. Cheers, Fraser Hello Fraser, yes, that solves the issue. 'ipa certprofile-mod caIPAserviceCert --file=/path/to/caIPAserviceCert.cfg' was successful, and newly issued certificate is with correct attributes as before. # ipa-getcert request -k /etc/pki/tls/private/http.key -f /etc/pki/tls/certs/http.pem -N CN=$(hostname -f) -D $(hostname -f) -D www.example.com -K HTTP/$(hostname -f) # ipa-getcert list Number of certificates and requests being tracked: 1. Request ID '20160331113029': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/tls/private/http.key' certificate: type=FILE,location='/etc/pki/tls/certs/http.pem' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=http2.example.com,O=EXAMPLE.COM expires: 2018-04-01 11:30:33 UTC dns: http2.example.com,www.example.com principal name: HTTP/http2.example@example.com key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Great job! The history would be: - idmc1 was installed first on CentOS 7.1 as IPA 4.0 - replica file was created from this idmc1 and replica was provisioned as idmc2 again on CentOS 7.1 as IPA 4.0 - upon release of CentOS 7.2, idmc2 was "yum" upgraded to CentOS 7.2 / FreeIPA 4.2, everything was OK, so - idmc1 was "yum" upgraded to CentOS 7.2 / FreeIPA 4.2 - time flies... - recently I've created another replica file from idmc1 for idmc3 and replica idmc3 was provisioned on fresh CentOS 7.2 / IPA 4.2, and this might have been the moment when something got broken. :( - http1, http2, etc. were provisioned only after idmc3 was deployed Thank you for the steps! I will also mail you ipa-server install/upgrade logs from all three systems in separate mail, if you don't mind, to try to see what exactly happened. btw, after I executed 'ipa certprofile-mod caIPAserviceCert --file=/path/to/caIPAserviceCert.cfg', certmonger stopped to see/track all 'CN=*,OU=pki-ipa,O=IPA' certificates and reported 'Number of certificates and requests being tracked: 0.', but I was going to re-provision the certificates anyway. Enjoy your longer weekend! Regards, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates - private files
On Thu, Mar 31, 2016 at 09:49:20AM +0200, Martin Štefany wrote: > Hello Fraser, > > here are the files for real, thank you for help. > > Martin > Thanks Martin, So what appears to have happened is somehow the default profile `caIPAserviceCert`, which is shipped with Dogtag, was imported into LDAP instead of the version shipped with IPA. I do not know how this might have occurred - it will help to know the history of your installation e.g. was it a fresh install, upgrade from a Centos/RHEL 7.1, migration (ipa-replica-install) of an earlier version, etc. In any case, how to resolve? You can import a corrected version of the profile. I have attached an example config, but you should check it to make sure it is what you want; in particular check the following values: policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=EXAMPLE.COM policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://ipa-ca.example.com/ipa/crl/MasterCRL.bin policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate Authority,o=ipaca You can update the profile with the new profile data by executing: ipa certprofile-mod caIPAserviceCert --file=/path/to/caIPAserviceCert.cfg Hopefully this fixes the issue. A fallback suggestion: if the above command fails, and if `ipa certprofile-find` shows no objects, then you may be able to resolve the issue by setting, in `/etc/pki/pki-tomcat/ca/CS.cfg`: subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem and then running `ipa-server-upgrade` manually. I am on PTO tomorrow but look forward to learning on Monday how you fared. Others may be able to help in the meantime. Cheers, Fraser profileId=caIPAserviceCert classId=caEnrollImpl desc=This certificate profile is for enrolling server certificates with IPA-RA agent authentication. visible=false enable=true enableBy=admin auth.instance_id=raCertAuth name=IPA-RA Agent-Authenticated Server Certificate Enrollment input.list=i1,i2 input.i1.class_id=certReqInputImpl input.i2.class_id=submitterInfoInputImpl output.list=o1 output.o1.class_id=certOutputImpl policyset.list=serverCertSet policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11 policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.serverCertSet.1.constraint.name=Subject Name Constraint policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+ policyset.serverCertSet.1.constraint.params.accept=true policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl policyset.serverCertSet.1.default.name=Subject Name Default policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=EXAMPLE.COM policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl policyset.serverCertSet.2.constraint.name=Validity Constraint policyset.serverCertSet.2.constraint.params.range=740 policyset.serverCertSet.2.constraint.params.notBeforeCheck=false policyset.serverCertSet.2.constraint.params.notAfterCheck=false policyset.serverCertSet.2.default.class_id=validityDefaultImpl policyset.serverCertSet.2.default.name=Validity Default policyset.serverCertSet.2.default.params.range=731 policyset.serverCertSet.2.default.params.startTime=0 policyset.serverCertSet.3.constraint.class_id=keyConstraintImpl policyset.serverCertSet.3.constraint.name=Key Constraint policyset.serverCertSet.3.constraint.params.keyType=RSA policyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096 policyset.serverCertSet.3.default.class_id=userKeyDefaultImpl policyset.serverCertSet.3.default.name=Key Default policyset.serverCertSet.4.constraint.class_id=noConstraintImpl policyset.serverCertSet.4.constraint.name=No Constraint policyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl policyset.serverCertSet.4.default.name=Authority Key Identifier Default policyset.serverCertSet.5.constraint.class_id=noConstraintImpl policyset.serverCertSet.5.constraint.name=No Constraint policyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl policyset.serverCertSet.5.default.name=AIA Extension Default policyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true policyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp policyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1 policyset.serverCertSet.5.default.params.authInfoAccessCritical=false policyset.serverCertSet.5.default.params.authInfoAccessNumADs=1 policyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl policyset.serverCertSet.6.constraint.name=Key Usage Extension Constraint policyset.serverCertSet.6.constraint.params.keyUsageCritical=true policyset.serverCertSet.6.constraint.params.keyUsageDigitalSig
Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates
On Sun, Mar 27, 2016 at 09:14:47PM +0200, Martin Štefany wrote: > Hello, > > I seem to be having some issues with IPA CA feature not generating > certificates with DNS SubjectAltNames. > > I'm sure this worked very well under CentOS 7.1 / IPA 4.0, but now under > CentOS 7.2 / IPA 4.2 something's different. > > Here are the original steps which worked fine for my first use case :: > > $ ipa dnsrecord-add example.com mail --a-ip=172.17.100.25 > $ ipa host-add mail.example.com > $ ipa service-add smtp/mail.example.com > $ ipa service-add smtp/mail1.example.com > $ ipa service-add-host smtp/mail.example.com --hosts=mail1.example.com > $ ipa-getcert request -k /etc/pki/tls/private/postfix.key \ > -f /etc/pki/tls/certs/postfix.pem \ > -N CN=mail1.example.com,O=EXAMPLE.COM \ > -D mail1.example.com -D mail.example.com \ > -K smtp/mail1.example.com > (and repeat for every next member of the cluster...) > > After this, I would get certificate with something like :: > $ sudo ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20150419153933': > status: MONITORING > stuck: no > key pair storage: > type=FILE,location='/etc/pki/tls/private/postfix.key' > certificate: type=FILE,location='/etc/pki/tls/certs/postfix.pem' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=mail1.example.com,O=EXAMPLE.COM > expires: 2017-04-19 15:39:35 UTC > dns: mail1.example.com,mail.example.com > principal name: smtp/mail1.example@example.com > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > with Subject line in form of: 'CN=,O=EXAMPLE.COM' and 'dns' > info line present. > > Suddenly, in the current setup, after upgrade from 4.0 to 4.2, I'm > getting this :: > > $ ipa dnsrecord-add example.com w3 --a-ip=172.17.17.80 --a-create- > reverse > $ ipa host-add w3.example.com > $ ipa service-add HTTP/w3.example.com > $ ipa service-add HTTP/http1.example.com > $ ipa service-add-host HTTP/w3.example.com --hosts=http1.example.com > $ ipa-getcert request -k /etc/pki/tls/private/httpd.key \ > -f /etc/pki/tls/certs/httpd.pem \ > -N CN=http1.example.com,O=EXAMPLE.COM \ > -D http1.example.com -D w3.example.com \ > -K HTTP/http1.example.com > $ sudo ipa-getcert list > Number of certificates and requests being tracked: 3. > Request ID '20160327095125': > status: MONITORING > stuck: no > key pair storage: > type=FILE,location='/etc/pki/tls/private/http.key' > certificate: type=FILE,location='/etc/pki/tls/certs/http.pem' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=http1.example.com,OU=pki-ipa,O=IPA > expires: 2018-03-28 09:51:27 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > Where's the 'CN=,OU=pki-ipa,O=IPA' coming from instead of > 'CN=,O=EXAMPLE.COM' and why are DNS SubjectAltNames missing? > > To be clear, if I don't do :: > $ ipa service-add-host HTTP/w3.example.com --hosts=http1.example.com > > then certificate is just not issued with 'REJECTED', but once this is > done properly in described steps, DNS SANs are not happening. > > I've tried ipa-getcert from both CentOS 7.2 and Fedora 23, but only > against my current IPA 4.2 on CentOS 7.2. > > For the actual certificates :: > $ sudo openssl x509 -in /etc/pki/tls/certs/postfix.pem -noout -text > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 15 (0xf) > Signature Algorithm: sha256WithRSAEncryption > Issuer: O=EXAMPLE.COM, CN=Certificate Authority > Validity > Not Before: Apr 19 15:39:35 2015 GMT > Not After : Apr 19 15:39:35 2017 GMT > Subject: O=EXAMPLE.COM, CN=mail1.example.com > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > [cut] > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Authority Key Identifier: > keyid:[cut] > > Authority Information Access: > OCSP - URI:http://ipa-ca.example.com/ca/ocsp > > X509v3 Key Usage: critical > Digital Signature, Non Repudiation, Key Encipherment, > Data Encipherment > X509v3 Extended Key Usage: > TLS Web Server Authentication, TLS Web Client > Authentication >
