Networking/SSL 29 September 2025 8 min read

SSL Trust — Missing 'Authority Key Identifier'

Understanding the 'missing Authority Key Identifier' SSL error — why it occurs, what it means for certificate chain validation, and how to resolve it in enterprise environments.

SSLTLSPKICertificateAuthority Key IdentifierX.509Troubleshooting

The Error

You’ve installed a certificate, your chain looks correct, but clients still fail with:

SSL_ERROR_BAD_CERT_DOMAIN
certificate verify failed
unable to get local issuer certificate
authority key identifier not found

Or in OpenSSL output:

verify error:num=20:unable to get local issuer certificate
verify error:num=27:certificate not trusted

This often points to a missing or mismatched Authority Key Identifier (AKI) extension in your certificate chain.

What is the Authority Key Identifier?

The Authority Key Identifier (AKI) is an X.509 certificate extension (OID: 2.5.29.35) that identifies the public key of the Certificate Authority that signed the certificate.

It typically contains:

  • Key Identifier: A hash of the issuing CA’s public key
  • Optionally: Issuer name and serial number
X509v3 Authority Key Identifier:
    keyid:B1:3E:C3:69:03:F8:BF:47:01:D4:98:26:1A:08:02:EF:63:64:2B:C3

The Subject Key Identifier (SKI) is the complementary extension — it identifies this certificate’s own public key, used by the next certificate in the chain as its AKI.

Why the Chain Validation Fails

X.509 path building works by walking the chain from leaf → intermediate → root. At each step, the validator:

  1. Checks the AKI of the current certificate
  2. Looks for a CA certificate whose SKI matches that AKI
  3. Verifies the signature

If the AKI extension is missing from the leaf or intermediate certificate, path building becomes ambiguous:

  • Multiple CAs may have the same Issuer name (especially after CA key rollovers)
  • The validator can’t determine which CA key to use without the AKI
  • Some strict implementations refuse to proceed without the AKI

Common Causes

1. Old Internal CA Without AKI

Legacy internal CAs — particularly those built with old versions of Microsoft AD CS or OpenSSL — may not include the AKI extension by default.

# Check if AKI is present
openssl x509 -in certificate.pem -text -noout | grep -A2 "Authority Key"
# No output means AKI is missing

2. CA Key Rollover Without New Certificates

When a CA renews its own certificate with a new key pair, the AKI in previously issued certificates no longer matches the new CA certificate’s SKI. Old leaf certificates need to be reissued by the new CA key.

3. Self-Signed Root Without AKI

Root CAs are self-signed — their AKI and SKI are the same. Some root CAs are created without these extensions, which can cause issues with strict validators.

4. Cross-Certificate Chains

In bridge PKI architectures, cross-certificates must have correct AKI/SKI relationships. Missing extensions break the cross-chain validation path.

Diagnosing the Issue

Examine the Full Certificate Chain

# Check a server's presented chain
openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null

# For each certificate in the chain, check extensions
openssl x509 -in cert.pem -text -noout | grep -A4 "Key Identifier"

Expected output for a well-formed certificate:

X509v3 Subject Key Identifier:
    5A:BB:91:0C:5F:92:B7:E1:4F:3E:...

X509v3 Authority Key Identifier:
    keyid:B1:3E:C3:69:03:F8:BF:47:01:...

Verify the Chain Using OpenSSL

# Verify leaf against chain and root
openssl verify -CAfile root-ca.pem -untrusted intermediate.pem leaf.pem

# Verbose chain verification
openssl verify -verbose -CAfile root-ca.pem -untrusted intermediate.pem leaf.pem

Check SKI/AKI Match Between Chain Levels

# Extract Subject Key Identifier from the CA cert
openssl x509 -in intermediate-ca.pem -text -noout | grep -A2 "Subject Key Identifier"

# This should match the AKI in the leaf cert
openssl x509 -in leaf.pem -text -noout | grep -A2 "Authority Key Identifier"

Fixes

Fix 1: Reissue the Leaf Certificate

If your CA is properly configured but issued the certificate without AKI, reissue it. Ensure your CA’s OpenSSL config includes:

# openssl.cnf - CA section
[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer

[ usr_cert ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer

Fix 2: Update the CA Configuration

For an OpenSSL-based CA, ensure authorityKeyIdentifier is always included:

# In your CA's openssl.cnf:
[ v3_req ]
authorityKeyIdentifier = keyid,issuer:always
subjectKeyIdentifier = hash

Fix 3: Add the Intermediate CA to the Trust Store

If the client can’t build the chain, sometimes adding the intermediate CA explicitly to the trust store resolves the issue even without AKI:

# Add intermediate to system trust (Ubuntu)
sudo cp intermediate-ca.pem /usr/local/share/ca-certificates/intermediate-ca.crt
sudo update-ca-certificates

Fix 4: Configure Server to Send Full Chain

A common mistake is sending only the leaf certificate from the server. Always send the full chain (leaf + intermediates, but NOT the root):

# nginx
ssl_certificate /path/to/fullchain.pem;  # leaf + intermediates
ssl_certificate_key /path/to/privkey.pem;
# Apache
SSLCertificateFile /path/to/cert.pem
SSLCertificateChainFile /path/to/intermediate.pem

Enterprise CA Best Practices

When operating an internal PKI:

  1. Always include AKI and SKI in all issued certificates
  2. Document your CA key rollover procedure — existing certs need reissuing
  3. Test chain validation after any CA changes: openssl verify is your friend
  4. Monitor certificate expiry across your chain — an expired intermediate silently breaks everything
  5. Use CAA DNS records to restrict which CAs can issue for your domains

Quick Diagnosis Checklist

  • Does the leaf certificate contain an AKI extension?
  • Does the intermediate CA certificate contain an AKI extension?
  • Does the AKI of the leaf match the SKI of the signing CA?
  • Does the AKI of the intermediate match the SKI of the root CA?
  • Is the server sending the full chain (leaf + intermediate)?
  • Is the root CA trusted by the client?
← Back to Articles