Spire will create CAs that are longer lived than the upstream CA

[drewwells]

• Version: 1.7.1
• Platform: linux
• Subsystem: server

Spire will create a CA that outlives the upstream CA being signed with. This doesn't appear to be an issue for standard mint/verify workflows on a single spire, but it does cause federation to stop working. Take the following use case.

ServerA and ServerB are configured with an upstreamCA that lasts 1month, their internal CA_TTL is set to 6 months.

ServerA is configured to trust ServerB using Web PKI (https_web). ServerA calls ServerB's PKI endpoint https://serverb.com/ and gets a payload of keys like this

{ keys: [{"use": "x509-svid", "x5c": ["{{base64encoded upstream CA public key}}"}, { "jwt-svid" ... }...}]}

Now we have a uni-direction federation link that will stop working in 1month.

Repo Steps:

1. Fast forward 1month + 1second... [[touch the ground to speed up time]]
2. client mints a token on ServerB
3. Client verifies the token on serverA. ServerA reports an error like this:

SVID is not valid: public key "X5ZOAszrYj0LnaHdUqRWLZcMtzpgcY9L" not found in trust domain "serverb.com"

4. Notice serverA makes no attempt to refresh the bundle on errors. Also no errors are mentioned about the bundle being untrustworthy due to upstreamCA public keys

[azdagron]

I've confirmed this behavior. While we ensure the upstream CA is valid, we don't check the lifetime of the intermediate relative to the root.

1.10.0 would be a good time to get this stricter validation in.

[evan2645]

SPIRE Server should grow a defensive feature to detect upstream mis-issuance wherein intermediate CA is issued to SPIRE with a lifetime that exceeds one or more of the certificates in the chain above it. When this condition is detected, SPIRE Server should adjust its CA rotation timing accordingly to prevent its locally held intermediate from becoming invalid (due to chain expiry). A warning should be logged when this condition is detected.

If the upstream doesn't rotate before expiry, it could be possible that SPIRE Server gets into a loop renewing as the expiry approaches. This should also be detected and prevented, perhaps implemented as some kind of floor on the renewal cycle.

@drewwells any chance you're interested or able to pick this up?

[drewwells]

I'm interested but I have no time to work on this for at least a few weeks. Happy to punt this to someone to look at.

I also don't work on our spire integration any longer, so it will be challenging for me to test it in the field moving forward. This issue has made the last 3months of my work life very hard :|

[evan2645]

Understood, thanks @drewwells

What UpstreamAuthority are you using when you hit this?

[drewwells]

certmanager self-signed CA