Limits of Teleport's certificate_revocation_check on Active SSH Sessions

Question

Goal: Determine whether an expired user certificate triggers immediate termination of an existing Teleport‑managed SSH (or Kubernetes) session when the Auth Server’s certificate_revocation_check flag is enabled.
Uncertainty: The documentation states that certificate expiry causes authentication handshake failures for new connections but does not specify if active sessions are torn down. Behavior may vary between Teleport Open Source and Enterprise editions, and settings such as idle_timeout or max_session_ttl can influence when reauthentication occurs, making it unclear if the flag alone can enforce least‑privilege revocation in‑flight.
Questions: Does enabling certificate_revocation_check cause Teleport to close active sessions upon certificate expiry? If not, what configuration or mechanism can be used to enforce immediate session termination? How do idle_timeout and max_session_ttl interact with this behavior?

Tasadduq Burney · Answer

Answer
Enabling certificate_revocation_check does not close an already‑established Teleport SSH or Kubernetes session when the user certificate expires. The flag only validates the certificate during the initial SSH handshake. Once the session is live, the server does not continuously re‑check the valid‑until field.
What actually ends a session

Idle timeout – if a session is idle for longer than the idle_timeout value, the server disconnects it.
Maximum session TTL – a session that has been running longer than max_session_ttl is terminated regardless of activity.
Enterprise revocation poll – Enterprise editions can be configured to periodically poll the revocation list and terminate sessions whose certificates are revoked, but this is a background process and does not act immediately on expiry.

How to enforce immediate termination

Verify your Teleport version with teleport version to understand the exact revocation handling in that release.
Check the auth_service section of teleport.yaml for the certificate_revocation_check flag and confirm it is set to true.
Set idle_timeout or max_session_ttl to a low value (e.g., 5 minutes) if you need sessions to be re‑authenticated quickly after a certificate’s valid‑until passes.
For Enterprise users, enable the session_termination_on_revocation feature (if available) to have the server terminate sessions as soon as a revocation is detected.
To confirm behavior, start an SSH session with a short‑lived certificate, wait until the certificate expires, and observe whether the connection drops or remains until the configured timeout.

Key configuration snippets
# teleport.yaml – auth_service section
auth_service:
  certificate_revocation_check: true
  idle_timeout: 5m
  max_session_ttl: 30m

What you still need to verify
Because Teleport’s revocation logic can change between releases, it is important to test the exact version you run. The steps above will help you confirm whether the session ends as expected.
Ask for missing detail
To give you a definitive recommendation, could you share the Teleport version you are running (e.g., 14.0.0)?

Limits of Teleport's certificate_revocation_check on Active SSH Sessions

1 answer

Answer

What actually ends a session

How to enforce immediate termination

Key configuration snippets

What you still need to verify

Ask for missing detail

Your perspective belongs here.

0 question comments