Why Enclave certificates don't expire¶

Enclave issues each enrolled system a certificate containing NotBefore and NotAfter fields. A value of -1 in the NotAfter field indicates the certificate has no expiry date.

    ...

    "NotBefore": 1549156210,
    "NotAfter": -1,

    ...

By default, Enclave issues certificates that are valid in perpetuity. If a system is compromised or decommissioned, its certificate should be revoked in the portal.

Why perpetual certificates are safe¶

Conventional wisdom in the TLS ecosystem favours short-lived certificates. The reasoning is sound for TLS: compromised certificates are hard to revoke, and the longer a certificate is valid, the longer it can be misused if the private key is stolen.

The TLS revocation problem stems from the fragmented nature of the ecosystem. Browser vendors, Certificate Authorities, system administrators and software developers all operate independently. OCSP responders and CRL distribution points are not universally reliable, and soft-fail behaviour is common practice. Short-lived certificates compensate for this by ensuring that even unrevoked certificates stop working after a brief window.

Enclave does not operate in this fragmented landscape and is not subject to the same constraints. Three properties of Enclave's architecture make perpetual certificates safe:

Instant, reliable revocation¶

Certificate revocation in the Enclave portal is instant and applied globally across your entire estate. Once a certificate is revoked, all connections to that system are immediately and irrevocably terminated, and no further connections can be established. There is no CRL to propagate, no OCSP responder to query, and no soft-fail path that allows a revoked certificate to continue operating. When indicators of compromise suggest that a system may have been attacked, its certificate should be immediately revoked in the portal - an operation which can also be automated using the Enclave REST API.

Forward secrecy through per-session keys¶

Enclave's certificate private key is used only for identity - proving that a system is who it claims to be. It is never used to encrypt tunnel traffic directly. Every time a tunnel is established between two peers, Enclave performs a fresh Curve25519 ECDHE key exchange to generate unique per-session encryption keys. This provides perfect forward secrecy: even if a certificate's private key were later compromised, previously recorded traffic cannot be decrypted because the session keys are ephemeral and never stored.

Revocation is key rotation¶

In the event of a confirmed compromise, revoking the certificate and re-enrolling the system generates an entirely new key pair and a new certificate. This is effectively key rotation - the compromised key material is permanently invalidated, and the system starts fresh. For undetected compromise where an attacker maintains persistent access, rotating the private key alone would have little effect, as the new key would simply be extracted from the same compromised system. The correct response is to remediate the compromised system, revoke its certificate, and re-enrol.

Comparison with TLS¶

The arguments for short-lived certificates in TLS do not transfer directly to Enclave:

Concern	TLS ecosystem	Enclave
Revocation reliability	OCSP/CRL are unreliable; soft-fail is common	Revocation is instant and enforced by the platform
Key exposure window	Longer certificate lifetime means longer exposure	Per-session ECDHE keys provide forward secrecy regardless of certificate lifetime
Forcing out weak cryptography	Short lifetimes push deprecated algorithms out of use	Enclave controls the cryptographic stack and can enforce algorithm changes through automatic updates
Automation	Short-lived certificates encourage automation	Certificate lifecycle is fully managed by the platform

For public infrastructure exposing TLS endpoints, short-lived certificates remain the right approach. For systems connected privately via Enclave, perpetual certificates provide equivalent security properties without the operational overhead of certificate renewal.

Controlling access without certificate expiry¶

Even with perpetual certificates, Enclave provides several mechanisms to limit when and how long systems can connect:

Certificate expiry via Enrolment Keys — Enrolment Keys can be configured with an expiry constraint so that resulting certificates are only valid for a fixed duration from the time of enrolment. This is useful for granting connectivity to partners, supply chain or contractors where an engagement has a known end date and the connection must not persist beyond it. See Enrolment Keys for details.
Active Hours — Each policy can restrict connectivity to specific hours of the day and days of the week. Outside those hours, the policy is inactive and connections governed by it are torn down. See Active Hours for details.
Revocation — A system's certificate can be permanently revoked at any time in the portal or via the API, immediately terminating all connections.

Having problems? Contact the Enclave team at support@enclave.io or visit the support options page.

Last updated August 1, 2026