On Thu, May 19, 2016 at 09:52:08AM +0200, Jan Cholasta wrote: > On 19.5.2016 01:31, Fraser Tweedale wrote: > > On Wed, May 18, 2016 at 03:17:37PM +0200, Jan Cholasta wrote: > > > Hi, > > > > > > On 18.5.2016 08:09, Fraser Tweedale wrote: > > > > Rebased version of 0057 attached, along with new patch 0058 that > > > > detects when the Dogtag version of caIPAserviceCert has been > > > > erroneously imported and repairs the profile. > > > > > > How to reproduce the issue? So far I had no luck with > > > freeipa-server-4.2.4-1.fc23.x86_64. > > > > > > Honza > > > > > `ipa-replica-install --setup-ca` with an affected version (including > > 4.2.4-1) will cause the issue. > > Thanks. > > The fix seems to work, although if you install an unfixed replica against a > fixed server, it will still break the profile. I'm not sure how much of a > problem this could be in the real world, though. > Thank you for testing. If un-fixed replica re-breaks the profile, the next server upgrade on any fixed replica will re-fix the profile. So assume customer eventually upgrades all replicas beyond the broken versions, it will converge on a fixed profile.
> For the record, this is a diff between the relevant parts of a test > certificate issued before and after the fix: > > @@ -1,19 +1,19 @@ > Validity > Not Before: <snip> > Not After : <snip> > - Subject: O=IPA, OU=pki-ipa, > CN=vm-244.abc.idm.lab.eng.brq.redhat.com > + Subject: O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM, > CN=vm-244.abc.idm.lab.eng.brq.redhat.com > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > @@ -36,48 +36,60 @@ > > keyid:89:8C:12:22:E7:D4:C5:87:06:26:5E:AE:C7:73:B5:4B:82:93:CE:1E > > Authority Information Access: > - OCSP - > URI:http://vm-244.abc.idm.lab.eng.brq.redhat.com:80/ca/ocsp > + OCSP - > URI:http://ipa-ca.abc.idm.lab.eng.brq.redhat.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.abc.idm.lab.eng.brq.redhat.com/ipa/crl/MasterCRL.bin > + CRL Issuer: > + DirName: O = ipaca, CN = Certificate Authority > + > + X509v3 Subject Key Identifier: > + 5E:A4:14:31:8E:71:00:4E:2A:71:D6:49:E4:1D:09:EC:10:DF:5D:B1 > Signature Algorithm: sha256WithRSAEncryption > <snip> > Note that SAN, if requested, would also not appear with the broken profile. > The ticket and bugzilla mention only OCSP URI being wrong. It should be > stated somewhere visible that the subject name and CRL distribution points > are also affected. > > BTW the CRL issuer field is wrong. In my case, the issuer name of the CRL is > "CN=Certificate Authority,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM", not > "CN=Certificate Authority,O=ipaca". Also, according to RFC 5280, section > 4.2.1.13, the CRL issuer field must be ommited if the CRL issuer is the same > as the certificate issuer. > It's been like that (i.e. wrong) forever. A proper fix, in light of sub-CAs work, will require a fair bit of work in Dogtag, i.e. a new profile component that implements the following heuristic: - Determine whether issuer has CRL(s) configured; if not, omit CRLDP - Determine whether issuer issues CRLs itself, or delegates. Construct CRLDP extension accordingly. Not gonna happen for v4.4 ;) Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code