Lehtsertifikaat kehtiv, ahel aegunud: lugege sügavust

Kontrollite serveri sertifikaati, näete kellal veel kuid ja klient keeldub siiski ühendusest aegumisteatega. Kuupäev, mida loete, kuulub lehele, ja kaebus võib puudutada midagi sügavamat rajal. Kontroll läbib ahela ja iga sertifikaat, mille see käik valib, võib oma kehtivusaknas läbi kukkuda. Lugege, milline läbi kukkus, enne kui midagi uuendate.

Sügavus nimetab sertifikaadi, mis läbi kukkus

OpenSSL-i diagnostikas on sügavus 0 sihtsertifikaat ja sügavus 1 seda allkirjastanud väljaandja, kusjuures suuremad numbrid jätkuvad usaldusankru suunas. Sügavusel 1 teatatud aegumist ei kummuta lehel olev kehtiv notAfter, seega nähtava sertifikaadi uuesti kontrollimine ei selgita seda viga kunagi.

Kirjutage üles nurjunud sertifikaadi sõrmejälg koos selle subjektiga, sest erinevad sertifikaadid võivad kanda sama CA-nime. Ristallkirjastamine loob täpselt selle olukorra: sama asutus esineb rohkem kui korra, erinevate kehtivuskuupäevadega, ja kontrollija valis selle, mida te ei oodanud. Tuttav silt ei ole identifikaator ja sõrmejälg on see, mis eristab kahte sama nime jagavat objekti.

Pöörake tähelepanu ka toodetele, millel on rohkem kui üks sertifikaadiroll. OpenVPN Access Serveris on veebiliideseid kaitsvad sertifikaadid VPN-ühenduste omadest eraldi, seega administraatorilehte avav brauser ei tõesta tunneliraja kohta midagi.

Usaldussisendid ei ole sama mis ahelakandidaadid

Andke kontrollijale kaks sisendit eraldi ja selgesõnaliselt. Usaldusfail hoiab ankruid, mida te aktsepteerite; mitteusaldusväärne kogum hoiab raja ehitamiseks pakutavaid vahesertifikaate. Nende segamine on viis, kuidas inimesed kogemata tõstavad vahesertifikaadi juureks ja imestavad siis, miks sama viga neid masinate vahel jälitab.

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

Vaikeraja ja -hoidla keelamine valikuga -no-CApath -no-CAstore hoiab testi ausana: tulemus sõltub siis teie nimetatud failidest, mitte sellest, mida tööjaam juhuslikult usaldab. OpenSSL-i kontrolliviide dokumenteerib need valikud ja nende tekitatava diagnostika.

-show_chain prindib ehitatud ahela, kui kontroll õnnestub, mis on kasulik kinnitamaks, et rada on kavandatu. Kui see ebaõnnestub, hoidke teatatud sügavus ja subjekt; need kaks välja ütlevad järgmisele lugejale, millist sertifikaati uurida.

Mida see ei tee, on iga kliendi poliitika taasesitamine. Pin, otstarbe piirang või kliendipõhine identiteedikontroll elab kliendis, mitte selles käsus. Need on seaded, mida uurida, kui kontroll serveris õnnestub ja ühendus ikka ebaõnnestub. Hoidke kaks diagnoosi lahus, muidu uuendate tervet sertifikaati, ajades taga pinning-viga.

Mida kontroll tõestab ja mida välja jätab

See on raja ja otstarbe kontroll teie esitatud usaldusfaili vastu. HTTPS-i nimekontrolli jaoks lisage oodatav hostinimi sobiva valikuga; VPN-ühenduse jaoks hoidke kliendi konfigureeritud identiteedikontrollid ja kasutage usaldusmaterjali, mida see klient tegelikult loeb.

See, mida server saadab, on kandidaatide kogum, mitte rada, mille teie klient lõpuks ehitab. Kohalik usaldus ja teegi ehituseeskirjad mõjutavad mõlemad tulemust, mistõttu võib sama vastus ühes masinas kontrolli läbida ja teises mitte. Võrrelge nurjunud kliendi hallatavat usaldushoidlat ja TLS-i teostust töötava kliendi omadega, enne kui eeldate identset hindamist. Erinevus seal selgitab paljusid raporteid „ainult see sülearvuti ebaõnnestub“.

Iga sertifikaadi akna nägemiseks ühekaupa printimise asemel printige need kogumina:

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

Teine käsk loetleb subjektid ja väljaandjad iga faili käsitsi dekodeerimata, nii märkate vahesertifikaati, mille kuupäev on möödunud, samal ajal kui leht näib veel korras.

Parandage rada kontrolli nõrgendamata

Kui esitatakse aegunud vahesertifikaat või vananenud ristallkirjastatud sertifikaat, hankige väljaandja praegu toetatud ahel ja juurutage see teenuse dokumenteeritud sertifikaaditöövoo kaudu. Kui kliendil puudub kavandatud hallatav ankur, uuendage selle hallatavat usaldusseadistust või klienditarkvara. Vastustage kiusatusele märkida iga kogumis olev sertifikaat juureks, et teadet lihtsalt vaigistada.

Juure käsitlemine väärib märkust, sest kokkuvõtted liialdavad sellega sageli. RFC 5280 käsitleb ankrut sisendina, mis asub väljaspool kavandatavat rada, samas kui OpenSSL dokumenteerib kehtivuskontrolle, mis hõlmavad selle juur-CA sertifikaati. Mõlemad väited kehtivad nende endi süsteemide kohta; ühe teegi juure aegumiskäitumise üldistamine igale kliendile annab enesekindlalt vale vastuseid.

Pärast muudatust sundige mõjutatud kliendil värske autentimine ja kinnitage, et konkreetne aegumisteade on kadunud. Uuendage lehte ainult siis, kui leht ise on sobimatu. Ajakontrollide keelamine või ajaloolise ristsertifikaadi taastamine ei anna kehtivat praegust rada; see ainult lükkab järgmise tõrke edasi.