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 <ftwee...@redhat.com>: > > > 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=<hostname>,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=<hostname>,OU=pki-ipa,O=IPA' coming from instead of > > > 'CN=<hostname>,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 > > > X509v3 CRL Distribution Points: > > > > > > Full Name: > > > URI:http://ipa-ca.example.com/ipa/crl/MasterCRL.bin > > > CRL Issuer: > > > DirName: O = ipaca, CN = Certificate Authority > > > > > > X509v3 Subject Key Identifier: > > > [cut] > > > X509v3 Subject Alternative Name: > > > DNS:mail1.example.com, DNS:mail.example.com, > > > othername:<unsupported>, othername:<unsupported> > > > Signature Algorithm: sha256WithRSAEncryption > > > [cut] > > > > > > vs. > > > > > > $ sudo openssl x509 -in /etc/pki/tls/certs/http.pem -text -noout > > > Certificate: > > > Data: > > > Version: 3 (0x2) > > > Serial Number: 71 (0x47) > > > Signature Algorithm: sha256WithRSAEncryption > > > Issuer: O=EXAMPLE.COM, CN=Certificate Authority > > > Validity > > > Not Before: Mar 27 09:51:27 2016 GMT > > > Not After : Mar 28 09:51:27 2018 GMT > > > Subject: O=IPA, OU=pki-ipa, CN=http1.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://idmc1.example.com:80/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 > > > Signature Algorithm: sha256WithRSAEncryption > > > [cut] > > > > > > so even reference to CRL is missing here, but OCSP is present. > > > > > > > > > Sorry if this is duplicate, but from what I was able to find, DNS > > > SubjectAltNames are reported working since CentOS 7.1, and I think I'm > > > consistent with http://www.freeipa.org/page/PKI, unless I miss something > > > obvious here. > > > > > > For new features like certificate profiles and ACLs, I haven't changed > > > any defaults as far as I know as there was no need for that. > > > > > > > > > Thank you for any support in advance! And Happy Easter! > > > > > > Martin > > > > Hi Martin, > > > > Thanks for the detailed info. Could you please provide the > > Dogtag configuration for the default profile, `caIPAserviceCert'? > > > > ipa certprofile-show --out caIPAserviceCert.cfg caIPAserviceCert > > > > (Then provide the contents of caIPAserviceCert.cfg) > > > > Could you also provide the contents of file > > `/etc/pki/pki-tomcat/ca/CS.cfg'? > > > > Regards, > > 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 -- 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