Lapo sertifikatas galioja, grandinė pasibaigė: skaitykite gylį
Galiojimo pabaigos klaida gali priklausyti išdavėjui, o ne lapui. Perskaitykite patikrinimo gylį ir pasitikėjimo įvestis prieš atnaujindami sertifikatą, kuris dar atrodo galiojantis.
Tikrinate serverio sertifikatą, matote, kad laikrodyje dar liko mėnesių, o klientas vis tiek atmeta ryšį su galiojimo pabaigos pranešimu. Data, kurią skaitote, priklauso lapui, o skundas gali būti apie kažką giliau kelyje. Patikra eina grandine, ir bet kuris sertifikatas, kurį pasirenka ši eiga, gali nepraeiti savo galiojimo lange. Perskaitykite, kuris nepraėjo, prieš ką nors atnaujindami.
Gylis įvardija sertifikatą, kuris nepraėjo
OpenSSL diagnostikoje gylis 0 yra tikslinis sertifikatas, o gylis 1 — jį pasirašęs išdavėjas, didesni skaičiai tęsiasi link pasitikėjimo inkaro. 1 gylyje pranešta galiojimo pabaiga neprieštarauja galiojančiam notAfter lape, todėl pakartotinis matomo sertifikato tikrinimas niekada nepaaiškins klaidos.
Užrašykite nepraėjusio sertifikato pirštų atspaudą kartu su jo subject, nes skirtingi sertifikatai gali turėti tą patį CA pavadinimą. Kryžminis pasirašymas sukuria būtent tokią situaciją: ta pati institucija pasirodo daugiau nei kartą su skirtingomis galiojimo datomis, o tikrintojas pasirinko tą, kurio nesitikėjote. Pažįstama etiketė nėra identifikatorius, o pirštų atspaudas yra tai, kas išskiria du objektus, turinčius tą patį pavadinimą.
Atkreipkite dėmesį ir į produktus, turinčius daugiau nei vieną sertifikato vaidmenį. OpenVPN Access Server atveju sertifikatai, saugantys žiniatinklio sąsajas, yra atskirti nuo naudojamų VPN ryšiams, todėl naršyklė, atidaranti administravimo puslapį, nieko neįrodo apie tunelio kelią.
Pasitikėjimo įvestys nėra tas pats, kas grandinės kandidatai
Duokite tikrintojui abi įvestis atskirai ir aiškiai. Pasitikėjimo failas laiko inkara, kuriuos priimate; nepatikimas rinkinys laiko tarpinius sertifikatus, siūlomus kelio statybai. Jų sumaišymas yra tai, kaip žmonės netyčia pakelia tarpinį sertifikatą į šaknį ir paskui stebisi, kodėl ta pati klaida juos persekioja tarp mašinų.
$ openssl verify -verbose -show_chain -purpose sslserver \
-CAfile trusted-roots.pem -no-CApath -no-CAstore \
-untrusted intermediates.pem server.pem
Numatytojo kelio ir saugyklos išjungimas su -no-CApath -no-CAstore išlaiko testą sąžiningą: rezultatas tada priklauso nuo jūsų nurodytų failų, o ne nuo to, kuo darbo stotis atsitiktinai pasitiki. OpenSSL patikros žinynas dokumentuoja šias parinktis ir jų generuojamą diagnostiką.
-show_chain išspausdina pastatytą grandinę, kai patikra pavyksta, o tai naudinga patvirtinti, kad kelias yra tas, kurį ketinote. Kai ji nepavyksta, palikite praneštą gylį ir subject; šie du laukai pasako kitam skaitytojui, kurį sertifikatą tikrinti.
Ko tai nedaro — neatkuria kiekvieno kliento politikos. Pin, paskirties apribojimas ar klientui būdingas tapatybės patikrinimas gyvena kliente, o ne šioje komandoje. Tai yra nustatymai, kuriuos reikia tikrinti, kai patikra serveryje pavyksta, o ryšys vis tiek nepavyksta. Laikykite abi diagnozes atskirai, kitaip atnaujinsite sveiką sertifikatą, vijedamiesi pinning klaidą.
Ką patikra įrodo ir ko neapima
Tai kelio ir paskirties patikra pagal jūsų pateiktą pasitikėjimo failą. HTTPS vardo patikrai pridėkite laukiamą pagrindinio kompiuterio vardą per atitinkamą parinktį; VPN ryšiui palikite sukonfigūruotus kliento tapatybės patikrinimus ir naudokite tą pasitikėjimo medžiagą, kurią tas klientas iš tikrųjų skaito.
Tai, ką siunčia serveris, yra kandidatų rinkinys, o ne kelias, kurį galiausiai pastatys jūsų klientas. Vietinis pasitikėjimas ir bibliotekos statybos taisyklės abu formuoja rezultatą, todėl tas pats atsakymas gali būti patikrintas vienoje mašinoje ir nepavykti kitoje. Palyginkite nepavykusio kliento prižiūrimą pasitikėjimo saugyklą ir TLS įgyvendinimą su veikiančio kliento, prieš darydami prielaidą apie identišką vertinimą. Skirtumas ten paaiškina daugybę pranešimų „nepavyksta tik šiame nešiojamajame“.
Norėdami matyti kiekvieno sertifikato langą, o ne po vieną, išspausdinkite juos kaip rinkinį:
$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
| openssl pkcs7 -print_certs -noout
Ta antroji komanda išvardija subject ir išdavėjus nedešifruodama kiekvieno failo ranka, taip pastebite tarpinį sertifikatą, kurio data jau praėjo, kol lapas dar atrodo tvarkingai.
Sutaisykite kelią nesusilpnindami patikros
Kai pateikiamas pasibaigęs tarpinis ar pasenęs kryžmai pasirašytas sertifikatas, gaukite dabartinę palaikomą išdavėjo grandinę ir įdiekite ją per dokumentuotą paslaugos sertifikatų darbo eigą. Kai klientui trūksta numatyto prižiūrimo inkaro, atnaujinkite jo valdomą pasitikėjimo konfigūraciją arba kliento programinę įrangą. Atsispirkite pagundai pažymėti kiekvieną rinkinio sertifikatą šaknimi tik tam, kad nutildytumėte pranešimą.
Šaknies tvarkymas vertas pastabos, nes santraukos dažnai jį perdėja. RFC 5280 traktuoja inkarą kaip įvestį, esančią už numatomo kelio, o OpenSSL dokumentuoja galiojimo patikras, įtraukiančias jo šakninį CA sertifikatą. Abu teiginiai teisingi jų pačių sistemoms; vienos bibliotekos šaknies galiojimo pabaigos elgsenos apibendrinimas visiems klientams duoda užtikrintus neteisingus atsakymus.
Po pakeitimo priverskite paveiktą klientą atlikti naują autentifikaciją ir patvirtinkite, kad konkretaus galiojimo pabaigos pranešimo nebėra. Atnaujinkite lapą tik jei pats lapas netinkamas. Laiko patikrų išjungimas ar istorinio kryžminio sertifikato atkūrimas nesukuria galiojančio dabartinio kelio; tai tik atideda kitą nesėkmę.