ikke-understøttet certifikatformål: hvorfor den mellemliggende CA fejler

Servercertifikatets formål ser rigtigt ud, nøglen passer, datoerne er fine, og forbindelsen fejler stadig med unsupported certificate purpose. Den detalje, der løser det, står normalt på samme linje som fejlen: en dybdeværdi og et subject, der navngiver et certifikat højere oppe i kæden. Der køres to forskellige test, og kun den ene handler om bladet. At sammenligne dem forklarer, hvorfor udskiftning af servercertifikatet ikke ændrer noget.

Hvilket certifikat verifikatoren faktisk afviste

En kæde er ikke ét objekt gentaget tre gange. Bladet bærer serverens navn og nøgle, de mellemliggende certifikater forbinder det til en rod, og hvert har sin egen gyldighedsperiode, begrænsninger og anvendelser. Når fejlen angiver en dybde, identificerer det tal en position i den kæde, verifikatoren byggede, og det er måske ikke den position, du forventer, hvis serveren sender en uventet kæde.

Læs felterne på certifikatet i den dybde i stedet for det certifikat, du antog var skyld i det. Bed om de to udvidelser, der begrænser udstedelsen, i stedet for at dumpe hvert felt, fordi svaret næsten altid er i en af dem. Udvidelsesoutput er sikkert at dele; private nøgler aldrig.

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

Hvis det navngivne certifikat er et mellemliggende certifikat, hvis udvidede nøgleanvendelse nævner noget, der ikke har med TLS-servergodkendelse at gøre, følger resten af fejlen mekanisk. Kæden kan ikke bruges til det formål, som OpenVPN anmodede om.

Bladets formål og kædens politik er to test

Bladtesten stiller et snævert spørgsmål: tillader dette slutentitetscertifikat servergodkendelse for dette navn? Kædetesten stiller et bredere: må hvert certifikat i stien tjene det formål? En certifikatmyndighed, der kun må udstede klientcertifikater, består sine egne signaturkontroller og fejler alligevel den anden test, fordi den sti, den autoriserer, ikke omfatter det formål, applikationen har brug for. De to test fejler med de samme ord og har helt forskellige reparationer.

Det er derfor et nyudstedt blad, korrekt i hvert synligt felt, kan fejle med det samme. Det er også derfor rettelsen normalt hører til den udstedende myndigheds profil og ikke til VPN-konfigurationen.

En manglende EKU er ikke en begrænsende EKU

RFC 5280 gør udvidelsen udvidet nøgleanvendelse valgfri og, når den er til stede, begrænsende. Et CA-certifikat uden udvidelsen har derfor ikke sagt „nej“ til servergodkendelse, mens et, der kun lister et uvedkommende formål, har sagt noget meget specifikt. At behandle de to tilstande som ækvivalente giver den forkerte diagnose og, værre, den forkerte reparation. Forskellen forklarer også, hvorfor to myndigheder, der ser ens ud i en konsol, opfører sig helt forskelligt i en kæde.

Biblioteksadfærd er heller ikke ens her. OpenSSL's dokument om verifikationsmuligheder beskriver sin egen behandling af formålskontroller på CA-certifikater, og den behandling er en implementeringspolitik snarere end en regel, som hver TLS-stak følger identisk. Beskriv, hvad din verifikator gør, og bekræft det derefter mod den version, du faktisk kører.

Genskab fejlen offline, før du genudsteder

En offline verifikation fjerner applikationen fra spørgsmålet. Hvis kæden fejler på samme måde under samme formål, er certifikatet problemet, og ingen serverkonfiguration skjuler det. Hvis kæden består offline, mens tjenesten stadig afviser, anmoder applikationen om et andet formål eller bruger en anden kæde end den, du testede.

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

-show_chain betyder noget, fordi det udskriver den sti, værktøjet byggede, og den er ofte ikke den filrækkefølge, du angav. Det output er den hurtigste måde at opdage, at et andet mellemliggende certifikat trækkes fra et tillidslager, at serveren sender en krydssigneret variant, du ikke havde til hensigt, eller at det formålsflag, du kopierede fra en vejledning, tilhører en anden rolle end den, der betjenes.

Ret udstedelsespolitikken, ikke verifikationskaldet

Den holdbare reparation er et mellemliggende certifikat udstedt under en politik, der tillader de formål, det skal tjene, med begrænsningen skrevet ned og gennemgået. At tilføje hvert formål til hver myndighed er ikke en politik; det fjerner den begrænsning, der gjorde udvidelsen meningsfuld i første omgang, og det overlever normalt den hændelse, der fremkaldte det. En kort note i profilen, der beskriver, hvilke roller myndigheden må certificere, forhindrer, at den næste genudstedelse gentager den samme diskussion.

At slå verifikationen fra er den anden fristende genvej, og den forvandler et certifikatproblem til et tillidsproblem. Behold formålskontrollen, ret kæden, og kør den samme offline verifikation igen for at bekræfte, at stien nu tjener den tilsigtede rolle, før du rører tjenesten igen.