Hello, we are curently testing a large-scale rollout of EAP-TLS for eduroam purposes. One of the things we observed is that if an authentication uses TLS session resumption, the server does not re-check the OCSP state of the client cert that was used to login initially. So, in a scenario where - cert is valid, user authenticates with a full EAP-TLS handshake - cert gets revoked - user re-authenticates with session resumption then the authentication does NOT fail but succeed. Looking at the TLS-Client-Cert-* attributes which get restored from session cache, it looks like it could be easy to do that though - the serial number of the cert is saved; and the OCSP responder URL maybe isn't but could be. And with both pieces of information, another OCSP check can be run even on a resumed session. A related question: how is the cache lifetime determined? When config sets it to 24 hours, is that 24 hours after the initial, full, authentication, or is that lifetime refreshed with every re-auth, meaning the cache expires after 24 hours of non-use? If the latter, a revoked user could perpetually prolong his account lifetime even if OCSP wouldn't want to let him. Also, something we didn't check but that just now comes to my mind: does the server check the expiry time of the cert on a resumed session? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66