Problème révocation certificats PKI Vault

salut ! la révocation TLS ça marche pas tout seul. le client doit activement vérifier la révocation. tes clients implémentent la vérification de la CRL (Certificate Revocation List) ou de l'OCSP (Online Certificate Status Protocol) ? si non, ils vont accepter le certif tant qu'il est valide au niveau de sa date d'expiration.

ah ok je pige. j'ai bien activé la génération de CRL sur mon backend pki vault et j'ai des endpoints pour la crl et l'ocsp mais non, mes clients sont des services go/python maisons et j'ai rien implémenté pour vérifier les CRLs/OCSP. je pensais que c'était plus "automagique" au niveau du handshake TLS.

non pas du tout. le TLS est par nature stateless. quand un client reçoit un certif, il vérifie la chaîne de confiance et la date. pour la révocation, il doit faire une requête spécifique (HTTP pour CRL, OCSP pour son service dédié) pour voir si le certif est sur liste noire. tu dois soit modifier tes clients pour qu'ils fassent cette vérif, soit mettre un proxy devant qui le fera.

si tu pars sur OCSP, assure-toi que ton `ocsp_url` dans la config du backend pki de vault est accessible par tes clients et que vault lui-même peut signer les réponses OCSP. et surtout, les certificats générés doivent inclure l'extension OCSP pour indiquer où trouver le répondeur.

pour CRL, le plus simple est de publier la CRL sur un endpoint HTTP accessible publiquement (ou au moins par tes clients). vault peut le faire automatiquement avec `crl_distribution_points`. tes clients doivent alors télécharger cette CRL régulièrement et la mettre à jour pour savoir quels certifs sont révoqués.

attention, la révocation par CRL peut avoir un délai si la CRL n'est pas rafraîchie souvent. OCSP est beaucoup plus en temps réel, mais ça rajoute une requête réseau supplémentaire au handshake TLS. souvent, on utilise OCSP stapling avec un proxy pour éviter cette requête client.

si tes services sont en java, par défaut java ne checke pas la révocation. faut le forcer avec `System.setProperty("com.sun.net.ssl.checkRevocation", "true")` ou via le `java.security` file. pour go/python faut utiliser les libs spécifiques.

et si tu passes par un proxy comme envoy ou nginx, tu peux configurer la vérification ocsp/crl au niveau du proxy. c'est souvent plus simple à gérer pour une flotte de microservices que de modifier chaque client.

et n'oublie pas le cache OCSP/CRL sur tes proxys ou clients pour pas submerger vault de requêtes de vérification. des caches bien configurés peuvent réduire drastiquement la latence et la charge.

ok je pige beaucoup mieux maintenant ! c'est clairement un manque d'implémentation côté client. on va partir sur un reverse proxy (probablement envoy) qui fera la validation OCSP stapling et la gestion des CRLs. ça me semble le plus robuste pour notre infra. merci pour toutes ces explications détaillées les gars !