Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

alt

Daniel Nashed

Let’s Encrypt X509v3 Subject Key Identifier Changes to the first 160 bits of a SHA256 instead of a SHA1 hash

Daniel Nashed – 7 June 2025 22:14:00

Most admins don't pay much attention to Subject Key Identifiers (SKI).

But they have a special role in Domino 12 and higher they are used as a certificate extension to match certificate chains.
CertStore calculates a SKI as an unique identifier used to reference root certificates for trusts.


I noticed the SKI which is part of the X509 extension is different from what Domino calculates.
It took a moment to find out what is going on. You would only notice or run into it if you compare the values in the certificate extension and the computed value for example in Domino
.

This change does not have any impact how those certificates and SKIs are handled in Domino.

Domino calculates the SKI in the same way for all certificates and the X509 extension isn't used for looking up certificates.

It's still important to know the background.


Calculation


Most Certificate Authorities (CA) use a SHA1 hash of the raw public key.


Let's Encrypt now uses SHA256, truncated to the first 160 bits, to generate the Subject Key Identifier (SKI).

This is a departure from their previous practice of using SHA1, as outlined in RFC 5280.

This change ensures compatibility and aligns with RFC 7093.


Here is the background


https://community.letsencrypt.org/t/lets-encrypt-new-intermediate-certificates/209498?page=2

"we have updated the ceremony to use a SHA-256 hash truncated to the first 160 bits (the same length as a SHA-1 hash) for the SubjectKeyIdentifier, so that we can simultaneously stop using SHA-1 and not increase the size of the new certificates."



Explaining Subject Key Identifiers and Authority Key Identifiers


The X509v3 Subject Key Identifier and X509v3 Authority Key Identifier are X.509 certificate extensions defined in version 3 of the X.509 standard.

They are used to help uniquely identify keys and link certificates in a certificate chain, especially in public key infrastructure (PKI)


X509v3 Subject Key Identifier (SKI)


This extension provides a unique identifier for the public key contained in the certificate. It’s primarily used to:
  • Identify the certificate’s key (especially if the same subject name is reused in different certs).
  • Support building and verifying chains of trust.


How it's generated:


Typically, it's the SHA-1 hash of the DER-encoded SubjectPublicKey BIT STRING (just the raw key bytes, not the full X509_PUBKEY).


Example from openssl x509 -text:


X509v3 Subject Key Identifier:
B9:2F:D7:DA:9F:61:B8:F6:53:AD:D4:87:95:F4:AA:58:6B:B2:D0:F5



X509v3 Authority Key Identifier (AKI)


This extension helps identify which key was used to sign this certificate — i.e., it points to the issuer’s key. It's especially useful for:
  • Locating the correct issuing certificate in cases where the issuer’s name is ambiguous or reused.
  • Detecting and handling key rollovers (same issuer, different keys).


Example from openssl x509 -text:


X509v3 Authority Key Identifier:
keyid:88:B3:3A:E1:0B:FA:A7:6A:47:C5:BB:BF:0C:F0:71:ED:E4:3D:9D:E7



How they work together:


In a certificate chain:
  • The Subject Key Identifier (SKI) in a CA certificate identifies its public key.
  • The Authority Key Identifier (AKI) in a child certificate refers to that SKI, helping to verify which certificate signed it.

This matching is especially critical in:
  • Complex PKI environments with multiple CAs
  • Certificate revocation checking (e.g., CRLs, OCSP)


---


Reference RFC 7093


https://datatracker.ietf.org/doc/html/rfc7093#section-2


Additional Methods for Generating Key Identifiers


[RFC5280] specifies two examples for generating key identifiers from

public keys.  Four additional mechanisms are as follows:


1) The keyIdentifier is composed of the leftmost 160-bits of the

SHA-256 hash of the value of the BIT STRING subjectPublicKey

(excluding the tag, length, and number of unused bits).


2) The keyIdentifier is composed of the leftmost 160-bits of the

SHA-384 hash of the value of the BIT STRING subjectPublicKey

(excluding the tag, length, and number of unused bits).


3) The keyIdentifier is composed of the leftmost 160-bits of the

SHA-512 hash of the value of the BIT STRING subjectPublicKey

(excluding the tag, length, and number of unused bits).


4) The keyIdentifier is composed of the hash of the DER encoding of

the SubjectPublicKeyInfo value.



Links

    Archives


    • [HCL Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]