OCSP teenoor ’n CRL: hoe elke herroepingskontrole in die praktyk werk

Een van hierdie twee herroepingskontroles gee ’n ondertekende antwoord oor ’n enkele sertifikaat terug, en die ander een gee ’n ondertekende lys wat jy in die geheel aflaai. Albei is bedoel om vir ’n verifieerder te sê of ’n bewys nog vertrou word, en albei faal op maniere wat niks na mekaar lyk nie. Die volgorde hieronder volg wat ’n operateur werklik in produksie teëkom, van die grepe op die draad tot by ’n poort wat ’n verbinding weier. Om ’n stap oor te slaan, is hoe ’n ontplooiing eindig met ’n herroepingsbeleid wat net op papier bestaan.

Stap 1: Wat elke kontrole teruggee en hoe lank dit bruikbaar bly

’n CRL word gepubliseer as een ondertekende objek wat elke sertifikaat dek wat ’n uitreiker herroep het, so ’n verifieerder haal dit een keer en hergebruik dit tot die lys se nextUpdate verstryk. ’n OCSP-antwoord is enger: dit antwoord vir presies een sertifikaat en dra thisUpdate, producedAt en gewoonlik ook nextUpdate. Daardie verskil dryf alles anders. ’n Gekaste CRL word stil verouderd, want die lêer ontleed steeds en sy handtekening verifieer steeds, terwyl ’n vervalle OCSP-antwoord duidelik waardeloos is die oomblik wanneer jy sy tydstempels lees.

Kasberging is dus die eerste ding om vas te stel: watter komponent hou die kopie, en watter plafon daardie kopie gehoorsaam. Op ’n poort moet die plafon nextUpdate minus ’n veiligheidsmarge wees, nooit wat ’n HTTP-kasopskrif toevallig voorstel nie. openssl crl -in issuer.crl -noout -lastupdate -nextupdate druk albei datums, en ’n lys waarvan die nextUpdate reeds in die verlede is, moet as ontbrekend eerder as bloot oud behandel word.

Stap 2: Waarheen die sertifikaat die kliënt wys

Die bladsertifikaat dra gewoonlik twee leidrade: ’n CRL-verspreidingspunt-uitbreiding en ’n gesagsinligtingstoegang-inskrywing vir OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints druk die eerste, en die tweede sit onder die AIA-afdeling van openssl x509 -in client.pem -noout -text. Enige uitbreiding is ’n wyser, nie ’n verpligting nie. ’n Kliënt wat nooit herroepingskontrole implementeer nie, sal heeltemal goed verbind teen ’n sertifikaat wie se uitbreidings ’n responder noem wat al ’n jaar dood is.

Verspreidingspunte noem dikwels ’n interne gasheer wat net binne een netwerksegment opgelos word, en sommige ouer kliënte weier ldap-URL's heeltemal. Toets bereikbaarheid vanaf die gasheer wat die tonnel termineer, nie vanaf jou eie skootrekenaar nie, want dit is die enigste uitkykpunt wie se mislukking werklik saak maak.

Stap 3: Kies fail-closed of fail-open voor die onderbreking

’n Onbereikbare responder of ’n vervalle lys dwing ’n besluit af: weier die verbinding, of aanvaar dit en teken die gaping aan. OpenSSL se verify-subopdrag maak die streng keuse eksplisiet, want om -crl_check by te voeg verander ’n onbeskikbare CRL in unable to get certificate CRL en ’n mislukte verifikasie. Sagte mislukking in die meeste stapels is glad nie ’n vlag nie, dit is die afwesigheid van die kontrole, en dit is presies waarom dit per ongeluk verskeep word.

Om te sien watter gedrag ’n kliënt werklik het, neem die responder weg en verbind weer. As die tonnel steeds opkom, vind die logreël wat die oorgeslaande kontrole aangeteken het, en vra dan of iemand daardie reël tydens ’n voorval sou lees. Dieselfde verskaffer kan per protokol verskil, met ’n IKEv2-kliënt en ’n OpenVPN-kliënt op een masjien wat onverwante konfigurasieknoppe lees.

Stap 4: Bewys die kontrole loop waar verkeer toegelaat word

Vind die proses wat die verbinding termineer of magtig, en vra dit dan vir die konfigurasieline wat herroepingskontrole aktiveer. ’n Poort wat die ketting valideer maar nooit oor herroeping vra nie, handhaaf ’n ander beleid as die een in jou dokumentasie, en geen skermskoot van ’n sertifikaatketting bewys die teendeel nie. OpenVPN spel die opsie crl-verify; strongSwan hou CRL- en OCSP-opsoektogte onder die CA-konfigurasie, waar crl_uris of ocsp_uris gestel word. As jy nie na een van die twee kan wys nie, neem aan die kontrole is afwesig.

’n OCSP-antwoord geld net wanneer die uitreikende CA dit onderteken het, of wanneer ’n responder met die OCSPSigning-uitgebreide sleutelgebruik wat daardie CA delegeer, dit onderteken het, so ’n antwoord van ’n onverwante diens bewys niks. As jy die responder self bedryf, monitor dit as ’n harde afhanklikheid, want een dooie diens word op een slag ’n onderbreking vir elke fail-closed-kliënt.

Stap 5: Herroep een sertifikaat doelbewus

Neem ’n toets-sertifikaat, herroep dit deur dieselfde kanaal wat produksie gebruik, en vra die responder direk. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text behoort Cert Status: revoked saam met ’n herroepingstyd te rapporteer, en ’n good-antwoord beteken jou herroeping het nie die responder bereik wat jou kliënte bevraag nie. Voer dan openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem uit om dieselfde besluit deur die lyspad te sien. Lees die redesstring eerder as die uitgangskode, want ’n herroepingsverwerping en ’n kettingfout eindig albei in mislukking.

Die stap wat werklik saak maak, is die laaste een: weer verbind met die ou profiel teen die werklike handhawingspunt en bevestig die weiering kom van herroeping. Verbind dan weer met ’n vars, geldige sertifikaat om te bewys jy het nie bloot die luisteraar gebreek nie. Om die profiel op die kliënt te verwyder bewys niks oor die bediener se besluit nie, en ’n geslaagde openssl verify-lopie op ’n masjien wat nooit ’n tonnel termineer nie, ook nie. RFC 6960 omskryf wat ’n konforme OCSP-antwoord bevat, insluitend die statuswaardes wat hierdie toets lees.