On Tue, Jul 22, 2003, Julio Sanchez Fernandez wrote: > I was experimenting with replacing certificates and I found it is harder > that it seems. > > I replaced a self-signed certificate with a new one (changing a couple > of extensions, such as CRL distribution points, etc.) and now the > subordinate CAs do not verify correctly against the new root > certificate. > > The problem comes from the fact that subordinate CA certificates > included an AKID that included the root certificate serial. The key > pair has not changed nor has the root DN, but the serial has changed and > now 'openssl verify' rejects the chain as invalid, though other software > seems to swallow it alright. > > I am going to reissue the subordinate CA certificates anyway to prevent > problems (I need OpenSSL and other software may behave similarly, > rightly or not), but I have been doing some reading and I am a little > bit confused (well, X.509 *always* has the same effect on me :-) > > [I quote from a draft dated May 3, 2001, downloaded from the Bull server > some time ago, I don't have the published spec.] > > On page 34 (8.2.2.1 Authority key identifier extension), I read: > > The authorityCertIssuer, authoritySerialNumber [typo?] pair can > only be used to provide preference to one certificate over > others during path construction. > > On page 60 (10.5.1 Basic certificate checks), I read: > > a) Check that the signature verifies, that dates are valid, that > the certificate subject and certificate issuer names chain > correctly, and that the certificate has not been revoked. > > and I don't find any mention to the AKID data. > > Yet, X509_check_issued will process it if present unconditionally, as if > it matching was a requirement. > > Is X509_check_issued unnecessarily strict, have I misunderstood X.509 > (one of my favorite hobbies) or is this behaviour part of the unwritten > lore in the field? >
I think some other implementations do a similar thing to OpenSSL. Others may well ignore the extension and so will accept anything. RFC3280 isn't very clear on the matter though some discussions in the lists suggest that is also advisory. I'll look into loosening the requirement so it uses a certificate which matches AKID if available otherwise just uses one which matches the issuer name. If you just create the keyIdentifier field when using AKID then this problem doesn't arise because the AKID will then match the SKID and issuer and serial number isn't checked. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
