Yntrekken fan sertifikaten mislearret: hokker host kin wat net berikke

Sertifikaten kinne binnen har jildichheidsperioade lizze wylst de VPN noch in autentikaasjeflater rapportearret, en immen konkludearret dat it sertifikaat yntrokken is. Dat binne trije ferskillende feiten. Yntrekgegevens moatte troch it apparaat dat de falidaasje docht ophelle wurde fan in publikaasjepunt dat yn it sertifikaat sels neamd is. As dat apparaat it punt net berikke kin, mislearret de kontrôle om redenen dy't neat mei de status fan it sertifikaat te meitsjen hawwe.

It falidearjen hat it ophaalpaad

Begjin mei it identifisearjen fan it falidearjen. As in laptop it sertifikaat fan de gateway kontrolearret, docht de laptop it ophalen; as de gateway in kliïntsertifikaat kontrolearret, docht de gateway it. In autentikaasjetsjinst op de eftergrûn kin in tredde falidearder tafoegje mei syn eigen netwurkposysje. Elk hat in oare rûte nei it internet en in oare proxy-konfiguraasje. Bewiis dat op it wurkstasjon fan in behearder sammele is, seit neat oer in tsjinner binnen in DMZ.

Skriuw it sertifikaat, it falidearjen, de tiid fan de poging en de krekte statuskoade op foardat jo eat feroarje.

Lês it publikaasjepunt út it sertifikaat

It sertifikaat neamt wêr't syn status wennet. Lês dy fjilden ynstee fan in CA-adres te rieden.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

De earste útwreiding listet CRL-distribúsjepunten op, en de twadde listet metoaden foar tagong ta autoriteitsynformaasje, dy't OCSP-status en it ophalen fan it sertifikaat fan de útjouwer dekke kinne. Dat binne ferskillende meganismen, en in OCSP-responder is gjin CRL-bestân. De publikaasjehost is faak in gewoane webserver en net de CA-masine, om't in offline útjouwer in CRL ûndertekenje kin dy't in oare tsjinner ferspriedt. Dêrom is in firewallregel dy't as tagong ta de CA beskreaun wurdt te ûndúdlik om te ymplementearjen of te beöardieljen.

Test it ophalen fan it apparaat dat falt

Fier de ophaaltest út yn de omjouwing dy't de falidaasje echt docht, mei goedkard sertifikaatmateriaal en sûnder privee kaaien.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

De certutil-run kontrolearret de keatling en rapportearret hokker URL-ophalings slagge of mislearren, wylst de curl-oprop ien publikaasje-adres fan deselde host testet en allinnich in statuskoade weromjout. In mislearre ophaling fan in berikber adres wiist op ynhâld- of ûndertekeningsproblemen; in ferbiningsflater wiist op routing, DNS of proxy. Hâld beide resultaten, om't ien slagge ophaling net bewiist dat de hiele keatling brûkber is. Feroarje de foarbyldhost en it paad nei it distribúsjepunt dat yn it sertifikaat fûn is.

Skied ûntbrekkende gegevens fan yntrokken status

Fjouwer útkomsten lykje fan bûten itselde: it punt is net berikber, de list is ferâldere, de list is troch de ferkearde útjouwer ûndertekene, of it sertifikaat is echt yntrokken. Allinnich de lêste is in statusresultaat, en allinnich dat rjochtfeardiget it fuortheljen fan tagong. Caching makket it byld noch yngewikkelder, om't earder ophelle gegevens in brutsen publikaasjepaad ferbergje kinne oant de folgjende ferfersking. It útskeakeljen fan de yntrekkontrôle, it fuortheljen fan net-relatearre sertifikaten of it opnij opstarten fan de gateway ferfange allegear de diagnostyk troch aktiviteit.

Nei de reparaasje twing in nije autentikaasje ôf en befêstigje dat it bedoelde status ophalen slagget. Wêr't in kontrolearre testidentiteit bestiet, befêstigje dat dy noch hieltyd wegere wurdt, om't beskikberens dy't de kontrôle fuorthellet gjin reparaasje is.