Lapas sertifikāts derīgs, ķēde beigusies: lasiet dziļumu

Jūs pārbaudāt servera sertifikātu, redzat, ka pulkstenī vēl ir mēneši, un klients tomēr atsaka savienojumu ar termiņa beigu ziņojumu. Datums, ko jūs lasāt, pieder lapai, un sūdzība var būt par kaut ko dziļāku ceļā. Pārbaude iet pa ķēdi, un jebkurš sertifikāts, ko šī gaita izvēlas, var neizturēt savā derīguma logā. Izlasiet, kurš neizturēja, pirms kaut ko atjaunojat.

Dziļums nosauc sertifikātu, kas neizturēja

OpenSSL diagnostikā dziļums 0 ir mērķa sertifikāts, bet dziļums 1 ir izdevējs, kas to parakstīja, un lielāki skaitļi turpinās uz uzticības enkuru. Dziļumā 1 ziņotais termiņa beigas nav pretrunā ar spēkā esošu notAfter lapā, tāpēc redzamā sertifikāta atkārtota pārbaude nekad neizskaidros kļūdu.

Pierakstiet neizturējušā sertifikāta pirksta nospiedumu kopā ar tā subject, jo dažādi sertifikāti var nest vienu un to pašu CA nosaukumu. Krusteniskā parakstīšana rada tieši šo situāciju: viena un tā pati iestāde parādās vairāk nekā vienreiz, ar dažādiem derīguma datumiem, un pārbaudītājs izvēlējās to, ko jūs negaidījāt. Pazīstams marķējums nav identifikators, un pirksta nospiedums ir tas, kas atšķir divus objektus ar vienu nosaukumu.

Pievērsiet uzmanību arī produktiem ar vairāk nekā vienu sertifikāta lomu. OpenVPN Access Server gadījumā sertifikāti, kas aizsargā tīmekļa saskarnes, ir atsevišķi no tiem, kas tiek izmantoti VPN savienojumiem, tāpēc pārlūks, kas atver administrācijas lapu, neko nepierāda par tuneļa ceļu.

Uzticības ievades nav tas pats, kas ķēdes kandidāti

Dodiet pārbaudītājam abas ievades atsevišķi un skaidri. Uzticības fails satur enkurus, ko pieņemat; neuzticamā pakete satur starpposma sertifikātus, kas tiek piedāvāti ceļa būvēšanai. To sajaukšana ir veids, kā cilvēki nejauši paaugstina starpposma sertifikātu par sakni un tad brīnās, kāpēc tā pati kļūda viņiem seko starp mašīnām.

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

Noklusējuma ceļa un krātuves atslēgšana ar -no-CApath -no-CAstore uztur testu godīgu: rezultāts tad atkarīgs no jūsu nosauktajām datnēm, nevis no tā, kam darbstacija nejauši uzticas. OpenSSL pārbaudes uzziņa dokumentē šīs opcijas un to radīto diagnostiku.

-show_chain izdrukā uzbūvēto ķēdi, kad pārbaude izdodas, kas ir noderīgi, lai apstiprinātu, ka ceļš ir tas, ko jūs domājāt. Kad tā neizdodas, saglabājiet ziņoto dziļumu un subject; šie divi lauki pasaka nākamajam lasītājam, kuru sertifikātu pārbaudīt.

Ko tas nedara — neatkārto katra klienta politiku. Pin, mērķa ierobežojums vai klientam raksturīga identitātes pārbaude dzīvo klientā, nevis šajā komandā. Tie ir iestatījumi, kas jāpārbauda, kad pārbaude serverī izdodas un savienojums joprojām neizdodas. Turiet abas diagnozes atsevišķi, citādi atjaunosiet veselu sertifikātu, dzenoties pēc pinning kļūdas.

Ko pārbaude pierāda un ko tā izlaiž

Šī ir ceļa un mērķa pārbaude pret jūsu sniegto uzticības failu. HTTPS nosaukuma pārbaudei pievienojiet gaidīto resursdatora nosaukumu ar atbilstošo opciju; VPN savienojumam saglabājiet klienta konfigurētās identitātes pārbaudes un izmantojiet to uzticības materiālu, ko šis klients patiešām lasa.

Tas, ko serveris sūta, ir kandidātu kopa, nevis ceļš, ko jūsu klients beigās uzbūvēs. Vietējā uzticība un bibliotēkas būvēšanas noteikumi abi veido rezultātu, tāpēc viena un tā pati atbilde var pārbaudīties vienā mašīnā un neizdoties citā. Salīdziniet neizdevušā klienta uzturēto uzticības krātuvi un TLS ieviešanu ar strādājoša klienta, pirms pieņemat identisku novērtējumu. Atšķirība tur izskaidro daudzus ziņojumus „tikai šajā portatīvajā neizdodas“.

Lai redzētu katra sertifikāta logu, nevis pa vienam, izdrukājiet tos kā kopu:

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

Otrā komanda uzskaita subject un izdevējus, nekatru datni dekodējot ar roku, tā jūs pamanāt starpposma sertifikātu, kura datums jau pagājis, kamēr lapa vēl izskatās labi.

Salabojiet ceļu, nevājinot pārbaudi

Kad tiek piegādāts beidzies starpposma vai novecojis krusteniski parakstīts sertifikāts, iegūstiet izdevēja pašlaik atbalstīto ķēdi un izvietojiet to pakalpojuma dokumentētajā sertifikātu darbplūsmā. Kad klientam trūkst paredzētā uzturētā enkura, atjauniniet tā pārvaldīto uzticības konfigurāciju vai klienta programmatūru. Pretojieties saīsnei atzīmēt katru paketes sertifikātu par sakni, tikai lai apklusinātu ziņojumu.

Saknes apstrāde ir pelnījusi piezīmi, jo kopsavilkumi to bieži pārspīlē. RFC 5280 uzskata enkuru par ievadi, kas atrodas ārpus paredzamā ceļa, savukārt OpenSSL dokumentē derīguma pārbaudes, kas ietver tā saknes CA sertifikātu. Abi apgalvojumi ir patiesi viņu pašu sistēmām; vienas bibliotēkas saknes termiņa uzvedības vispārināšana uz visiem klientiem dod pārliecinoši nepareizas atbildes.

Pēc izmaiņām piespiediet skarto klientu veikt jaunu autentifikāciju un apstipriniet, ka konkrētais termiņa beigu ziņojums ir pazudis. Atjaunojiet lapu tikai tad, ja pati lapa ir nepiemērota. Laika pārbaužu atslēgšana vai vēsturiska krusteniskā sertifikāta atjaunošana nerada derīgu pašreizējo ceļu; tā tikai atliek nākamo kļūmi.