[Freeipa-devel] [PATCH] 0057..0058 Fix caIPAserviceCert regression
Jan Cholasta
jcholast at redhat.com
Thu May 19 11:36:46 UTC 2016
On 19.5.2016 13:03, Fraser Tweedale wrote:
> 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.
Right.
>
>> 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 ;)
OK. ACK then.
Pushed to:
master: 356f262fb7320345fd5f787c383912b9a2d77314
ipa-4-2: f116e51ce3d495758ff71f685b78d4848ce6708c
ipa-4-3: e9672b1a2b191a1622f18a57a2751e4db3e9e39d
--
Jan Cholasta
More information about the Freeipa-devel
mailing list