Dir préift de Server-Zertifikat, gesitt nach Méint um Auer, an de Client refuséiert d'Verbindung ëmmer nach mat enger Oflafmeldung. Den Datum, deen Dir liest, gehéiert zum Blat, an d'Beschwerde kann iwwer eppes Méi déift am Wee goen. D'Préifung geet eng Kette entlaang, an jedes Zertifikat, dat dëse Laf auswielt, kann a sengem eegene Gëltegkeetsfenster feelen. Liest, wat gefeelt huet, ier Dir eppes erneieret.

D'Tiefe nennt d'Zertifikat, dat gefeelt huet

An der OpenSSL-Diagnostik ass d'Tiefe 0 den Zilzertifikat an d'Tiefe 1 den Aussteller, deen en ënnerschriwwen huet, mat méi héijen Zuelen déi weider zum Vertrauensanker féieren. En Oflaf, deen op der Tiefe 1 gemellt gëtt, gëtt net duerch en aktuellen notAfter um Blat widderluecht, dofir wäert d'visibel Zertifikat nach eng Kéier ze préifen de Feeler ni erklären.

Notéiert de Fangerofdrock vum gefeelte Zertifikat zesumme mat sengem Subject, well verschidde Zertifikate kënnen deeselwechte CA-Numm droen. Kräizschreiwen erstellt genau déi Situatioun: deeselwecht Autoritéit erschéngt méi wéi eemol, mat ënnerschiddlechen Gëltegkeetsdatumer, an de Préifer huet deen ausgewielt, deen Dir net erwaart hutt. Eng vertraut Etikett ass keen Identifiant, an e Fangerofdrock ass dat, wat zwee Objeten mat deem selwechten Numm ënnerscheet.

Passt och op Produkter mat méi wéi enger Zertifikatsroll op. Op OpenVPN Access Server sinn d'Zertifikater, déi d'Webinterface schützen, getrennt vun deene fir VPN-Verbindungen, also beweise Browser, déi d'Admin-Säit opmaacht, näischt iwwer de Wee vum Tunnel.

Vertrauensinputte si net datselwecht wéi Kettekandidaten

Gitt dem Préifer déi zwee Inputte getrennt an explizit. D'Vertrauensdatei hält d'Ankeren, déi Dir akzeptéiert; de net-vertraute Bündel hält Zwëschenzertifikater, déi fir de Bau vum Wee ugebuede ginn. Si ze mëschen ass wéi d'Leit accidentell en Zwëschenzertifikat zum Root firéieren an dann froen, firwat dee selwechte Feeler si tëschent Maschinnen suivéiert.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

D'Deaktivéiere vum Standardwee an -späicher mat -no-CApath -no-CAstore hält den Test éierlech: d'Resultat hänkt dann vun den Dateien of, déi Dir genannt hutt, net dovun, wat d'Aarbechtsstatioun zoufällech vertraut. D'OpenSSL-Préifreferenz dokumentéiert dës Optiounen an d'Diagnostik, déi se produzéieren.

-show_chain dréckt déi gebaut Kette, wann d'Préifung geléngt, wat nëtzlech ass fir ze bestätegen, datt de Wee dee ass, deen Dir virgesinn hutt. Wann et feelt, behält d'gemellt Tiefe a Subject; déi zwee Felder soen dem nächste Lieser, wéi ee Zertifikat ze ënnersichen.

Wat dëst net mécht, ass d'Politik vun all Client ze reproduzéieren. E Pin, eng Zweckbeschränkung oder eng clientspezifesch Identitéitspréifung lieft am Client, net an dësem Kommando. Dat sinn d'Astellungen, déi ze préife sinn, wann d'Préifung um Server geléngt an d'Verbindung nach ëmmer feelt. Hält déi zwou Diagnosen getrennt, soss erneiert Dir en gesond Zertifikat an der Verfollegung vun engem Pinning-Fehler.

Wat d'Préifung beweist a wat se weiderlässt

Dëst ass eng Wee- an Zweckpréifung géint eng Vertrauensdatei, déi Dir geliwwert hutt. Fir eng HTTPS-Nummepréifung füügt den erwaarten Hostnumm iwwer déi passend Optioun derbäi; fir eng VPN-Verbindung behält d'konfiguréiert Identitéitspréifunge vum Client a benotzt d'Vertrauensmaterial, dat dee Client wierklech liest.

Wat e Server schéckt, ass e Set vu Kandidaten, net de Wee, deen Äre Client am Endeffekt baut. Lokal Vertrauen an d'Konstruktiounsregelen vun der Bibliothek formen allebéid d'Resultat, dofir kann déiselwecht Äntwert op enger Maschinn préifen an op enger anerer feelen. Vergläicht de gepflegte Vertrauensspäicher an d'TLS-Implementatioun vum Client, dee feelt, mat deene vun engem funktionéierende Client, ier Dir eng identesch Bewäertung unhëlt. En Ënnerscheed do erkläert vill Berichter „nëmmen dëse Laptop feelt“.

Fir d'Fënster vun all Zertifikat anstatt eng no der anerer ze gesinn, dréckt se als Set:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Déi zweet Kommando lëscht Subjecten an Aussteller, ouni all Datei vun Hand ze dekodéieren, sou erkennt Dir en Zwëschenzertifikat, deem säin Datum vergaangen ass, wärend d'Blat nach gutt ausgesäit.

Reparéiert de Wee, ouni d'Préifung ze schwächen

Wann en ofgelafenen Zwëschenzertifikat oder en veraltete Kräiz-Zertifikat geliwwert gëtt, kritt déi aktuell ënnerstëtzt Kette vum Aussteller a setzt se iwwer de dokumentéierte Zertifikatsworkflow vum Service ëm. Wann dem Client de virgesinnene gepflegten Anker feelt, aktualiséiert seng verwalt Vertrauenskonfiguratioun oder d'Client-Software. Widderstitt der Ofkierzung, all Zertifikat am Bündel als Root ze markéieren, just fir d'Meldung ze berouegen.

D'Behandlung vum Root verdéngt eng Notiz, well Zesummefaassunge se dacks iwwerdreiwen. RFC 5280 behandelt den Anker als en Input ausserhalb vum prospective Wee, während OpenSSL Gëltegkeetspréifunge dokumentéiert, déi säin Root-CA-Zertifikat enthalen. Béid Aussoen si wouer fir hir eege Systemer; eng Bibliothéik hire Root-Oflafverhalen op all Client ze generaliséieren produzéiert selbstsécher falsch Äntwerten.

No der Ännerung forcéiert eng nei Authentifikatioun um betraffene Client a bestätegt, datt déi spezifesch Oflafmeldung fort ass. Erneiert d'Blat nëmmen, wann d'Blat selwer ongëeegent ass. Zäitpréifungen auszeschalten oder en historescht Kräiz-Zertifikat ze restauréieren produzéiert kee gëltege aktuellen Wee; et verréckelt just de nächste Feeler.

Ähnlech Artikelen