Authority Key Identifier vs Subject Key Identifier in PKI

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 guide explains what each extension is, how they work together, where they matter, and the mistakes worth avoiding.

Quick Answer: What Are AKI and SKI in X.509 PKI?

SKI (Subject Key Identifier) is an X.509 extension that identifies a certificate’s own public key, derived from the subject’s public key using a hash method defined in RFC 5280 or RFC 7093. AKI (Authority Key Identifier) identifies the public key of the certificate’s issuer. A certificate’s AKI should match the SKI of its issuing CA certificate, creating the link that lets validation software build the trust chain efficiently without relying solely on subject name matching.

Key Takeaways

• SKI and AKI are complementary extensions: the SKI in a CA certificate provides the value that issued certificates reference through their AKI. This AKI-to-SKI link is how certificate chain-building software locates the correct issuing CA certificate, particularly when multiple CA certificates share similar subject names but represent different signing keys.
• AKI and SKI assist discovery, not trust. RFC 5280 is explicit that applications are not required to verify that key identifier values match during certification path validation. Cryptographic signature verification still determines whether a chain is actually trustworthy. The extensions make chain building faster and less ambiguous, but they do not replace signature validation.
• RFC 5280 requires the SKI extension in all conforming CA certificates. The AKI keyIdentifier field is also required in all CA-issued certificates, with one exception: a CA distributing its public key as a self-signed certificate may omit the AKI. Both extensions become critical during CA key rollovers and renewals, where a stale or mismatched key identifier can silently break chain construction across browsers, VPNs, APIs, and email systems.
• According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of all enterprises experienced certificate-related downtime in the past year. AKI/SKI mismatches during CA key rollover are a recurring, often overlooked contributor to chain-building failures that surface during those outages.
• CA/Browser Forum Ballot SC-081v3 (April 2025) reduces maximum public TLS certificate validity to 47 days by March 2029, meaning certificate renewals will occur up to eight times per year per certificate. At that frequency, CA template configurations controlling SKI generation and AKI population must be verified for correctness before automation is enabled, not discovered to be misconfigured after a chain-building failure in production.

Who Should Care About AKI and SKI in Enterprise PKI

AKI and SKI are low-visibility fields that have high-impact consequences when misconfigured. Every role below has a direct stake in ensuring key identifiers are correct, consistent, and tracked through every CA renewal and key rollover.

What Is the Subject Key Identifier (SKI)?

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 (AKI)?

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.

How AKI and SKI Work Together in Certificate Chain Construction

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... in the Authority Key Identifier field. Inspecting the issuing CA certificate reveals the same value in its Subject Key Identifier field. 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.

Authority Key Identifier vs Subject Key Identifier: Side-by-Side Comparison

The table below sets out the core differences between the two extensions, showing how their purposes, scopes, and roles in certificate chain construction compare.

AKI and SKI Decision Matrix: Use Case, Impact, and Owner

Use this table to map AKI and SKI governance decisions to their security impact, operational effort, automation fit, and recommended owner across common enterprise PKI scenarios.

Where AKI and SKI Matter in Enterprise 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. For organizations managing cloud, hybrid, or multi-CA environments, CBOM Secure provides the cryptographic bill of materials visibility needed to track key identifier values across all CA sources and detect inconsistencies before they cause chain-building failures. As certificate validity periods shrink toward 47 days under CA/Browser Forum Ballot SC-081v3 (April 2025), the frequency of CA interactions and renewals increases, making correct AKI/SKI configuration in CA templates a prerequisite for reliable automation via managed PKI or self-hosted ACME endpoints.

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. The most reliable way to catch this before it reaches production is to run end-to-end chain validation tests after every CA renewal, using openssl verify -CAfile chain.pem cert.pem or equivalent against all affected trust paths.

Security Considerations for AKI and SKI in PKI Operations

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.

As organizations plan for post-quantum cryptography migration, the CA hierarchy’s SKI and AKI generation methods should be evaluated for compatibility with planned algorithm transitions. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. A CA hierarchy rebuild for post-quantum algorithms is an opportunity to standardize SKI generation on RFC 7093 SHA-256 methods across all CAs. Begin PQC readiness planning via the PQC Readiness assessment and the PQC Center of Excellence.

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 program 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, 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. For cryptographic visibility across all CA sources and environments, CBOM Secure builds a Cryptographic Bill of Materials that surfaces AKI and SKI values alongside algorithm, key size, and certificate authority data, making it possible to detect key identifier inconsistencies before they become chain-building failures. For organizations building or migrating PKI to the cloud, PKI as a Service delivers a fully managed CA hierarchy with correct AKI and SKI configuration built in from the start.

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 efficiently and unambiguously.

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.

Frequently Asked Questions

What is the main takeaway from Authority Key Identifier vs Subject Key Identifier in PKI?

SKI and AKI are complementary X.509 extensions that together enable efficient certificate chain construction. The SKI in a CA certificate provides the value that issued certificates reference through their AKI, creating the link that lets validation software build the trust chain without relying solely on subject name matching. They assist discovery, not trust; cryptographic signature verification still determines whether a chain is actually trustworthy.

Why do AKI and SKI matter for enterprise PKI teams?

Enterprise PKI teams manage CA hierarchies where multiple certificates can share similar subject names but represent different signing keys. In those scenarios, the key identifier in AKI and SKI is what distinguishes the correct issuer certificate from incorrect candidates, preventing chain-building failures and validation errors. According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced certificate-related downtime in the past year; AKI/SKI mismatches during CA key rollover are a contributing factor.

What risks increase if AKI and SKI are managed manually in enterprise PKI?

Manual management increases the risk of: key identifier mismatches during CA key rollover, where automation workflows and certificate templates are not updated to reflect the new CA keypair; inconsistent SKI generation methods across different CA platforms, making cross-CA chain building ambiguous; and missing AKI in issued certificates due to misconfigured CA templates, violating RFC 5280 conformance requirements and causing path-construction failures in strict validation environments.

Which teams should own AKI and SKI governance in enterprise PKI?

PKI admins own the CA template configuration that controls SKI generation and AKI population, and verification that key identifiers remain consistent through CA renewals and key rollovers. Security architects own the CA hierarchy design decisions. Platform teams own the validation that AKI and SKI are correctly represented in deployed certificates. Compliance teams own audit evidence that CA certificates include the extensions required by RFC 5280.

How do AKI and SKI connect to certificate lifecycle management?

CLM platforms depend on key identifier values being correct and consistent to accurately track certificate lineage, map issued certificates to their issuing CA, and detect chain-building anomalies. CertSecure Manager maintains a live certificate inventory that tracks the full chain for every certificate, including the AKI-to-SKI link from issued certificate to issuing CA, and alerts when that link breaks during a CA renewal or key rollover.

How should organizations measure success in AKI and SKI governance?

Key metrics: percentage of CA certificates confirmed to carry a correct, stable SKI value (target: 100%); percentage of issued certificates carrying an AKI keyIdentifier matching the issuing CA’s SKI (target: 100%); number of certificate chain-building failures attributed to AKI/SKI mismatch in the past quarter (target: zero); and mean time to detect and resolve AKI/SKI discrepancies during CA key rollover via CertSecure Manager inventory alerts (target: under one business day).

What should be audited or monitored regularly for AKI and SKI?

Audit quarterly: CA certificate templates to confirm SKI generation method consistency and AKI population rules; issued certificate samples to confirm AKI keyIdentifier matches the issuing CA’s SKI; and end-to-end certificate chain validation tests across all trust paths. Monitor continuously: certificate chain-building failures in TLS servers, API gateways, and browsers that may indicate an AKI/SKI mismatch; and CBOM Secure inventory for any certificates whose issuing CA SKI has changed without a corresponding AKI update.

How do AKI and SKI affect cloud, hybrid, or multi-CA PKI environments?

In cloud and hybrid environments where certificates are issued from multiple CAs, the AKI is the primary field that chain-building software uses to locate the correct issuing CA when multiple candidates with similar subject names exist. Inconsistent SKI generation methods across different CA platforms can create ambiguity in multi-CA environments. CBOM Secure provides cryptographic inventory visibility across all CA sources in cloud, on-premises, and hybrid environments, ensuring no issuing CA’s key identifier changes go undetected.

What common mistakes should teams avoid with AKI and SKI?

The most common mistakes: assuming AKI and SKI should always hold identical values (true only for self-signed root CA certificates); not updating CA certificate templates and automation workflows after a CA key rollover, leaving issued certificates with an AKI matching the old CA keypair; and assuming every validation engine enforces AKI/SKI matching during path validation (RFC 5280 is explicit that applications are not required to verify key identifier matches, so behavior varies across implementations).

What prerequisites are required before implementing or auditing AKI and SKI?

Prerequisites include: a complete certificate inventory covering all CA and issued certificates across all environments, identifying the SKI value for every CA certificate and the AKI value for every issued certificate; documentation of the SKI generation method used by each CA platform in the hierarchy (RFC 5280 Method 1 SHA-1, or RFC 7093 SHA-256/384/512); access to run openssl x509 -text -noout or equivalent against certificates in all environments; and a CLM platform such as CertSecure Manager to track the AKI-to-SKI link across the full certificate estate and alert on discrepancies during CA renewals and key rollovers.

What should be refreshed quarterly for AKI and SKI governance?

Refresh quarterly: CA certificate template audit confirming SKI generation method consistency and AKI population rules across all issuing CAs; end-to-end certificate chain validation tests across all trust paths; PQC readiness review via the PQC Center of Excellence covering whether the current CA hierarchy’s SKI and AKI generation methods are compatible with planned post-quantum algorithm migration (NIST FIPS 203, 204, and 205 finalized August 2024); and CLM inventory review confirming the AKI-to-SKI link is intact for all certificates in the managed estate following any CA renewal or key rollover in the preceding quarter.