Namen strežniškega certifikata je videti pravilen, ključ se ujema, datumi so v redu, povezava pa kljub temu spodleti z unsupported certificate purpose. Podrobnost, ki to reši, je običajno v isti vrstici kot napaka: vrednost globine in subject, ki poimenujeta certifikat višje v verigi. Izvajata se dva različna preskusa in le eden od njiju zadeva končni certifikat. Njuna primerjava pojasni, zakaj zamenjava strežniškega certifikata ne spremeni ničesar.

Kateri certifikat je preverjevalnik dejansko zavrnil

Veriga ni en predmet, ponovljen trikrat. Končni certifikat nosi ime in ključ strežnika, vmesni ga povežejo s korenom, vsak pa ima svoje obdobje veljavnosti, omejitve in uporabe. Ko napaka navede globino, ta številka označuje položaj v verigi, ki jo je zgradil preverjevalnik, in ta morda ni položaj, ki ga pričakujete, če strežnik pošlje nepričakovano verigo.

Preberite polja certifikata na tej globini, ne certifikata, za katerega ste domnevali, da je kriv. Zahtevajte dve razširitvi, ki omejujeta izdajo, namesto da izpišete vsako polje, ker je odgovor skoraj vedno v eni od njiju. Izpis razširitev je varen za deljenje; zasebni ključi nikoli.

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

Če je navedeni certifikat vmesni in njegova razširjena uporaba ključa omenja nekaj, kar ni povezano s preverjanjem strežnika TLS, preostanek napake sledi mehanično. Verige ni mogoče uporabiti za namen, ki ga je zahteval OpenVPN.

Namen končnega certifikata in politika verige sta dva preskusa

Preskus končnega certifikata postavi ozko vprašanje: ali ta certifikat končnega subjekta dovoljuje preverjanje strežnika za to ime? Preskus verige postavi širše: ali lahko vsak certifikat na poti služi temu namenu? Certifikacijski organ, ki sme izdajati samo odjemalske certifikate, bo prestal lastne kontrolnike podpisa in vseeno padel na drugem preskusu, ker pot, ki jo odobri, ne vključuje namena, ki ga aplikacija potrebuje. Oba preskusa spodletita z istimi besedami in imata popolnoma različne popravke.

Zato lahko na novo izdan končni certifikat, pravilen v vseh vidnih poljih, takoj spodleti. Zato popravek običajno spada v profil izdajatelja in ne v konfiguracijo VPN.

Odsoten EKU ni omejujoč EKU

RFC 5280 naredi razširitev razširjene uporabe ključa neobvezno in, kadar je prisotna, omejujočo. Certifikat CA brez razširitve torej ni rekel „ne“ preverjanju strežnika, medtem ko je tisti, ki navaja samo nepovezan namen, povedal nekaj zelo določnega. Obravnavanje teh dveh stanj kot enakovrednih prinese napačno diagnozo in, še huje, napačen popravek. Razlika tudi pojasni, zakaj se dva organa, ki so v konzoli videti podobna, v verigi obnašata povsem različno.

Tudi vedenje knjižnic tu ni enotno. dokument OpenSSL o možnostih preverjanja opisuje svoj pristop k preverjanjem namena pri certifikatih CA, in ta pristop je politika izvedbe, ne pravilo, ki bi se ga vsak sklad TLS držal enako. Opišite, kaj počne vaš preverjevalnik, in to nato potrdite na različici, ki jo dejansko poganjate.

Pred ponovno izdajo ponovite napako brez povezave

Preverjanje brez povezave odstrani aplikacijo iz enačbe. Če veriga spodleti enako pri istem namenu, je problem v certifikatu in nobena konfiguracija strežnika tega ne bo skrila. Če veriga uspe brez povezave, medtem ko storitev še vedno zavrača, aplikacija zahteva drug namen ali uporablja drugo verigo od preizkušene.

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

-show_chain je pomemben, ker izpiše pot, ki jo je zgradilo orodje, ta pa pogosto ni vrstni red datotek, ki ste ga navedli. Ta izpis je najhitrejši način, da odkrijete, da se drugi vmesni certifikat vleče iz skladišča zaupanja, da strežnik pošilja navzkrižno podpisano različico, ki je niste nameravali, ali da zastavica namena, kopirana iz vadnice, pripada drugi vlogi od tiste, ki se streže.

Popravite politiko izdajanja, ne klica preverjanja

Trajna poprava je vmesni certifikat, izdan po politiki, ki dovoljuje namene, ki jim mora služiti, z omejitvijo zapisano in pregledano. Dodajanje vsakega namena vsakemu organu ni politika; odstrani omejitev, ki je razširitvi dala smisel, in običajno preživi incident, ki ga je sprožil. Kratka opomba v profilu, ki opisuje, katere vloge organ sme potrjevati, prepreči, da bi naslednja izdaja ponovila isto razpravo.

Izklop preverjanja je druga zapeljiva bližnjica in spremeni težavo s certifikatom v težavo z zaupanjem. Ohranite preverjanje namena, popravite verigo in znova zaženite isto preverjanje brez povezave, da potrdite, da pot zdaj služi predvideni vlogi, preden se znova dotaknete storitve.

Sorodni članki