“X509v3 Authority Key Identifier” or “authorityKeyIdentifier” is an X509v3 extension that’s added to X509 certificates and identifies the CA that signed the Certificate. I suppose that this speeds up the certificate validation process by eliminating multiple checks.
Short version
Edit openssl.cnf and make sure that authorityKeyIdentifier does not include “issuer”
Long version
There’s an issue when using the default OpenSSL configuration or when basing a config on that: the default OpenSSL configuration has the following:
authorityKeyIdentifier=keyid,issuer
In the section that lists options for user certificates (i.e. not the CA section). The above results in new certificates using the extension and include two identifiers for the signing CA:
- The Key ID of the CA’s cert (because if “keyid”)
- The subject and the serial number of the CA’s cert (because of issuer)
For example:
X509v3 Authority Key Identifier: keyid:7E:E5:82:FF:FF:FF:15:96:9B:40:FF:C9:5E:51:FF:69:67:4D:BF:FF DirName:/C=UK/O=V13/OU=V13/CN=V13 Certificate Authority serial:8E:FF:A2:1B:74:DD:54:FF
And this is where the pain and the suffering happens: If you ever decide that you want to re-create the CA’s certificate using the same private key then you won’t be able to do so because all certificates that are already signed dictate the subject and the serial number of the old certificate as the CA certificate identifier. Thus your new CA certificate will not be able to verify the existing certificates.
Thus the only way to replace your certificate would be:
- To start from scratch recreating all certificates, or
- to create another CA certificate with the same subject and serial number (not tested)
Recreating a certificate with the same details (like serial number) will make it impossible to have both certificates available and will most probably cause a mess.
The best approach is to completely remove the “issuer” from authorityKeyIdentifier from the configuration file. Then only the Key ID will be used to identify the CA which should be more than enough.
So use the following and live a happy life:
authorityKeyIdentifier=keyid
V13 
Hi, that AKI detail is something that can really bite us, nevertheless i believe that
the process described here: http://windowsitpro.com/security/q-whats-impact-renewing-enterprise-root-cas-certificate-our-existing-pki-clients-and-subord/ can workaround the problem. In summary, we establish a cross trust between the old root CA certificate and the new one. Clients that attempt to validate and their certificate chain ends up in the old root CA certificate will succeed because the old cert trusts the new one, and vice versa.
In any case that will happen in the transitional period between the issuance of the new root CA cert and the expiration of the old, since after the old expires all client certs will have expire (or if not, they will be invalid). After that period, life goes on with the new root CA cert only.
I am new to PKI (and i still feel new after quite some reading, with all this complexity and moving targets issues) so i am pretty sure i haven’t took into account other parameters or issues when thinking about all this, so i would like to hear your opinion on that.
Cheers,
vagy
LikeLike
The latest version of openssl will either use `keyid` or the `issue`, never the both 🙂
LikeLike
> _to create another CA certificate with the same subject and serial number (not tested)_
That actually works, but you need to do two things:
– Replace the root cert in all clients (you had to do this anyway)
– setup a CA-like new directory, config, etc and force the SN into the new root
LikeLike