How to keep the same Service Key Identifier (SKID) when generating the new Root & Intermediate CA issuing certificates.

What?

This article demonstrates how to keep the same "Service Key Identifier (SKID)" when generating the new Root & Intermediate CA issuing certificates.

To elaborate more about the need for regeneration, we never actually renew the root issuing certificate, but once it expires, we require a new certificate. However, since the lifetime is typically extremely long for the first certificate, we can always plan for this, well in advance, and spin up a new root, say, a couple of years before the old one expires. The Intermediate CAs share the same context for regeneration.

 

How?

The solution, or the workaround to achieve the ask here, will be to generate a CSR and then sign it with the sign-intermediate endpoint.

• Look for the key_id  of the current issuer, it will look something like dc439612-ac6b-dfe4-4d3c-70d82845fd48.
• Next, generate a CSR using that key by running vault write /pki/intermediate/generate/existing key_ref="dc439612-ac6b-dfe4-4d3c-70d82845fd48".
• Then save that CSR to a file, sign that CSR with the certificate you used initially, and supply the correct SKID field by running vault write /pki/issuer/:issuer_ref/sign-intermediate csr=@examplefilename.csr skid=<your-skid> common_name="xyz-abc" ttl=87600h.
  • If that certificate has the same key as the intermediate, and you supply the same name and skid, you end up with a root certificate.
    • issuer_ref - Refer to the issuer ID of the existing root CA.
    • skid - Value for the Subject Key Identifier of the current root CA you are regenerating.
    • ttl - to define the age of the newly generated root CA issuing certificate.

Why?

The Subject Key Identifier (SKID) is simply a hash of the public key inside the certificate. As its name suggests, it is used to uniquely identify a key if a CA has more than one.
 

On the other hand, Authority Key Identifier (AKID), most commonly, it is the value of the Issuer's Subject Key Identifier. Together, SKIDs and AKIDs help us to ensure the chain of authority.

Hence, if you want to keep the same private key used by the existing issuers to sign certificates. While certificates represent a public assertion of an identity, private keys represent the private part of that identity, a secret used to prove who they are and who they trust. So, while generating the new issuing certificate, keeping the existing issuer and the private key, you would need these steps.

Important!

#1

On the contrary, if you are ok to create a new issuer with the existing private key, you can use the following commands to achieve it:
 

Generate a new Root CA issuing certificate:

vault write -field=certificate pki/root/generate/internal \
     common_name="example.com" \
     issuer_name="root-2024" \
     ttl=87600h

Regenerate the new Root CA issuing certificate:

vault write -field=certificate pki/root/generate/existing \
     common_name="example.com" \
     issuer_name="root-2025" \
     ttl=87600h key_ref=09a71e93-7bf1-4760-49a0-97723debc8eb

You will be able to see two different issuer certificates having the same SKID because the key remained the same.
 

#2

Starting the Vault v1.10.0, there was a change introduced which was:

secrets/pki: Calculate the Subject Key Identifier as suggested in RFC 5280, Section 4.2.1.2. [GH-11218]

With this change, the way of storing the PKI information in the storage layout was changed. Hence, the PKI mounts/CAs enabled before that would change the SKID as well, even if you would use the existing key reference, with the following information printed in the Vault operational logs:

[INFO]  secrets.pki.pki_faf55812: performing PKI migration to new keys/issuers layout
[INFO]  secrets.pki.pki_faf55812: Migration generated the following ids and set them as defaults: issuer id=de24b30b-d124-072c-067d-7b812b09a0c4 key id=9fcb4329-b717-c197-28f7-af436a833eae
[INFO]  secrets.pki.pki_faf55812: Scheduling PKI CRL rebuild.
[INFO]  secrets.pki.pki_faf55812: 28bc5768-5e05-8fc0-a617-ec385454bb3a: succeeded in migrating to issuer storage version 2

Post this PKI migration, and in newer Vault versions, the SKID can be the same when regenerating, as mentioned in #1.

Reference Articles:

• PKI secrets engine (API)