toetamata sertifikaadi otstarve: miks vahepealne CA ebaõnnestub

Serveri sertifikaadi otstarve näib õige, võti klapib, kuupäevad on korras, ja ühendus ebaõnnestub ikkagi veaga unsupported certificate purpose. Üksikasjad, mis selle lahendavad, on tavaliselt samal real kui viga: sügavuse väärtus ja subjekt, mis nimetavad sertifikaadi ahelas kõrgemal. Käivitatakse kaks erinevat testi ja ainult üks neist puudutab lõppsertifikaati. Nende võrdlemine selgitab, miks serveri sertifikaadi asendamine ei muuda midagi.

Millise sertifikaadi verifitseerija tegelikult tagasi lükkas

Ahel ei ole üks objekt, mida korratakse kolm korda. Lõppsertifikaat kannab serveri nime ja võtit, vahepealsed sertifikaadid seovad selle juurega, ja igal neist on oma kehtivusaeg, piirangud ja kasutused. Kui viga nimetab sügavust, tähistab see number positsiooni ahelas, mille verifitseerija ehitas, ja see ei pruugi olla positsioon, mida ootate, kui server saadab ootamatu ahela.

Lugege selle sügavuse sertifikaadi välju, mitte sertifikaadi, mida pidasite süüdlaseks. Küsige kahte laiendust, mis väljastamist piiravad, selle asemel et kõiki välju välja kirjutada, sest vastus on peaaegu alati ühes neist. Laienduste väljundit on ohutu jagada; privaatvõtmeid mitte kunagi.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Kui nimetatud sertifikaat on vahepealne, mille laiendatud võtmekasutus mainib midagi, mis ei ole seotud TLS-serveri autentimisega, järgneb ülejäänud ebaõnnestumine mehaaniliselt. Ahelat ei saa kasutada otstarbeks, mida OpenVPN taotles.

Lõppsertifikaadi otstarve ja ahela poliitika on kaks testi

Lõppsertifikaadi test küsib kitsa küsimuse: kas see lõppüksuse sertifikaat lubab selle nime jaoks serveri autentimist? Ahela test küsib laiema: kas iga sertifikaat teel võib seda otstarvet teenida? Sertifitseerimisasutus, kellel on lubatud väljastada ainult kliendisertifikaate, läbib oma allkirjakontrollid ja ebaõnnestub ikkagi teises testis, sest tee, mille ta autoriseerib, ei sisalda otstarvet, mida rakendus vajab. Mõlemad testid ebaõnnestuvad samade sõnadega ja neil on täiesti erinevad parandused.

Seetõttu võib värskelt väljastatud lõppsertifikaat, mis on igas nähtavas väljas korrektne, kohe ebaõnnestuda. Seetõttu kuulub parandus tavaliselt väljastava asutuse profiili, mitte VPN-i seadistusse.

Puuduv EKU ei ole piirav EKU

RFC 5280 muudab laiendatud võtmekasutuse laienduse vabatahtlikuks ja selle olemasolul piiravaks. Seega ei ole CA-sertifikaat ilma laienduseta öelnud serveri autentimisele «ei», samas kui selline, mis loetleb ainult kõrvalise otstarbe, on öelnud midagi väga konkreetset. Nende kahe oleku samaväärseks pidamine annab vale diagnoosi ja veel hullema, vale paranduse. Erinevus selgitab ka seda, miks kaks asutust, mis konsoolis sarnased paistavad, käituvad ahelas täiesti erinevalt.

Ka teekide käitumine ei ole siin ühtne. OpenSSL-i dokument kontrollivalikute kohta kirjeldab oma käsitlust CA-sertifikaatide otstarbe kontrollidest ja see käsitlus on rakenduspoliitika, mitte reegel, mida iga TLS-pinu järgib identselt. Kirjeldage, mida teie verifitseerija teeb, ja kinnitage see siis versioonil, mida te tegelikult käitate.

Taastage tõrge võrguühenduseta enne uuesti väljastamist

Võrguühenduseta kontroll eemaldab rakenduse võrrandist. Kui ahel ebaõnnestub sama otstarbe korral samamoodi, on probleem sertifikaadis ja ükski serveri seadistus ei varja seda. Kui ahel läbib võrguühenduseta, samal ajal kui teenus ikka keeldub, taotleb rakendus teist otstarvet või kasutab teist ahelat kui see, mida katsetasite.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain on oluline, sest see trükib tee, mille tööriist ehitas, ja see ei ole sageli see failijärjekord, mille te esitasite. See väljund on kiireim viis avastada, et teine vahepealne sertifikaat tõmmatakse usaldushoidlast, et server saadab ristallkirjastatud variandi, mida te ei kavatsenud, või et õpetusest kopeeritud otstarbe lipp kuulub teisele rollile kui teenindatav.

Parandage väljastamispoliitikat, mitte verifitseerimiskutset

Kestev parandus on vahepealne sertifikaat, mis on väljastatud poliitika alusel, mis lubab otstarbed, mida see peab teenima, kirja pandud ja üle vaadatud piiranguga. Iga otstarbe lisamine igale asutusele ei ole poliitika; see eemaldab piirangu, mis andis laiendusele mõtte, ja elab tavaliselt üle juhtumi, mis selle esile kutsus. Lühike märkus profiilis, mis kirjeldab, milliseid rolle asutus võib sertifitseerida, hoiab järgmise uuesti väljastamise sama vaidluse kordamisest.

Kontrolli väljalülitamine on teine ahvatlev otsetee ja see muudab sertifikaadiprobleemi usaldusprobleemiks. Jätke otstarbe kontroll alles, parandage ahel ja käivitage sama võrguühenduseta kontroll uuesti, et kinnitada, et tee teenib nüüd kavandatud rolli, enne kui teenust uuesti puudutate.