tukematon sertifikaatin käyttötarkoitus: miksi välittävä CA epäonnistuu

Palvelimen sertifikaatin käyttötarkoitus näyttää oikealta, avain täsmää, päivämäärät ovat kunnossa, ja yhteys epäonnistuu silti virheeseen unsupported certificate purpose. Yksityiskohta, joka ratkaisee tämän, on yleensä samalla rivillä kuin virhe: syvyysarvo ja subject, jotka nimeävät ketjussa ylempänä olevan sertifikaatin. Käynnissä on kaksi eri testiä, ja vain toinen niistä koskee lehtisertifikaattia. Niiden vertailu selittää, miksi palvelimen sertifikaatin vaihtaminen ei muuta mitään.

Minkä sertifikaatin vahvistaja todella hylkäsi

Ketju ei ole yksi kolme kertaa toistettu objekti. Lehtisertifikaatti kantaa palvelimen nimen ja avaimen, välittävät sertifikaatit yhdistävät sen juureen, ja jokaisella on oma voimassaoloaikansa, rajoituksensa ja käyttönsä. Kun virhe nimeää syvyyden, tämä luku yksilöi sijainnin ketjussa, jonka vahvistaja rakensi, eikä se välttämättä ole odottamasi sijainti, jos palvelin lähettää odottamattoman ketjun.

Lue sertifikaatin kentät tältä syvyydeltä etkä siltä sertifikaatilta, jonka oletit olevan syyllinen. Pyydä kahta laajennusta, jotka rajoittavat myöntämistä, sen sijaan että tulostaisit jokaisen kentän, koska vastaus on lähes aina jommassa kummassa. Laajennusten tuloste on turvallista jakaa; yksityiset avaimet eivät koskaan.

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

Jos nimetty sertifikaatti on välittävä sertifikaatti, jonka laajennettu avainkäyttö mainitsee jotain, joka ei liity TLS-palvelimen tunnistamiseen, loput epäonnistumisesta seuraa mekaanisesti. Ketjua ei voi käyttää siihen käyttötarkoitukseen, jota OpenVPN pyysi.

Lehtisertifikaatin käyttötarkoitus ja ketjun käytäntö ovat kaksi testiä

Lehtisertifikaatin testi kysyy kapeaa kysymystä: salliiko tämä loppukokonaisuuden sertifikaatti palvelimen tunnistamisen tälle nimelle? Ketjun testi kysyy laajempaa: saako jokainen polun sertifikaatti palvella tätä käyttötarkoitusta? Vain asiakassertifikaatteja myöntämään oikeutettu varmentaja läpäisee omat allekirjoituksensa tarkistukset ja epäonnistuu silti toisessa testissä, koska polku, jonka se valtuuttaa, ei sisällä käyttötarkoitusta, jota sovellus tarvitsee. Molemmat testit epäonnistuvat samoilla sanoilla ja niillä on täysin erilaiset korjaukset.

Siksi juuri myönnetty lehtisertifikaatti, joka on jokaisessa näkyvässä kentässä oikein, voi epäonnistua heti. Siksi myös korjaus kuuluu yleensä myöntävän tahon profiiliin eikä VPN:n kokoonpanoon.

Puuttuva EKU ei ole rajoittava EKU

RFC 5280 tekee laajennetun avainkäytön laajennuksesta valinnaisen ja sen ollessa läsnä rajoittavan. Siksi CA-sertifikaatti ilman laajennusta ei ole sanonut «ei» palvelimen tunnistamiselle, kun taas sellainen, joka luettelee vain asiaankuulumattoman käyttötarkoituksen, on sanonut jotain hyvin täsmällistä. Näiden kahden tilan pitäminen samanarvoisina tuottaa väärän diagnoosin ja, pahempaa, väärän korjauksen. Ero selittää myös, miksi kaksi konsolissa samannäköistä tahoa käyttäytyvät ketjussa täysin eri tavoin.

Kirjastojen käyttäytyminen ei ole tässäkään yhtenäistä. OpenSSL:n asiakirja vahvistusvalinnoista kuvaa oman tapansa käsitellä CA-sertifikaattien käyttötarkoitustarkistuksia, ja tämä tapa on toteutuskäytäntö, ei sääntö, jota jokainen TLS-pino noudattaa samalla tavalla. Kuvaile, mitä vahvistajasi tekee, ja vahvista se sitten versiolla, jota todella ajat.

Toista epäonnistuminen offline-tilassa ennen uudelleenmyöntöä

Offline-vahvistus poistaa sovelluksen yhtälöstä. Jos ketju epäonnistuu samalla tavalla saman käyttötarkoituksen alla, ongelma on sertifikaatissa, eikä mikään palvelimen kokoonpano peitä sitä. Jos ketju läpäisee offline-tilassa, kun palvelu yhä kieltäytyy, sovellus pyytää toista käyttötarkoitusta tai käyttää toista ketjua kuin testaamaasi.

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

-show_chain on tärkeä, koska se tulostaa polun, jonka työkalu rakensi, eikä se useinkaan ole antamasi tiedostojärjestys. Tämä tuloste on nopein tapa havaita, että toinen välittävä sertifikaatti vedetään luottamussäilöstä, että palvelin lähettää ristiinallekirjoitetun variantin, jota et tarkoittanut, tai että opetusohjelmasta kopioimasi käyttötarkoituksen lippu kuuluu eri roolille kuin se, jota palvellaan.

Korjaa myöntämiskäytäntöä, ei vahvistuskutsua

Kestävä korjaus on välittävä sertifikaatti, joka on myönnetty käytännön mukaisesti, joka sallii sen palveltavat käyttötarkoitukset, ja rajoitus on kirjattu ja tarkistettu. Jokaisen käyttötarkoituksen lisääminen jokaiselle taholle ei ole käytäntö; se poistaa rajoituksen, joka teki laajennuksesta merkityksellisen alun perin, ja se elää yleensä kauemmin kuin sen laukaisema tapaus. Lyhyt merkintä profiilissa, joka kuvaa, mitä rooleja taho saa varmentaa, estää seuraavaa uudelleenmyöntöä toistamasta samaa väittelyä.

Vahvistuksen poistaminen käytöstä on toinen houkutteleva oikopolku, ja se muuttaa sertifikaationgelman luottamusongelmaksi. Pidä käyttötarkoitustarkistus paikallaan, korjaa ketju ja aja sama offline-vahvistus uudelleen vahvistaaksesi, että polku palvelee nyt aiottua roolia ennen kuin kosket palveluun uudelleen.