Large TLS deployments often need signing capability on many serving machines. Copying the certificate private key to every endpoint expands the set of systems whose compromise can expose a long-lived credential. Keeping that key in one tightly controlled location reduces exposure, but remote signing for every handshake can add an operational dependency to the serving path.
Delegated Credentials for TLS, standardized in RFC 9345, provide a narrower option for TLS 1.3. A certificate holder can use its certificate private key to authorize another public key for a limited period. The endpoint receives the corresponding delegated private key and can authenticate TLS handshakes without holding the certificate private key itself.
The delegation is bounded. It does not create a new certificate, alter the certificate chain, or give the delegated key authority beyond the credential accepted by a supporting client.
The certificate key authorizes a temporary TLS signing key
A delegated credential contains a public key, a validity value, an expected certificate-verify algorithm, and a signature made using the certificate’s private key. That signature connects the temporary key to the certificate presented in the TLS handshake.
The corresponding delegated private key can be distributed to an edge server. During a TLS 1.3 handshake, that server signs the CertificateVerify message with the delegated key rather than the certificate private key.
A supporting client verifies two separate signatures. It verifies the signature on the delegated credential using the certificate public key, then verifies the handshake’s CertificateVerify signature using the public key carried by the delegated credential.
The certificate chain still has its ordinary PKI role. Delegated credentials add an authorization layer beneath the end-entity certificate; they do not replace certification-path validation.
Client support is negotiated
A server cannot assume that every TLS 1.3 client accepts delegated credentials. RFC 9345 defines the delegated_credentials extension so a client can advertise the signature algorithms it supports for delegated credentials.
Only after the client advertises support can the server use a delegated credential in the corresponding handshake. The server sends the credential in an extension associated with its end-entity certificate.
This negotiation property matters during deployment. A service that must support clients without the extension still needs a compatible authentication path for those clients. Delegated credentials therefore do not automatically eliminate all access to the certificate private key from the broader serving architecture.
The exact fallback design is an operational choice. Its security boundary should be reviewed separately because a fallback that broadly redistributes the certificate key can erase much of the exposure reduction gained on delegated paths.
Lifetime is deliberately constrained
The delegated credential carries a validity interval expressed relative to the certificate’s notBefore time. RFC 9345 limits the delegated credential to no more than seven days and requires it to remain within the certificate’s own validity period.
A short lifetime limits the useful period of a stolen delegated private key. It also creates a rotation requirement: infrastructure must mint, distribute, activate, and replace credentials often enough to avoid service interruption.
That trade is intentional. A credential that can be replaced frequently can be placed closer to serving infrastructure, while the certificate private key can remain in a more restricted signing environment.
Short lifetime is not instant revocation. If a delegated private key is copied by an attacker, the credential can remain usable until clients stop accepting it under the protocol’s time checks or until another control prevents its use. Operational response plans should account for that interval.
The certificate has to permit delegation
A delegated credential cannot be attached to any certificate without preparation. RFC 9345 defines the DelegationUsage X.509 extension. The end-entity certificate must contain this extension for a client to accept a delegated credential.
This requirement gives the certificate issuer and certificate holder an explicit boundary. A certificate lacking DelegationUsage cannot silently acquire delegated-credential behavior merely because a server sends an extra TLS extension.
Certificate issuance workflows therefore need to request and verify the extension where delegated credentials are intended. Rotation workflows also need to preserve the required property when replacing the end-entity certificate.
The delegated credential is additionally bound to the certificate that signed it. Replacing the certificate requires new delegated credentials; an old delegation is not transferable to a different certificate.
Algorithm choices are checked at both layers
TLS authentication already depends on signature-algorithm negotiation. Delegated credentials add another key and another signature, so implementations must keep the roles distinct.
The certificate key signs the delegated credential using an algorithm acceptable under the protocol rules. The delegated key signs CertificateVerify using the algorithm recorded for that purpose in the credential. Client-advertised capabilities constrain what the server can send.
This permits the delegated key to use a different key type or signature algorithm from the certificate key when the negotiated and protocol requirements permit it. The separation can help deployments move handshake signing to keys suited to edge infrastructure without replacing the certificate solely for that purpose.
It does not relax cryptographic validation. Unsupported algorithms, invalid signatures, malformed credentials, or credentials outside their accepted time bounds must not be treated as successful authentication.
Key isolation still depends on the surrounding system
Delegated credentials reduce the need to expose a certificate private key, but they do not secure the endpoint that holds the delegated private key. Compromise of that endpoint can still expose a credential capable of authenticating the covered service for its remaining accepted lifetime.
Distribution also becomes a security-sensitive path. The delegated private key must reach the intended serving systems without leaking to unauthorized systems, and expired material should not remain active in serving configuration.
The signing service that holds the certificate private key is especially sensitive. It decides which delegated public keys receive authorization. Strong access control, auditability, and constrained issuance are needed so the delegation mechanism does not become a convenient route for minting unauthorized serving credentials.
Operational monitoring should track credential age, activation, replacement, and failed issuance or distribution. A seven-day protocol ceiling is not a substitute for observing whether rotation is actually functioning.
Delegation narrows the blast radius of edge key compromise
The central benefit is key separation. The certificate private key can remain in a restricted environment while edge systems receive credentials with a much shorter useful lifetime.
That boundary is precise rather than absolute. A stolen delegated key can still authenticate within its accepted window, unsupported clients may require another authentication path, and the delegation issuer remains a high-value component.
Used with controlled issuance and reliable rotation, delegated credentials reduce the amount of long-lived certificate key material exposed to serving infrastructure while preserving normal certificate-chain authentication for TLS 1.3 clients that support the extension.