Lisni certifikat valjan, lanac istekao: pročitajte dubinu

Greška isteka može pripadati izdavaču, a ne listu. Pročitajte dubinu provjere i unose povjerenja prije nego obnovite certifikat koji još izgleda aktualno.

Provjeravate certifikat servera, vidite još mjeseci na satu, a klijent ipak odbija vezu s porukom o isteku. Datum koji čitate pripada listu, a prigovor se može odnositi na nešto dublje u putu. Provjera prolazi lanac, i svaki certifikat koji taj prolaz odabere može pasti u vlastitom prozoru valjanosti. Pročitajte koji je pao prije nego što bilo šta obnovite.

Dubina imenuje certifikat koji je pao

U OpenSSL dijagnostici dubina 0 je ciljni certifikat, a dubina 1 je izdavač koji ga je potpisao, s većim brojevima koji vode dalje prema sidru povjerenja. Istek prijavljen na dubini 1 ne opovrgava trenutni notAfter na listu, pa ponovna provjera vidljivog certifikata nikada neće objasniti grešku.

Zabilježite otisak neuspjelog certifikata zajedno s njegovim subjektom, jer različiti certifikati mogu nositi isto ime CA. Unakrsno potpisivanje stvara upravo tu situaciju: isti organ se pojavljuje više puta, s različitim datumima valjanosti, a provjerivač je odabrao onaj koji niste očekivali. Poznata oznaka nije identifikator, a otisak je ono što razlikuje dva objekta koja dijele ime.

Obratite pažnju i na proizvode s više od jedne uloge certifikata. Na OpenVPN Access Serveru certifikati koji štite web sučelja odvojeni su od onih koji se koriste za VPN veze, pa preglednik koji otvori administratorsku stranicu ništa ne dokazuje o putu tunela.

Unosi povjerenja nisu isto što i kandidati za lanac

Dajte provjerivaču dva unosa odvojeno i izričito. Datoteka povjerenja drži sidra koja prihvatate; nepouzdani paket drži posredničke certifikate ponuđene za izgradnju puta. Miješati ih znači da ljudi slučajno promoviraju posrednički certifikat u korijen i onda se pitaju zašto ih ista greška slijedi između računara.

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

Isključivanje zadanog puta i spremišta s -no-CApath -no-CAstore čini test poštenim: rezultat tada ovisi o datotekama koje ste naveli, a ne o tome čemu radna stanica slučajno vjeruje. OpenSSL referenca za provjeru dokumentira te opcije i dijagnostiku koju proizvode.

-show_chain ispisuje izgrađeni lanac kada provjera uspije, što je korisno za potvrdu da je put onaj koji ste namjeravali. Kada ne uspije, zadržite prijavljenu dubinu i subjekt; ta dva polja govore sljedećem čitaocu koji certifikat provjeriti.

Ono što ovo ne radi je reproduciranje politike svakog klijenta. Pin, ograničenje namjene ili provjera identiteta specifična za klijenta živi u klijentu, ne u ovoj naredbi. To su postavke koje treba provjeriti kada provjera na serveru prođe, a veza i dalje ne uspije. Držite dvije dijagnoze odvojeno, inače ćete obnoviti zdrav certifikat jureći grešku pinninga.

Šta provjera dokazuje i šta izostavlja

Ovo je provjera puta i namjene prema datoteci povjerenja koju ste dostavili. Za provjeru imena po HTTPS dodajte očekivano ime hosta kroz odgovarajuću opciju; za VPN vezu zadržite konfigurirane provjere identiteta klijenta i koristite materijal povjerenja koji taj klijent zaista čita.

Ono što server šalje je skup kandidata, a ne put koji će vaš klijent na kraju izgraditi. Lokalno povjerenje i pravila izgradnje biblioteke oblikuju rezultat, zato isti odgovor može proći provjeru na jednom računaru i pasti na drugom. Usporedite održavano spremište povjerenja i TLS implementaciju neuspjelog klijenta s onima radnog klijenta prije nego pretpostavite identičnu evaluaciju. Razlika tamo objašnjava mnoge izvještaje „samo ovaj laptop pada“.

Da vidite prozor svakog certifikata umjesto jedan po jedan, ispišite ih kao skup:

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

Ta druga naredba navodi subjekte i izdavače bez ručnog dekodiranja svake datoteke, tako uočavate posrednički certifikat čiji je datum prošao dok list još izgleda dobro.

Popravite put bez slabljenja provjere

Kada se dostavlja istekao posrednički ili zastarjeli unakrsno potpisan certifikat, nabavite trenutno podržani lanac izdavača i postavite ga kroz dokumentirani tijek certifikata usluge. Kada klijentu nedostaje namjeravano održavano sidro, ažurirajte njegovu upravljanu konfiguraciju povjerenja ili klijentski softver. Oduprite se prečici da svaki certifikat u paketu označite kao korijen samo da ušutkate poruku.

Rukovanje korijenom zaslužuje napomenu, jer sažeci ga često preuveličavaju. RFC 5280 tretira sidro kao unos koji stoji izvan predviđenog puta, dok OpenSSL dokumentira provjere valjanosti koje uključuju njegov korijenski CA certifikat. Obje tvrdnje vrijede za njihove vlastite sisteme; generaliziranje ponašanja isteka korijena jedne biblioteke na svaki klijent daje samouvjerene pogrešne odgovore.

Nakon promjene prisilite svježu autentifikaciju na pogođenom klijentu i potvrdite da je specifična poruka o isteku nestala. Obnovite list samo ako je sam list neprikladan. Isključivanje provjera vremena ili vraćanje historijskog unakrsnog certifikata ne stvara valjan trenutni put; samo odgađa sljedeći neuspjeh.

Povezani članci