Un client identifie l'émetteur et le numéro de série du certificat auprès d'un répondeur OCSP, qui retourne un statut signé good, revoked ou unknown avec une information de temps.
L'application utilisatrice authentifie la réponse et décide si elle est fraîche et applicable. Dans Transport Layer Security, l'OCSP stapling permet à un serveur d'attacher à la poignée de main une réponse en cache signée par le répondeur, réduisant les requêtes et la dépendance au répondeur.
Points clés
Signification de la réponse« Revoked » porte des données de révocation, tandis qu'« unknown » signifie que le répondeur ne connaît pas le certificat. Sous RFC 6960, « good » signifie au minimum qu'aucun certificat correspondant n'est enregistré comme révoqué ; cela ne prouve ni émission ni validité.
Fraîcheur et rejeuVérifier thisUpdate, nextUpdate, producedAt, la politique d'horloge locale et la liaison requête-réponse. RFC 6960 est un Proposed Standard ; RFC 9654 met à jour son extension de nonce, qui peut réduire le risque de rejeu mais affecte la mise en cache.
Vie privée et disponibilitéLes requêtes directes peuvent révéler au répondeur les certificats qui intéressent le client. Le stapling peut réduire cette divulgation et la dépendance réseau, mais les réponses en cache exigent toujours une validation correcte et un rafraîchissement en temps utile.
Limite importanteL'OCSP ne peut fournir une assurance de révocation fiable lorsque le statut est périmé, indisponible, non fiable ou ignoré. Des clients en échec toléré (soft-fail) peuvent continuer après une panne du répondeur, affaiblissant la révocation ; une politique d'échec strict (hard-fail) peut au contraire transformer les pannes du répondeur en pannes de service.