Certifikata e gjethes e vlefshme, zinxhiri skaduar: lexo thellësinë

Një gabim skadimi mund t'i përkasë një lëshuesi, jo gjethes. Lexo thellësinë e verifikimit dhe hyrjet e besimit përpara se të rinovosh një certifikatë që ende duket aktuale.

Ju kontrolloni certifikatën e serverit, shihni muaj të mbetur në orë, dhe klienti ende refuzon lidhjen me një mesazh skadimi. Data që lexoni i përket gjethes, dhe ankesa mund të jetë për diçka më të thellë në rrugë. Verifikimi kalon nëpër një zinxhir, dhe çdo certifikatë që zgjedh ky ecje mund të dështojë në dritaren e vetë vlefshmërisë. Lexoni cila dështoi përpara se të rinovoni ndonjë gjë.

Thellësia emërton certifikatën që dështoi

Në diagnostikimin e OpenSSL, thellësia 0 është certifikata e synuar dhe thellësia 1 është lëshuesi që e nënshkroi, me numra më të mëdhenj që vazhdojnë drejt spirancës së besimit. Një skadim i raportuar në thellësinë 1 nuk kundërshtohet nga një notAfter aktual në gjethe, kështu që kontrolli i përsëritur i certifikatës së dukshme nuk do ta shpjegojë kurrë gabimin.

Shënoni gjurmën e gishtit të certifikatës që dështoi së bashku me subject-in e saj, sepse certifikata të ndryshme mund të mbajnë të njëjtin emër CA. Nënshkrimi kryq krijon pikërisht atë situatë: e njëjta autoritet shfaqet më shumë se një herë, me data të ndryshme vlefshmërie, dhe verifikuesi zgjodhi atë që nuk e prisnit. Një etiketë e njohur nuk është identifikues, dhe gjurma e gishtit është ajo që dallon dy objekte që ndajnë një emër.

Vini re edhe produktet me më shumë se një rol certifikate. Në OpenVPN Access Server, certifikatat që mbrojnë ndërfaqet web janë të ndara nga ato që përdoren për lidhjet VPN, kështu që një shfletues që hap faqen e administratorit nuk provon asgjë për rrugën e tunelit.

Hyrjet e besimit nuk janë të njëjta me kandidatët e zinxhirit

Jepini verifikuesit dy hyrjet veçmas dhe në mënyrë eksplicite. Skedari i besimit mban spirancat që pranoni; paketa e pabesuar mban certifikata të ndërmjetme të ofruara për ndërtimin e rrugës. Përzierja e tyre është mënyra se si njerëzit aksidentalisht promovojnë një të ndërmjetme në rrënjë dhe pastaj pyesin veten pse i njëjti gabim i ndjek midis makinave.

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

Çaktivizimi i rrugës dhe depove të parazgjedhura me -no-CApath -no-CAstore e mban testin të ndershëm: rezultati atëherë varet nga skedarët që emërtuat, jo nga ajo që stacioni i punës beson rastësisht. Referenca e verifikimit të OpenSSL dokumenton këto opsione dhe diagnostikimin që prodhojnë.

-show_chain printon zinxhirin e ndërtuar kur verifikimi ka sukses, gjë që është e dobishme për të konfirmuar se rruga është ajo që synuat. Kur dështon, mbani thellësinë dhe subject-in e raportuar; këto dy fusha i thonë lexuesit tjetër cilën certifikatë të inspektojë.

Ajo që kjo nuk bën është të riprodhojë politikën e çdo klienti. Një pin, një kufizim qëllimi ose një kontroll identiteti specifik i klientit jeton në klient, jo në këtë komandë. Këto janë cilësimet për të inspektuar kur verifikimi kalon në server dhe lidhja ende dështon. Mbani dy diagnostikimet të ndara, përndryshe do të rinovoni një certifikatë të shëndetshme duke ndjekur një gabim pinning.

Çfarë provon kontrolli dhe çfarë lë jashtë

Ky është një kontroll rruge dhe qëllimi kundrejt një skedari besimi që ju dhatë. Për një kontroll emri HTTPS, shtoni emrin e pritur të hostit përmes opsionit të duhur; për një lidhje VPN, mbani kontrollet e identitetit të konfiguruara të klientit dhe përdorni materialin e besimit që ai klient lexon vërtet.

Ajo që dërgon një server është një grup kandidatësh, jo rruga që klienti juaj do të ndërtojë në fund. Besimi lokal dhe rregullat e ndërtimit të bibliotekës formësojnë të dyja rezultatin, kjo është arsyeja pse i njëjti përgjigje mund të verifikohet në një makinë dhe të dështojë në një tjetër. Krahasoni depon e besimit të mirëmbajtur dhe zbatimin TLS të klientit që dështon me ato të një klienti që funksionon përpara se të supozoni një vlerësim identik. Një ndryshim atje shpjegon shumë raporte „vetëm ky laptop dështon“.

Për të parë dritaren e secilës certifikatë në vend të një nga një, printoni ato si një grup:

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

Ai komandë e dytë liston subject-e dhe lëshues pa dekoduar çdo skedar me dorë, kështu vini re një të ndërmjetme, data e së cilës ka kaluar ndërsa gjetja ende duket mirë.

Riparoni rrugën pa dobësuar verifikimin

Kur ofrohet një e ndërmjetme e skaduar ose një certifikatë e nënshkruar kryq e vjetëruar, merrni zinxhirin aktualisht të mbështetur të lëshuesit dhe vendoseni atë përmes rrjedhës së dokumentuar të certifikatave të shërbimit. Kur klientit i mungon spiranca e mirëmbajtur e synuar, përditësoni konfigurimin e tij të menaxhuar të besimit ose softuerin e klientit. Rezistoni shkurtores për të shënuar çdo certifikatë në paketë si rrënjë vetëm për të heshtur mesazhin.

Trajtimi i rrënjës meriton një shënim, sepse përmbledhjet shpesh e ekzagjerojnë atë. RFC 5280 e trajton spirancën si një hyrje që qëndron jashtë rrugës së parashikuar, ndërsa OpenSSL dokumenton kontrolle vlefshmërie që përfshijnë certifikatën e tij CA rrënjësore. Të dyja deklaratat janë të vërteta për sistemet e tyre; përgjithësimi i sjelljes së skadimit të rrënjës të një biblioteke për çdo klient prodhon përgjigje të gabuara me besim.

Pas ndryshimit, detyroni një vërtetim të ri në klientin e prekur dhe konfirmoni se mesazhi specifik i skadimit ka shkuar. Rinovoni gjethen vetëm nëse vetë gjetja është e papërshtatshme. Çaktivizimi i kontrolleve të kohës ose rikthimi i një certifikate të vjetër kryq nuk prodhon një rrugë aktuale të vlefshme; thjesht vonon dështimin tjetër.

Artikuj të ngjashëm