The Subject Key Identifier (SKI) identifies a certificate’s own public key, while the Authority Key Identifier (AKI) identifies the public key of the certificate’s issuer. Both are X.509 extensions defined in RFC 5280, and together they let certificate software link an issued certificate to the certificate that signed it, which makes building a trust chain faster and less ambiguous. They aid discovery, not trust; cryptographic signature verification still decides whether a chain is valid.
In Public Key Infrastructure (PKI), certificate chain building depends on linking each certificate to the correct issuer. Two X.509 extensions do much of that linking work: the Authority Key Identifier (AKI) and the Subject Key Identifier (SKI).
RFC 5280 defines the SKI as an identifier for the subject’s public key and the AKI as an identifier for the issuer’s public key. Certificate software uses them to recognize relationships between certificates and to construct trust chains efficiently. The extensions appear throughout certificate authority (CA) hierarchies, TLS trust chains, certificate lifecycle platforms, and renewal workflows.
AKI and SKI are small fields, but they matter more as a PKI grows, especially where an organization runs multiple certificate authorities, cross-signed certificates, and frequent renewals. This blog explains what each extension is, how they work together, where they matter, and the mistakes worth avoiding. Starting with the Subject Key Identifier establishes the foundation for understanding both extensions.
What is the Subject Key Identifier
The Subject Key Identifier(SKI) is an X.509 extension that identifies the public key contained in a certificate. Its value is derived from the subject’s public key. RFC 5280 describes two methods for generating this value: a 160-bit SHA-1 hash of the certificate’s public key, or a shorter value using the type field 0100 followed by the 60 least significant bits of that hash. In this context, SHA-1 functions purely as an identifier label rather than a cryptographic security mechanism, so its deprecation for security applications under NIST SP 800-131A Rev 2 does not affect its use in SKI generation.
RFC 7093 (2013) extends the available options further, defining additional methods that use SHA-256, SHA-384, and SHA-512 hashes of the SubjectPublicKeyInfo structure, each truncated to 160 bits. Modern certificate authorities are increasingly adopting these RFC 7093 methods; Let’s Encrypt, for instance, moved to a SHA-256-based SKI generation method in 2025.
RFC 5280 (2008) requires the SKI extension in all conforming certificate authority certificates, and it includes a normative SHOULD requirement that end-entity certificates include it as well. For a CA, the SKI acts as a stable, consistent identifier for the CA’s signing key. Certificates that the CA issues can reference this value through their own AKI field, creating a traceable link back to the issuing CA.
During path construction, validation software can use the SKI to differentiate between multiple certificates that might serve as an issuer. For root and intermediate CA certificates, it provides a consistent way to identify the CA’s signing key across the certificate lifecycle, including renewals and key rollover. The Authority Key Identifier complements this by pointing from any issued certificate back to the key that signed it.
What is the Authority Key Identifier
The Authority Key Identifier(AKI) is an X.509 extension that identifies the public key of the certificate’s issuer. RFC 5280 states that the keyIdentifier field of the AKI must be included in all certificates generated by conforming CAs to support path construction, with one exception: a CA distributing its public key as a self-signed certificate may omit the AKI.
The AKI typically contains a key identifier, and it may optionally include issuer name information expressed as GeneralNames (the authorityCertIssuer field in the ASN.1 structure) and the issuer’s certificate serial number. In most deployments, the key identifier is the component used during chain construction. Where SKI identifies the certificate’s own public key, AKI points to the key of the issuing CA, and that difference is the heart of the distinction between Authority Key Identifier and Subject Key Identifier. The next section shows how these two extensions interact during certificate chain construction.
How AKI and SKI Work Together
The relationship is simple to state. The SKI identifies a certificate’s own public key, and the AKI identifies the issuer’s public key. A useful analogy is that the SKI works like a name tag on a certificate’s own key, while the AKI works like a return address that points back to the key which signed it.
RFC 5280 ties the two together for conforming CAs: the keyIdentifier in an issued certificate’s AKI is derived from the issuing CA’s key and therefore matches the SKI of that CA’s certificate. That shared value creates a logical link from the issued certificate back to its issuer. During path construction, software can take the AKI of a certificate and look for a CA certificate whose SKI carries the same value. Once a candidate issuer is found, ordinary path validation and signature verification decide whether the chain is actually trustworthy.
In practice, this is straightforward to verify. Running the following command against an issued certificate displays the Authority Key Identifier in the output:
openssl x509 -text -noout
The output includes a value such as keyid:A1:B2:C3…. Inspecting the issuing CA certificate reveals the same value in its Subject Key Identifier. Matching the two confirms which CA certificate completes the chain.
An important distinction is worth noting. RFC 5280 does not require applications to verify that key identifiers match during certification path validation. AKI and SKI assist in certificate discovery and chain building, but they do not replace cryptographic validation or trust verification. This assistance is most valuable in environments that rely on Hardware Security Modules, automated issuance, ACME-based enrollment, and layered CA hierarchies. A side-by-side comparison in the next section captures the core differences between the two extensions at a glance.
Authority Key Identifier vs Subject Key Identifier
The table below sets out the core differences between the two extensions, showing how their purposes, scopes, and roles in certificate chain construction compare.
| Feature | Subject Key Identifier (SKI) | Authority Key Identifier (AKI) |
|---|---|---|
| Purpose | Identifies the subject’s public key | Identifies the issuer’s public key |
| References | The certificate’s own key | The issuing CA’s key |
| Typical source | Derived from the subject public key | Derived from the issuer’s key identifier |
| Primary use | Labeling a certificate’s public key | Locating the issuing certificate |
| RFC 5280 requirement | Required in conforming CA certificates; SHOULD be included in end-entity certificates (RFC 5280 §4.2.1.2) | keyIdentifier required in CA-issued certificates, may be omitted in self-signed certificates |
| Chain-building role | Provides the value an issuer certificate is matched against | Points to the issuer whose SKI it should match |
| Self-signed certificate | Identifies the certificate’s own public key | Identical to the SKI, so it may be omitted |
Where AKI and SKI Matter in PKI
With the core differences between the two extensions established, AKI and SKI become more important to understand as a PKI grows more complex. Organizations meet them across enterprise TLS deployments, internal and external CA hierarchies, code-signing infrastructures, device identity programs, certificate lifecycle management automation, cross-signing initiatives, and CA key rollover or migration work.
In environments with several intermediate CAs, the two extensions help software pick the right issuer certificate more efficiently, which reduces ambiguity and makes validation failures easier to troubleshoot. They are especially useful during CA key transitions, where several certificates may share similar issuer information but represent different signing keys, and the key identifier is what distinguishes them. These real-world deployments are also where operational mistakes and misconfigurations tend to surface.
Common Mistakes and Operational Challenges
A frequent misconception is that AKI and SKI should always hold identical values. That is true only for self-signed certificates, such as root CA certificates, where issuer and subject are the same key. For issued certificates, the SKI identifies the subject’s key while the AKI identifies the issuer’s key, so the values differ by design.
Another is assuming every validation engine treats these extensions the same way. RFC 5280 is explicit that applications need not verify key identifier matches during path validation, and implementations across operating systems and cryptographic libraries vary in how they use the fields during discovery and chain construction.
Organizations also hit trouble during CA key rollover. If certificate templates, automation workflows, monitoring, or inventories are not updated correctly, chain construction can break and troubleshooting effort rises sharply. Understanding these common pitfalls connects to broader security considerations for a well-maintained PKI.
Security Considerations
AKI and SKI support certificate chain construction, but they are not security controls. Trust in a PKI still rests on strong cryptographic signatures, secure protection of CA private keys, sound issuance policy, effective lifecycle management, and continuous monitoring and auditing.
Many organizations protect CA private keys in Hardware Security Modules to reduce the risk of key compromise. An HSM strengthens key security, but it does not change the purpose or behavior of AKI and SKI. After certificate renewals, CA migrations, or key rollover, administrators should validate certificate chains thoroughly so trust paths keep working across browsers, VPNs, APIs, email systems, and other TLS applications.
For organizations that need structured support managing these aspects of their PKI, working with a specialist partner can significantly reduce complexity and operational risk.
How Encryption Consulting Can Help
Managing certificate authorities, key rollover projects, and lifecycle operations at scale takes more than understanding a pair of X.509 extensions. Certificate hierarchies, trust chains, automation workflows, and governance all have to stay aligned across the certificate lifecycle.
Encryption Consulting offers end-to-end support for organizations at every stage of their PKI journey. Its Enterprise PKI Services include PKI programme assessments, CA hierarchy design and migration planning, certificate lifecycle management, HSM integration, and automation initiatives, giving organizations a structured path from initial design through ongoing operational management.
For organizations that want to automate certificate operations directly, EC’s CertSecure Manager delivers certificate lifecycle management across multiple certificate authorities, automating certificate discovery, enrollment, renewal, and monitoring so that certificate inventories and their key identifiers stay accurate through every renewal and key rollover.
EC’s experts help keep certificate trust chains healthy, reduce operational risk, and improve visibility across complex certificate ecosystems. Whether an organization is standing up a new PKI, modernizing an existing CA hierarchy, or preparing for large-scale automation, EC helps keep the certificate infrastructure secure, scalable, and operationally efficient.
Conclusion
The difference between Authority Key Identifier and Subject Key Identifier becomes clear once their roles are viewed separately. The SKI identifies a certificate’s own public key, and the AKI identifies the issuer’s public key. Together, they help certificate software locate and organize certificates within a trust chain.
AKI and SKI are not security controls, but they play a real role in path construction, CA hierarchy management, renewals, and key rollover. For PKI administrators, security architects, and certificate management teams, knowing how these extensions behave makes troubleshooting, migration planning, and lifecycle operations noticeably simpler. A practical first step is to confirm that your CA certificates carry correct, stable key identifiers and that your automation and inventory track them through every renewal and rollover.
