OCSP tsjin in CRL: hoe’t elke ynlûkingskontrôle eins wurket

Ien fan dizze twa ynlûkingskontrôles jout in ûndertekene antwurd oer ien inkeld sertifikaat, en de oare jout in ûndertekene list dy’t je hielendal downloade. Beide binne bedoeld om in ferifiearder te fertellen oft in bewiis noch fertroud is, en beide mislearje op manearen dy’t hielendal net op inoar lykje. De folchoarder hjirûnder folget wat in operator yn produksje eins tsjinkomt, fan de bytes op ’e tried oant in poarte dy’t in ferbining wegeret. In stap oerslaan is hoe’t in útrôl einiget mei in ynlûkingsbelied dat allinnich op papier bestiet.

Stap 1: Wat elke kontrôle weromjout en hoe lang’t it brûkber bliuwt

In CRL wurdt publisearre as ien ûndertekene objekt dat elk sertifikaat dekt dat in útjouwer ynlûke hat, sadat in ferifiearder it ien kear hellet en it wer brûkt oant de nextUpdate fan ’e list foarby is. In OCSP-antwurd is smeller: it antwurdet foar krekt ien sertifikaat en draacht thisUpdate, producedAt en meastentiids ek nextUpdate. Dat ferskil stjoert al it oare. In cachet CRL ferâldet stil, om’t it bestân noch parst en syn hantekening noch ferifiearre wurdt, wylst in ferrûn OCSP-antwurd fansels weardeleas is op it stuit dat je syn tiidstimpels lêze.

Caching is dêrom it earste dat fêstlein wurde moat: hokker komponint hâldt de kopy, en hokker plafond dy kopy folget. Op in poarte moat it plafond nextUpdate minus in feiligensmarzje wêze, nea wat in HTTP-cachekop tafallich foarstelt. openssl crl -in issuer.crl -noout -lastupdate -nextupdate prints beide datums, en in list dêr’t de nextUpdate al fan yn it ferline leit moat as ûntbrekkend behannele wurde en net as allinnich âld.

Stap 2: Wêr’t it sertifikaat de klant hinne wiist

It blêdsertifikaat draacht meastentiids twa oanwizings: in CRL-ferspriedingspuntútwreiding en in yngong foar tagong ta autoriteitsynformaasje foar OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints prints de earste, en de twadde sit ûnder de AIA-seksje fan openssl x509 -in client.pem -noout -text. Elke útwreiding is in wiizer, net in ferplichting. In klant dy’t nea ynlûkingskontrôle ymplemintearret sil hielendal goed ferbine tsjin in sertifikaat dêr’t de útwreidingen in reagearder neame dy’t al in jier dea is.

Ferspriedingspunten neame faak in ynterne host dy’t allinnich binnen ien netwurksegmint oplost, en guon âldere klanten wegerje ldap-URL’s hielendal. Test berikberens fan ’e host dy’t de tunnel beëiniget, net fan dyn eigen laptop, want dat is it iennige eachpunt dêr’t it mislearjen echt fan telt.

Stap 3: Kies fail-closed of fail-open foar de steuring

In ûnberikbere reagearder of in ferrûne list twingt in beslút ôf: wegerje de ferbining, of akseptearje it en registrearje it gat. De verify-subopdracht fan OpenSSL makket de strange kar eksplisyt, om’t it tafoegjen fan -crl_check in net-beskikbere CRL feroaret yn unable to get certificate CRL en in mislearre ferifikaasje. Sêft mislearjen is yn de measte steapels hielendal gjin flagge, it is it ûntbrekken fan ’e kontrôle, en dêrom komt it tafallich mei.

Om te sjen hokker gedrach in klant eins hat, helje de reagearder fuort en ferbynje op ’e nij. As de tunnel noch omheech komt, fyn dan de logrigel dy’t de oersleine kontrôle fêstlein hat, en freegje dan oft immen dy rigel yn in ynsidint lêze soe. Deselde leveransier kin per protokol ferskille, mei in IKEv2-klant en in OpenVPN-klant op ien masine dy’t ûnferbâne konfiguraasjeknoppen lêze.

Stap 4: Bewiis dat de kontrôle rint dêr’t ferkear talitten wurdt

Fyn it proses dat de ferbining beëiniget of autorisearret, en freegje it dan om de konfiguraasjerigel dy’t ynlûkingskontrôle ynskeakelt. In poarte dy’t de keatling falidearret mar nea nei ynlûking freget, hanthavet in oar belied as dat yn dyn dokumintaasje, en gjin skermprint fan in sertifikaatkeatling bewiist it tsjinoerstelde. OpenVPN skriuwt de opsje as crl-verify; strongSwan hâldt CRL- en OCSP-sykaksjes ûnder de CA-konfiguraasje, dêr’t crl_uris of ocsp_uris ynsteld wurde. As je net nei ien fan beide wize kinne, nim dan oan dat de kontrôle ûntbrekt.

In OCSP-antwurd jildt allinnich as de útjaande CA it ûndertekene hat, of as in reagearder mei it troch dy CA delegearre útwreide kaai gebrûk OCSPSigning it ûndertekene hat, dus in antwurd fan in net besibbe tsjinst bewiist neat. As je de reagearder sels driuwe, monitorje it as in hurde ôfhinklikens, om’t ien deade tsjinst tagelyk in steuring wurdt foar elke fail-closed-klant.

Stap 5: Lûk mei opsetsin ien sertifikaat yn

Nim in testsertifikaat, lûk it yn fia deselde kaniel dy’t produksje brûkt, en freegje de reagearder direkt. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text soe Cert Status: revoked rapportearje moatte tegearre mei in ynlûkingstiid, en in good-antwurd betsjut dat dyn ynlûking de reagearder dy’t dyn klanten freegje net berikt hat. Rinn dan openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem om deselde beslissing fia it listpaad te sjen. Lês de redenstring ynstee fan ’e útgongskoade, want in ynlûkingswegering en in keatlingflater einigje beide yn mislearjen.

De stap dy’t echt telt is de lêste: ferbynje op ’e nij mei it âlde profyl tsjin it echte hanthavingspunt en befêstigje dat de wegering fan ’e ynlûking komt. Ferbynje dan op ’e nij mei in farsk, jildich sertifikaat om te bewizen dat je net allinnich de listener brutsen hawwe. It profyl op ’e klant wiskje bewiist neat oer de beslissing fan ’e tsjinner, en dat docht in slagge openssl verify-rin op in masine dy’t nea in tunnel beëiniget ek net. RFC 6960 definiearret wat in konform OCSP-antwurd befettet, ynklusyf de statuswearden dy’t dizze test lêst.