Vault root CA rotation

Vault
1

Hi All,

We are using Vault self-signed root CA and Intermediate CA signed by root CA. Both CA’s are generated using the PKI backend. What’s the procedure for rotating root CA and Intermediate CA?

Regards,
Aravind M D

2

Just replace the file containing the certificate, there is no internal tracker for the certs.

I should point out that, as long as your have been careful with your key for your root certificate, it isn’t best practice to rotate it. You want to have a long lived root cert but each of the leafs should be rotated out rather than the root itself.

A good explanation: Smooth root certificate rotation - Information Security Stack Exchange

3

Yes there is - @ambadiaravind said they are using the PKI backend which stores this in the Vault storage.

For root CAs, the “rotation” procedure is essentially to create a new one from scratch, and distribute it to all clients which need to trust it. (This is why root CAs typically have such a long lifetime.)

In Vault terms, this means mounting another instance of the PKI secrets engine at a new path in Vault, and setting it up from scratch, as you did before.

For intermediate CAs, the story is rather more complex, as unfortunately Vault does not currently have good support for this. Here are some questions you need to ask yourself, as they determine exactly how you will go about an intermediate CA renewal:

  • Does it matter if your intermediate CA is unable to issue certificates for a while? In Vault as it is today, if you generate a new intermediate key and CSR in your existing PKI secrets engine, it will then be offline until you get the CSR signed and the new certificate uploaded.

  • Do you care about your Authority Information Access (i.e. downloading the CA certificate), and CRL Distribution Point URLs continuing to work properly throughout the transition? In Vault as it is today, if you generate a new intermediate CA in an existing PKI secrets engine, the AIA URL will switch to serving the new CA, and the CRL will be signed by the new CA, which may break clients depending on them and expecting the old CA.

  • Do you still have a copy of the old intermediate CA’s CSR? If so, would resigning it as is be acceptable (no change to CA key or name)? This is the easiest way to handle a renewal with maximum compatibility in Vault today.

  • How hard would it be to get all clients to switch to a new PKI secrets engine path in Vault for talking to the new CA? (If feasible, handle the intermediate CA renewal by setting up a new PKI secrets engine at a different path and move users over to it.)

Some GitHub issues which provide some further background reading on this problem with Vault are workflow for rotating generated intermediates without downtime? · Issue #2581 · hashicorp/vault · GitHub and the other issues linked at the end of its conversation.

4

To add what aram advised, is better use external offline root ca with longer certificates validity period 20 years, root ca should be offline.

5

@tsiamer External root CA usage is advised because of changes in mount point? or is there any other advantage?

6

@maxb Vault PKI backend is managed using terraform. Easiest option is to use new path and propagate the changes.

7

For security reasons, just bring it online for crl and signing, revoking … certs for subordinate when needed.

1 Like
8

Hello,

I’m testing the CA rotation as described in

First I ran created the pki

vault write -field=certificate pki-test2/root/generate/internal \
>      common_name="example.com" \
>      issuer_name="root-2022" \
>      ttl=87600h 
-----BEGIN CERTIFICATE-----
MIIDNTCCAh2gAwIBAgIUZl2VAULdly1EsjRIetBprmtMjIkwDQYJKoZIhvcNAQEL
BQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjIwNzA4MDAxOTM5WhcNMzIw
NzA1MDAyMDA5WjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAM1VB00/Fn3yErPgggZaALDF95xT7MQ6vt5PusDc
Gmm7sU1RRJT9E1971/hIf3YO1940uRMUwCOfdaIi+5M03RjB1xpgoB8Og5Qnspy6
x1WfPqNiT8ECztVm7s6dPMgJuVbyQ2qiLY/+TEAgpa5Ak5cVnVIdeLwPBkl2T+O/
OGLLcov/zs78OxzTdRn55ux3rqZdLnDCw117CaPPqA87+SPOYL8BKVmt1oiHw+MZ
4BAR659UYGeftDmJaQ7hbTensciprjD+Lf4amTLMC3DsDfqluA0Yv24NAzePToac
XPkBAoHFJCHC3YdbZfkMr2ZtQ16hnIzjWDB4jZc/nQR76TsCAwEAAaN7MHkwDgYD
VR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGzpj5UMCXZz
86FWFgJtDwN+drldMB8GA1UdIwQYMBaAFGzpj5UMCXZz86FWFgJtDwN+drldMBYG
A1UdEQQPMA2CC2V4YW1wbGUuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAiMfqQOY3W
o6tTRXuDt7yFLBofqDNnV8EIo3HTMk6ikC1L797SVlYAN2CoTxvFVFrw2rpsbAMV
i4/bgromOYcCxZ9XTfOxYsyYCcwPeA1UCopQtE8JbxUnr7hJtzbVbPao4loCCIAM
iKgc/wOWcCJ9mlwKZVdaHfdV6TmDyrZFsGLqv7xBQ4RyihymZvtRC4q9XsJd1lnR
QVJB34l27e+TD0X3ymR79GLdMhXmbsLw1hn8Ok12aEt56KfKYtFoChM/AqFTGvlW
Y4YNoonLrepq3NEiSl69oSEQ6XPkMj02qs8txxGhyUE/ybkPg1agy/F2i73CuVFW
KgZJ8fEN1wgw
-----END CERTIFICATE-----
/ $ 
/ $ vault write pki-test2/config/urls \
>     issuing_certificates="http://127.0.0.1:8200/v1/pki-test2/ca" \
>     crl_distribution_points="http://127.0.0.1:8200/v1/pki-test2/crl"
Success! Data written to: pki-test2/config/urls
/ $  vault list pki-test2/issuers
No value found at pki-test2/issuers

So why can’t I list the issuers as the instructions say?

When I tried to rotate it

vault write pki-test2/root/rotate/internal \

common_name="example.com" \
issuer_name="root-2023"

Error writing data to pki-test2/root/rotate/internal: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/pki-test2/root/rotate/internal
Code: 404. Errors:

  • 1 error occurred:
    • unsupported path

/ $

So why I cannot list or rotate the root certificate?

Le