Clarification on cross-signing

Vault
1

Hello,

I have a root ca (generated with vault 1.3 OSS )that is going to expire soon. Due to a problem in the process and design, we are signing certificate directly on it.

We would like to generate a new root and cross sign on intermediate with the new root CA and the old one. That way we will move everything to the new intermediate with little to no impact to our production

From my unterstanding the process to do what I want should be:

  1. Create new mount and generate a new CA with desired TTL (in my case 10years)

  2. Create a new mount for the intermediate and generate a CSR with the desired TTL (5year)

  3. Sign the CSR with the new CA and import it to the intermediate mount-point

  4. On the intermediate mount point, generate a cross-sign CSR using intermediate/cross-sign path and set the TTL to 5year also

  5. Sign this new CSR with the old CA. At this point I get the cert signed but I get a warning since the root is due to expire in 2023

The expiration time for the signed certificate is after the CA's expiration time. If the new certificate is not treated as a root, validation paths with the certificate past the issuing CA's expiration time will fail.

so what should I do from here? Just import this cert in my intermediate and ignore this?

Openssl is telling me that the generated cert is a CA so I should be OK I guess

        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                xxxxx:E6:0F:71:9E:4F
            X509v3 Authority Key Identifier: 
                keyid:xxxxx:2A:41:80:D7:A1

and the keyid seems to be from the old CA

$ openssl x509 -in old_ca.crt -noout -text | grep -A1 Identifier
            X509v3 Subject Key Identifier: 
                xxxxx:2A:41:80:D7:A1
  1. I import this new cert in my intermediate mount

if I try with openssl to valided my new cert (with the new intermediate in the chain) against the old CA it works, but if I try the same against my new root CA (generated/created on step 1 it fail)

openssl x509 -in new_root_ca -noout -text give me the following

            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                xxxxxD9:EF:39:D0:B4
            X509v3 Authority Key Identifier: 
                keyid:xxxxx:D9:EF:39:D0:B4

Im not sure to understand what Im doing wrong.

Anyone can help or confirm my process?

2

I think where you’re going wrong is trying to cross-sign the intermediate. Instead, you would cross-sign the new root CA with the old root CA, and then incorporate the cross-certificate into the chain served by the new intermediate CA.

i.e. the chain would look like:

  1. Subject: End Entity; Issuer: New intermediate CA
  2. Subject: New intermediate CA; Issuer: New root CA
  3. Subject: New root CA; Issuer: Old root CA
3

hum yeah probably I was trying to do an “extra” steps by generating the new root and cross-signing the intermediate. I will cross-sign the new root as you suggested :slight_smile:

4

Blockquote

Is this a good idea? Cuz what would happen if the Old root CA expires? Wouldn’t that mean the clients which only trust the old root CA will chain up to an old root and fail verifying?

@maxb please advise

5

@Damien what did you end up doing? How did it work out?