[Freeipa-devel] [PATCH] 0057..0058 Fix caIPAserviceCert regression

[Fraser Tweedale]

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