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
--
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
