Question
Limits of Teleport's certificate_revocation_check on Active SSH Sessions
Ari Finch
0 reputation · 12 Dec 2025, 07:47 UTC
72.7K views1
Loading…
0 reputation · 12 Dec 2025, 07:47 UTC
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?
35275 reputation · 12 Dec 2025, 11:56 UTC
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.
teleportidle_timeout value, the server disconnects it.max_session_ttl is terminated regardless of activity.teleport version to understand the exact revocation handling in that release.auth_service section of teleport.yaml for the certificate_revocation_check flag and confirm it is set to true.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.session_termination_on_revocation feature (if available) to have the server terminate sessions as soon as a revocation is detected.# teleport.yaml – auth_service section
auth_service:
certificate_revocation_check: true
idle_timeout: 5m
max_session_ttl: 30m
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.
To give you a definitive recommendation, could you share the Teleport version you are running (e.g., 14.0.0)?
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 12 Dec 2025, 12:56 UTC
certificate_revocation_check flag primarily affects the authentication handshake. Once an SSH or Kubernetes session is established, Teleport does not typically continuously re-validate the valid-until field or the revocation status of the active stream.To enforce session termination after a certificate expires or is revoked, you must rely on the following mechanisms:
To verify your specific environment's behavior, issue a short-lived certificate and observe if the connection remains open after the certificate's timestamp passes. If it persists, you must reduce your max_session_ttl to ensure more frequent validation checks.