OCSP versus een CRL: hoe elke intrekkingscontrole echt werkt

Een van deze twee intrekkingscontroles geeft een ondertekend antwoord over één certificaat terug, en de andere geeft een ondertekende lijst terug die je in zijn geheel downloadt. Beide moeten een verifieerder vertellen of een referentie nog vertrouwd is, en beide falen op manieren die totaal niet op elkaar lijken. De volgorde hieronder volgt wat een operator in productie werkelijk tegenkomt, van de bytes op de draad tot een gateway die een verbinding weigert. Een stap overslaan is de manier waarop een uitrol eindigt met een intrekkingsbeleid dat alleen op papier bestaat.

Stap 1: Wat elke controle teruggeeft en hoe lang die bruikbaar blijft

Een CRL wordt gepubliceerd als één ondertekend object dat elk certificaat dekt dat een uitgever heeft ingetrokken, dus een verifieerder haalt hem één keer op en hergebruikt hem tot de nextUpdate van de lijst verstreken is. Een OCSP-antwoord is smaller: het antwoordt voor precies één certificaat en draagt thisUpdate, producedAt en meestal ook nextUpdate. Dat verschil stuurt al het andere. Een gecachte CRL veroudert stil, omdat het bestand nog steeds parseert en de handtekening nog steeds verifieert, terwijl een verlopen OCSP-antwoord duidelijk waardeloos is op het moment dat je de tijdstempels leest.

Caching is daarom het eerste dat moet worden vastgelegd: welke component de kopie vasthoudt, en welk plafond die kopie volgt. Op een gateway moet het plafond nextUpdate min een veiligheidsmarge zijn, nooit wat een HTTP-cacheheader toevallig voorstelt. openssl crl -in issuer.crl -noout -lastupdate -nextupdate drukt beide datums af, en een lijst waarvan de nextUpdate al in het verleden ligt, moet als ontbrekend worden behandeld en niet alleen als oud.

Stap 2: Waar het certificaat de client naartoe stuurt

Het bladcertificaat draagt meestal twee aanwijzingen: een CRL-distributiepunt-extensie en een autoriteitsinformatietoegang-item voor OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints drukt de eerste af, en de tweede staat onder de AIA-sectie van openssl x509 -in client.pem -noout -text. Elk van die extensies is een aanwijzer, geen verplichting. Een client die nooit intrekkingscontrole implementeert, verbindt prima met een certificaat waarvan de extensies een responder noemen die al een jaar dood is.

Distributiepunten noemen vaak een interne host die alleen binnen één netwerksegment resolveert, en sommige oudere clients weigeren ldap-URL's botweg. Test de bereikbaarheid vanaf de host die de tunnel termineert, niet vanaf je eigen laptop, want dat is het enige gezichtspunt waarvan het falen echt telt.

Stap 3: Kies fail-closed of fail-open vóór de storing

Een onbereikbare responder of een verlopen lijst dwingt een beslissing af: de verbinding weigeren, of hem accepteren en het gat vastleggen. De verify-subopdracht van OpenSSL maakt de strikte keuze expliciet, want het toevoegen van -crl_check maakt van een niet-beschikbare CRL unable to get certificate CRL en een mislukte verificatie. Soft-fail is in de meeste stacks helemaal geen vlag, het is de afwezigheid van de controle, en precies daarom wordt het per ongeluk meegeleverd.

Om te zien welk gedrag een client werkelijk heeft, haal de responder weg en verbind opnieuw. Als de tunnel toch omhoog komt, zoek dan de logregel die de overgeslagen controle vastlegde, en vraag dan of iemand die regel tijdens een incident zou lezen. Dezelfde leverancier kan per protocol verschillen, met een IKEv2-client en een OpenVPN-client op één machine die ongerelateerde configuratieknoppen lezen.

Stap 4: Bewijs dat de controle draait waar verkeer wordt toegelaten

Zoek het proces dat de verbinding termineert of autoriseert, en vraag het naar de configuratieregel die intrekkingscontrole inschakelt. Een gateway die de keten valideert maar nooit naar intrekking vraagt, handhaaft een ander beleid dan dat in je documentatie, en geen screenshot van een certificaatketen bewijst het tegendeel. OpenVPN schrijft de optie als crl-verify; strongSwan houdt CRL- en OCSP-opzoekingen onder de CA-configuratie, waar crl_uris of ocsp_uris worden gezet. Als je naar geen van beide kunt wijzen, neem dan aan dat de controle ontbreekt.

Een OCSP-antwoord telt alleen wanneer de uitgevende CA het heeft ondertekend, of wanneer een responder met het door die CA gedelegeerde uitgebreide sleutelgebruik OCSPSigning het heeft ondertekend, dus een antwoord van een ongerelateerde dienst bewijst niets. Als je de responder zelf draait, monitor hem dan als een harde afhankelijkheid, want één dode dienst wordt tegelijk een storing voor elke fail-closed-client.

Stap 5: Trek één certificaat met opzet in

Neem een testcertificaat, trek het in via hetzelfde kanaal dat productie gebruikt, en vraag het de responder direct. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text zou Cert Status: revoked moeten melden samen met een intrekkingstijd, en een antwoord good betekent dat je intrekking de responder die je clients bevragen niet heeft bereikt. Voer daarna openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem uit om dezelfde beslissing via het lijstpad te zien. Lees de redenreeks in plaats van de exitcode, want een intrekkingsweigering en een ketenfout eindigen beide in een mislukking.

De stap die er echt toe doet, is de laatste: verbind opnieuw met het oude profiel tegen het echte handhavingspunt en bevestig dat de weigering van intrekking komt. Verbind daarna opnieuw met een vers, geldig certificaat om te bewijzen dat je niet alleen de listener hebt gebroken. Het profiel op de client verwijderen bewijst niets over de beslissing van de server, en een geslaagde openssl verify-run op een machine die nooit een tunnel termineert al evenmin. RFC 6960 definieert wat een conform OCSP-antwoord bevat, inclusief de statuswaarden die deze test leest.