About the X.509-SVID Credential Provider
The X.509-SVID Credential Provider issues short-lived X.509 certificates that comply with the SPIFFE: Secure Production Identity Framework For Everyone (SPIFFE) is an open standard for workload identity that provides cryptographically verifiable identities to services without relying on shared secrets.Learn more(opens in new tab) standard. Each certificate embeds a workload’s SPIFFE ID as a URI Subject Alternative Name (SAN) for use with mTLS: Mutual Transport Layer Security. A TLS handshake in which both the client and server present certificates and validate each other's identity before any application traffic flows. mTLS is commonly used for workload-to-workload authentication where both parties must prove identity at the transport layer.Learn more in environments where SPIFFE-aware Server Workloads authenticate Client Workloads against their SPIFFE ID.
The X.509-SVID Credential Provider supports:
- SPIFFE-compliant certificates with the workload’s SPIFFE ID as a URI SAN.
- Literal or dynamic Subject and SPIFFE ID configuration.
- Signing through an Aembit Standalone Certificate Authority (CA).
- Configurable certificate lifetime.
- Configurable Extended Key Usage (EKU).
TLS client authentication (
id-kp-clientAuth) by default, with optional TLS server authentication (id-kp-serverAuth). - Automatic certificate rotation by Agent Proxy.
See Create an X.509-SVID Credential Provider to create one. To configure the Server Workload that authenticates the certificate, see Enable mTLS on a Server Workload.
Common use cases
Section titled “Common use cases”- Workload-to-workload mTLS - Mutually authenticated TLS between Client and Server Workloads with both sides validating certificates at the transport layer.
- Integration with SPIFFE-aware services - Connecting to Server Workloads that validate SPIFFE-compliant X.509-SVIDs, without running your own SPIFFE infrastructure.
- Zero Trust architecture - Cryptographically verifiable workload identities for environments that require identity proof on every connection.
- Managed identity issuance - Aembit-managed certificate issuance, rotation, and trust bundle: A collection of Certificate Authority (CA) certificates that a SPIFFE-aware workload uses to validate X.509-SVIDs and other SPIFFE identities presented during authentication.Learn more(opens in new tab) distribution as an alternative to running a SPIFFE control plane.
How the X.509-SVID Credential Provider works
Section titled “How the X.509-SVID Credential Provider works”-
Certificate issuance — Aembit Cloud signs each SPIFFE-compliant X.509 certificate using the Aembit Standalone CA assigned to the Resource Set or Client Workload that uses the Credential Provider. Each certificate carries the Client Workload’s SPIFFE ID as a URI Subject Alternative Name and is suitable for use with mTLS.
-
SPIFFE ID configuration — Aembit Cloud sets the URI SAN using your configured SPIFFE ID:
- Literal - Uses a fixed SPIFFE ID value that you provide (must start with
spiffe://). - Dynamic - Derives the SPIFFE ID from workload attributes using template expressions. For details, see Dynamic Claims for OIDC ID Token, JWT-SVID Token, and X.509-SVID Credential Providers.
- Literal - Uses a fixed SPIFFE ID value that you provide (must start with
-
Certificate consumption - Agent Proxy presents the certificate during the TLS handshake to a SPIFFE-aware Server Workload, which validates it against its configured trust bundle.
Configuration options
Section titled “Configuration options”The following sections describe the configuration options at a conceptual level. See Create an X.509-SVID Credential Provider for configuration steps.
Certificate subject
Section titled “Certificate subject”The Subject is the X.509 Distinguished Name (DN) carried in the certificate. SPIFFE-aware Server Workloads authenticate via the URI SAN, not the Subject DN, so the Subject DN doesn’t participate in identity verification. It functions as optional descriptive metadata—useful for audit logs, compliance frameworks that require a populated DN, or non-SPIFFE-aware Server Workloads that authorize clients by reading the Subject DN.
SPIFFE ID
Section titled “SPIFFE ID”The SPIFFE ID is the workload’s identity. Aembit embeds it as the URI Subject Alternative Name on the issued certificate, and SPIFFE-aware Server Workloads authenticate the Client Workload by matching this value against their configured trust policy.
Configure a literal SPIFFE ID when a single workload uses the Credential Provider, or a dynamic expression when one Credential Provider issues distinct identities to multiple workloads based on attestation attributes (for example, Kubernetes namespace and service account).
Certificate lifetime
Section titled “Certificate lifetime”Certificates are short lived by design. Agent Proxy rotates them automatically before expiration.
TLS handshake roles
Section titled “TLS handshake roles”Every certificate carries an Extended Key Usage (EKU) value that controls which side of the TLS handshake it can authenticate.
By default, Aembit Cloud issues the certificate with id-kp-clientAuth, which authenticates the certificate
holder when it initiates outbound TLS—the role Agent Proxy plays when presenting the certificate on behalf of
a Client Workload calling an upstream service.
Include id-kp-serverAuth in the Credential Provider’s Extended Key Usage field when the same workload also
accepts inbound TLS connections and needs to present this certificate to the connecting party.
Certificate constraints
Section titled “Certificate constraints”All issued certificates carry the following constraints:
- The certificate can’t sign other certificates.
- Subject Alternative Name is restricted to URI SAN only. No DNS or IP SANs.
- Aembit Cloud sets the SPIFFE ID URI SAN during signing; Agent Proxy cannot modify it in the request.
Limitations
Section titled “Limitations”- Certificate revocation — Aembit does not publish Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) responders for X.509-SVID certificates. Short certificate lifetimes and automatic rotation are the primary controls.
- External CA chaining — You can’t chain X.509-SVID issuance to a non-Aembit-managed root CA. Aembit Cloud always signs X.509-SVID certificates with an Aembit Standalone CA; you cannot substitute a different root CA.
- Service mesh integration — Direct integration with service mesh certificate provisioning (such as Istio) is not supported.