X509-SVID TTL Debugging Feedback With UpstreamAuthority Vault

[elee]

While upgrading SPIRE from version 0.10.0 to 0.11.1 I introduced a misconfiguration that made SVIDs expire earlier than expected (whoops!), this, in turn, triggered internal monitors alerting the team to the unexpected behavior and provoked me to debug. When SPIRE issues SVIDs it would be helpful to have a built-in command to easily explain why a particular expiry (ttl) exists on a certificate given its .

Background

After upgrading spire-server from 0.10.0 to 0.11.1 SVIDs issued to a particular workload were being issued with a 24h expiry instead of a 72h expiry prior to the upgrade. To start debugging this I examined three things:

1. The Workload's Registration Entry - to see if the ttl had been modified with spire-server entry show

2. The intermediate signing cert of a single spire-server - to determine the duration of it's Validity

openssl s_client -showcerts -connect localhost:$SPIRE_LISTENING_PORT

3. The Intermediate Cert Authority in Vault - which we refer to in spire-server as our vault UpstreamAuthority

It turned out the misconfiguration was not specifying a top-level ca_ttl value which defaulted (reasonably) to 24h, making this modification returned the system to the expected behavior. The SVIDs were issued 24h expirys because that was the lifetime of the signing keys in each upgraded spire-server after the upgrade.

Suggestion

It would have speeded the investigation for an operator to have a command or API to exercise to preview what an SVID's ttl value would be an how SPIRE arrived at that value.

Something like

spire-server entry explain -spiffeID spiffe://trustdomain.fqdn.com/workload-name

With output containing openssl s_client -showcerts-like output:

depth=3 CN = some-root
expiry: 1y
depth=2 CN = some-spire-ica
expiry: 1mo
depth=1 C = US, O = SPIFFE, CN = trustdomain.fqdn.com
expiry: 72h
depth=0 C = US, O = SPIRE
expiry: 24h

• Version: 0.11.1
• Platform: Debian
• Subsystem: Server

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 30 days since being marked as stale.