FR: Sign X.509-SVIDs with a static, externally-anchored CA (no SPIRE-minted downstream intermediate)

[calderonth]

Summary

SPIRE Server always signs X.509-SVIDs with an intermediate CA that SPIRE generates and rotates itself — either self-signed, or minted as a downstream of a configured UpstreamAuthority. There is no way to sign directly with a pre-existing, long-lived intermediate that the server doesn't own.

This requests an "external CA" mode where SPIRE Server loads an operator-supplied intermediate CA (+ root), signs SVIDs directly with its key via crypto.Signer (PKCS#11 as the first backend), treats the X.509 CA as static (no rotation), and keeps JWT key rotation unchanged.

The gap

1. Intermediates are commonly issued leaf-constrained (CA:TRUE, pathlen:0), forbidding any CA beneath them. SPIRE's flow requires minting a downstream sub-CA, which such a cert cannot legally sign — chains fail path validation at conforming verifiers.
2. Mandatory rotation breaks non-SPIFFE consumers. SPIRE rotates its X.509 CA frequently by design. Heterogeneous systems consuming SPIRE-issued certs — with no SPIFFE-aware edge to abstract trust away — can't continuously re-fetch the bundle and refresh chains. A stable, externally-anchored CA removes that friction.
3. The workaround adds CA-management burden. Provisioning a pathlen≥1 intermediate just so SPIRE can mint short-lived sub-CAs relaxes existing PKI policy and introduces a new problem: securely authorizing each spire-server to request and hold a signing-capable sub-CA. Signing directly with a fixed CA sidesteps this.

Proposed behavior

An experimental server { experimental { external_ca { … } } } block that:

• takes a root cert, an intermediate (signing) cert, and a crypto.Signer reference for the key (PKCS#11 first; design is signer-agnostic);
• validates at startup that the intermediate is signed by the root and is a CA cert (fail fast otherwise);
• uses that intermediate as the active X.509 signing authority and publishes root + intermediate in the trust bundle;
• disables X.509 CA rotation; leaves JWT rotation untouched.

Config sketch

  server {
    experimental {
      external_ca {
        enabled              = true
        root_cert_file_path  = "/etc/spire/certs/root.pem"
        cert_file_path       = "/etc/spire/certs/intermediate.pem"
        pkcs11 {
          pkcs11_uri    = "pkcs11:module-path=/usr/lib/.../libXXX.so;token=SPIRE;pin-value=…"
          pkcs11_object = "pkcs11:object=intermediate-ca-key"
        }
      }
    }
  }

Scope / non-goals

• Not changing JWT-SVID behavior — JWT keys still rotate.
• Not rotating/re-issuing the external CA — its lifecycle is owned by the external PKI; SPIRE consumes it read-only.
• Not replacing UpstreamAuthority — this is "sign directly with a supplied static CA," not "mint a downstream from an upstream."
• SPIRE already supports HSM/KMS-backed signing via several UpstreamAuthority/KeyManager plugins. The novelty here is direct signing with a static, externally-owned CA.

Alternatives considered

• UpstreamAuthority (disk/vault/PKCS#11-backed): still mints and rotates a SPIRE-owned downstream; incompatible with pathlen:0, still rotates the signing CA and doesn't scale well in heterogenous environments.
• Provision a pathlen≥1 intermediate: relaxes PKI policy and adds sub-CA bootstrapping/management on every server.

Contribution

I have this experimental feature implemented and I will shortly link a PR to support the above which can help with the discussion.

[amartinezfayo]

Thank you for bringing this up and for contributing an implementation to ground the discussion. The pain points are real and recurring: PKI teams commonly issue only leaf-constrained intermediates, and non-SPIFFE consumers struggle with rotating trust material. This is close to what #525 asked for many years ago, and it overlaps substantially with #6711.

However, I don't think SPIRE should adopt a static, non-rotating X.509 signing authority. Automatic rotation is a core SPIFFE/SPIRE design principle: it bounds the exposure window of a compromised authority and keeps a prepared next authority to fail over to. A static mode also cuts across the CA manager's rotation machinery in ways that are hard to support safely.

I believe the requirements can be met without freezing rotation. With an UpstreamAuthority, the X.509 anchors in the trust bundle are only the static upstream roots, while the rotating SPIRE CA travels in the SVID chain, so non-SPIFFE consumers anchor once at the external root. SPIRE also uses the upstream-returned certificate directly as its signing CA (no sub-CA beneath it), so if your PKI signs each rotated SPIRE CA directly, every one of them can itself be pathlen:0. The missing piece is a PKCS#11 KeyManager plugin, which would keep every rotated key inside the HSM. For cases where the PKI cannot issue online or the signing key must come from a formal key ceremony, #6711 proposes a pluggable ServerCA / RA mode that delegates per-SVID signing to an external signer, with the CA lifecycle owned by the external PKI rather than frozen by SPIRE. A PKCS#11-backed implementation of that interface is essentially what #7020 builds, behind a proper plugin boundary.

To figure out which path fits your environment, I have a few questions:

1. Can your PKI issue CA certificates to SPIRE through an automated channel? Existing plugins cover aws_pca, gcp_cas, vault, cert-manager, and ejbca, and if your PKI instead exposes a standard enrollment protocol with a sub-CA profile, a new UpstreamAuthority plugin is also an option. Or is a single pre-issued intermediate the only choice?
2. Is the hard constraint that the signing key must pre-exist (e.g., generated in a witnessed key ceremony for FIPS compliance), or only that issued intermediates must be pathlen:0?
3. Would your policy allow SPIRE to generate its rotating CA keys inside the HSM via a PKCS#11 KeyManager, if each rotated CA is signed directly by your PKI?
4. Do your non-SPIFFE consumers validate the full chain presented in handshakes (so a stable root anchor suffices), or do they pin the intermediate itself?
5. If the intermediate must be static, would the per-SVID delegated signing proposed in Pluggable ServerCA / RA mode for external per-SVID signing #6711 work for you, with renewal of the intermediate staying with your PKI?

Depending on the answers, I'd suggest reorienting the contribution toward a PKCS#11 KeyManager plugin (possibly with a new UpstreamAuthority plugin), or bringing the PKCS#11 signing work into the #6711 design discussion. In any case, I think we should settle the design here before investing more time in the PR. Happy to discuss further here or at a contributor sync.

[RufusJWB]

would it be an option to avoid operating a (leaf) CA in SPIRE totally but use SPIRE only as a RA and send certificate request messages (ideally over CMP) to an upstream CA?

[calderonth]

Thanks for the responses, sorry I have meant to reply to this earlier.

Can your PKI issue CA certificates to SPIRE through an automated channel? Existing plugins cover aws_pca, gcp_cas, vault, cert-manager, and ejbca, and if your PKI instead exposes a standard enrollment protocol with a sub-CA profile, a new UpstreamAuthority plugin is also an option. Or is a single pre-issued intermediate the only choice?

Not really no, our RootCA is an offline CA that is brought online using a key-ceremony when we need to issue new Intermediates (not something that happens frequently). We have mutliple intermediate CAs under that root of course to support multiple sites where the intermediate key material lives in HSMs.

Is the hard constraint that the signing key must pre-exist (e.g., generated in a witnessed key ceremony for FIPS compliance), or only that issued intermediates must be pathlen:0?

Both, disallow our intermediate to issue new CAs (i.e. pathlen:0) and the key material must remain in the HSM. So currently hooking spire-server to our intermediateCA server+HSM seems like the path of least resistance to unlock us.

Would your policy allow SPIRE to generate its rotating CA keys inside the HSM via a PKCS#11 KeyManager, if each rotated CA is signed directly by your PKI?

This would still currently conflict with our rootCA being offline and pathlen:0 constraints.

Do your non-SPIFFE consumers validate the full chain presented in handshakes (so a stable root anchor suffices), or do they pin the intermediate itself?

We would generally have them validate the full-chain.

If the intermediate must be static, would the per-SVID delegated signing proposed in #6711 work for you, with renewal of the intermediate staying with your PKI?

I think this is possibly the most promising option to pursue if this proposal doesn't proceed. We of course have a PKI software that understand the concept of provisioners that map to certain profiles, this is how we issue identities outside spire. So delegating the signing part to the actual existing PKI would work and align even more to our current model. However, I haven't read the proposal in detail but this seems that this would require a fair chunk of mechanical changes in order to be supported too (i.e. some of the fundamental around CA rotation being a building block).

@RufusJWB I think what you're proposing is similar to what @sorindumitru suggested in #6711?

[RufusJWB]

@RufusJWB I think what you're proposing is similar to what @sorindumitru suggested in #6711?

Potentially yes. I wrote a response to the linked issue to clarify my points.