Onondersteunde sertifikaatdoel: waarom die intermediêre CA misluk

Die bediener se sertifikaatdoel lyk reg, die sleutel pas, die datums is in orde, en die verbinding misluk steeds met unsupported certificate purpose. Die besonderheid wat dit oplos, staan gewoonlik op dieselfde reël as die fout: 'n dieptewaarde en 'n onderwerp wat 'n sertifikaat hoër in die ketting noem. Twee verskillende toetse word uitgevoer, en slegs een daarvan gaan oor die blad. Deur hulle te vergelyk, verduidelik waarom die vervanging van die bediener se sertifikaat niks verander nie.

Watter sertifikaat die verifieerder werklik verwerp het

'n Ketting is nie een voorwerp wat drie keer herhaal word nie. Die blad dra die bediener se naam en sleutel, die intermediêre sertifikate verbind dit aan 'n wortel, en elkeen het sy eie geldigheidsperiode, beperkings en gebruike. Wanneer die fout 'n diepte noem, dui daardie nommer 'n posisie in die ketting aan wat die verifieerder gebou het, wat dalk nie die posisie is wat jy verwag as die bediener 'n onverwagte ketting stuur nie.

Lees die velde van die sertifikaat op daardie diepte eerder as die sertifikaat waarvan jy aangeneem het dit is fout. Vra vir die twee uitbreidings wat uitreiking beperk in plaas daarvan om elke veld uit te gooi, want die antwoord is byna altyd een van hulle. Uitbreidingsuitsette is veilig om te deel; private sleutels nooit nie.

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

As die genoemde sertifikaat 'n intermediêre sertifikaat is wie se uitgebreide sleutelgebruik iets noem wat nie met TLS-bedienerverifikasie verband hou nie, volg die res van die fout meganies. Die ketting kan nie gebruik word vir die doel wat OpenVPN versoek het nie.

Blad se doel en kettingbeleid is twee toetse

Die bladtoets vra 'n eng vraag: laat hierdie eindentiteit-sertifikaat bedienerverifikasie vir hierdie naam toe? Die kettingtoets vra 'n wyer een: mag elke sertifikaat in die pad daardie doel dien? 'n Sertifikaatowerheid wat slegs kliëntsertifikate mag uitreik, sal sy eie handtekeningtoetse slaag en steeds die tweede toets druip, want die pad wat dit magtig, sluit nie die doel in wat die toepassing benodig nie. Die twee toetse druip met dieselfde woorde en het heeltemal verskillende herstellings.

Dit is waarom 'n nuut uitgereikte blad, korrek in elke sigbare veld, dadelik kan misluk. Dit is ook waarom die regstelling gewoonlik by die profiel van die uitreikende owerheid hoort eerder as by die VPN-konfigurasie.

'n Afwesige EKU is nie 'n beperkende EKU nie

RFC 5280 maak die uitgebreide sleutelgebruik-uitbreiding opsioneel en, wanneer dit teenwoordig is, beperkend. 'n CA-sertifikaat sonder die uitbreiding het dus nie 'nee' gesê vir bedienerverifikasie nie, terwyl een wat slegs 'n onverwante doel lys, iets heel spesifiek gesê het. Om daardie twee toestande as gelykwaardig te behandel, lewer die verkeerde diagnose en, erger, die verkeerde herstelling. Die onderskeid verduidelik ook waarom twee owerhede wat in 'n konsole soortgelyk lyk, heeltemal anders in 'n ketting optree.

Biblioteekgedrag is hier ook nie eenvormig nie. OpenSSL se dokument oor verifikasie-opsies beskryf sy eie hantering van doeltoetse op CA-sertifikate, en daardie hantering is 'n implementeringsbeleid eerder as 'n reël wat elke TLS-stapel identies volg. Beskryf wat jou verifieerder doen en bevestig dit dan teen die weergawe wat jy werklik gebruik.

Herhaal die fout vanlyn voordat jy heruitreik

'n Vanlyn verifikasie verwyder die toepassing uit die vraag. As die ketting op dieselfde manier onder dieselfde doel misluk, is die sertifikaat die probleem en geen hoeveelheid bedienerkonfigurasie sal dit verberg nie. As die ketting vanlyn slaag terwyl die diens steeds weier, versoek die toepassing 'n ander doel of gebruik dit 'n ander ketting as die een wat jy getoets het.

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

-show_chain maak saak omdat dit die pad druk wat die instrument gebou het, wat dikwels nie die lêervolgorde is wat jy verskaf het nie. Daardie uitset is die vinnigste manier om te ontdek dat 'n tweede intermediêre sertifikaat uit 'n truststore getrek word, dat die bediener 'n kruisgetekende variant stuur wat jy nie bedoel het nie, of dat die doelvlag wat jy uit 'n tutoriaal gekopieer het aan 'n ander rol behoort as die een wat bedien word.

Maak die uitreikingsbeleid reg, nie die verifikasie-oproep nie

Die duursame herstelling is 'n intermediêre sertifikaat wat uitgereik is onder 'n beleid wat die doele toelaat wat dit moet dien, met die beperking neergeskryf en hersien. Om elke doel by elke owerheid te voeg, is nie 'n beleid nie; dit verwyder die beperking wat die uitbreiding sinvol gemaak het, en dit oorleef gewoonlik die voorval wat dit veroorsaak het. 'n Kort nota in die profiel wat beskryf watter rolle die owerheid mag sertifiseer, voorkom dat die volgende heruitreiking dieselfde argument herhaal.

Om verifikasie af te skakel, is die ander aanloklike kortpad, en dit omskep 'n sertifikaatprobleem in 'n vertrouensprobleem. Hou die doeltoets in plek, maak die ketting reg en herhaal dieselfde vanlyn verifikasie om te bevestig dat die pad nou die bedoelde rol dien voordat jy die diens weer aanraak.