ikke-støttet sertifikatformål: hvorfor den mellomliggende CA-en feiler

Serversertifikatets formål ser riktig ut, nøkkelen stemmer, datoene er i orden, og tilkoblingen feiler fortsatt med unsupported certificate purpose. Detaljen som løser dette, står vanligvis på samme linje som feilen: en dybdeverdi og et subject som navngir et sertifikat høyere oppe i kjeden. To forskjellige tester kjøres, og bare én av dem handler om bladet. Å sammenligne dem forklarer hvorfor utskifting av serversertifikatet ikke endrer noe.

Hvilket sertifikat verifikatoren faktisk avviste

En kjede er ikke ett objekt gjentatt tre ganger. Bladet bærer serverens navn og nøkkel, de mellomliggende sertifikatene kobler det til en rot, og hvert har sin egen gyldighetsperiode, begrensninger og bruksområder. Når feilen angir en dybde, identifiserer tallet en posisjon i kjeden verifikatoren bygde, og det er kanskje ikke posisjonen du forventer hvis serveren sender en uventet kjede.

Les feltene til sertifikatet på den dybden i stedet for sertifikatet du antok var skyldig. Be om de to utvidelsene som begrenser utstedelsen i stedet for å dumpe hvert felt, fordi svaret nesten alltid ligger i en av dem. Utvidelsesutdata er trygt å dele; private nøkler aldri.

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

Hvis det navngitte sertifikatet er et mellomliggende sertifikat med utvidet nøkkelbruk som nevner noe uten forbindelse til TLS-serverautentisering, følger resten av feilen mekanisk. Kjeden kan ikke brukes til formålet OpenVPN ba om.

Bladets formål og kjedens policy er to tester

Bladtesten stiller et snevert spørsmål: tillater dette sluttenhetssertifikatet serverautentisering for dette navnet? Kjedetesten stiller et bredere: kan hvert sertifikat i banen tjene det formålet? En sertifiseringsmyndighet som bare har lov til å utstede klientsertifikater, vil bestå sine egne signaturkontroller og likevel feile den andre testen, fordi banen den autoriserer ikke omfatter formålet applikasjonen trenger. De to testene feiler med de samme ordene og har helt forskjellige reparasjoner.

Derfor kan et nyutstedt blad, korrekt i hvert synlig felt, feile umiddelbart. Derfor hører rettelsen vanligvis til profilen til den utstedende myndigheten og ikke til VPN-konfigurasjonen.

En manglende EKU er ikke en begrensende EKU

RFC 5280 gjør utvidelsen for utvidet nøkkelbruk valgfri og, når den er til stede, begrensende. Et CA-sertifikat uten utvidelsen har derfor ikke sagt «nei» til serverautentisering, mens et som bare lister et uvesentlig formål har sagt noe svært spesifikt. Å behandle de to tilstandene som likeverdige gir feil diagnose og, verre, feil reparasjon. Forskjellen forklarer også hvorfor to myndigheter som ser like ut i en konsoll, oppfører seg helt ulikt i en kjede.

Bibliotekatferd er heller ikke ensartet her. OpenSSL-dokumentasjonen om verifiseringsvalg beskriver sin egen behandling av formålskontroller på CA-sertifikater, og den behandlingen er en implementasjonspolicy snarere enn en regel hver TLS-stakk følger identisk. Beskriv hva verifikatoren din gjør, og bekreft det deretter mot versjonen du faktisk kjører.

Gjenskap feilen offline før du utsteder på nytt

En offline verifisering tar applikasjonen ut av spørsmålet. Hvis kjeden feiler på samme måte under samme formål, er sertifikatet problemet, og ingen serverkonfigurasjon skjuler det. Hvis kjeden består offline mens tjenesten fortsatt avviser, ber applikasjonen om et annet formål eller bruker en annen kjede enn den du testet.

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

-show_chain betyr noe fordi det skriver ut banen verktøyet bygde, og den er ofte ikke filrekkefølgen du oppga. Disse utdataene er den raskeste måten å oppdage at et annet mellomliggende sertifikat hentes fra et tillitslager, at serveren sender en kryssignert variant du ikke hadde tenkt, eller at formålsflagget du kopierte fra en veiledning tilhører en annen rolle enn den som betjenes.

Rett utstedelsespolicyn, ikke verifikasjonskallet

Den varige reparasjonen er et mellomliggende sertifikat utstedt under en policy som tillater formålene det skal tjene, med begrensningen skrevet ned og gjennomgått. Å legge hvert formål til hver myndighet er ikke en policy; det fjerner begrensningen som gjorde utvidelsen meningsfull, og den overlever vanligvis hendelsen som fremkalte den. Et kort notat i profilen som beskriver hvilke roller myndigheten kan sertifisere, hindrer at den neste nyutstedelsen gjentar den samme diskusjonen.

Å slå av verifisering er den andre fristende snarveien, og den gjør et sertifikatproblem om til et tillitsproblem. Behold formålskontrollen, rett kjeden og kjør den samme offline-verifiseringen på nytt for å bekrefte at banen nå tjener den tiltenkte rollen før du rører tjenesten igjen.