certifikatändamål som inte stöds: varför den mellanliggande CA:n misslyckas

Servercertifikatets ändamål ser rätt ut, nyckeln matchar, datumen är i ordning, och anslutningen misslyckas ändå med unsupported certificate purpose. Den detalj som löser detta finns vanligtvis på samma rad som felet: ett djupvärde och ett subject som namnger ett certifikat högre upp i kedjan. Två olika tester körs, och bara ett av dem handlar om lövet. Att jämföra dem förklarar varför byte av servercertifikatet inte ändrar något.

Vilket certifikat verifieraren faktiskt avvisade

En kedja är inte ett objekt som upprepas tre gånger. Lövet bär serverns namn och nyckel, de mellanliggande certifikaten länkar det till en rot, och var och en har sin egen giltighetstid, begränsningar och användning. När felet anger ett djup identifierar den siffran en position i kedjan som verifieraren byggde, och det är kanske inte den position du förväntar dig om servern skickar en oväntad kedja.

Läs fälten för certifikatet på det djupet i stället för certifikatet du antog var skyldigt. Begär de två tillägg som begränsar utfärdandet i stället för att dumpa varje fält, eftersom svaret nästan alltid finns i ett av dem. Tilläggsutdata är säkert att dela; privata nycklar aldrig.

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

Om det namngivna certifikatet är ett mellanliggande certifikat vars utökade nyckelanvändning nämner något som inte har med TLS-serverautentisering att göra, följer resten av felet mekaniskt. Kedjan kan inte användas för det ändamål som OpenVPN begärde.

Lövets ändamål och kedjans policy är två tester

Lövtestet ställer en snäv fråga: tillåter detta slutentitetscertifikat serverautentisering för detta namn? Kedjetestet ställer en bredare: får varje certifikat i vägen tjäna det ändamålet? En certifikatmyndighet som bara får utfärda klientcertifikat klarar sina egna signaturkontroller och misslyckas ändå i det andra testet, eftersom den väg den auktoriserar inte innehåller det ändamål som applikationen behöver. De två testerna misslyckas med samma ord och har helt olika reparationer.

Därför kan ett nyutfärdat löv, korrekt i varje synligt fält, misslyckas omedelbart. Därför hör rättelsen vanligtvis till profilen för den utfärdande myndigheten och inte till VPN-konfigurationen.

En saknad EKU är inte en begränsande EKU

RFC 5280 gör tillägget för utökad nyckelanvändning valfritt och, när det finns, begränsande. Ett CA-certifikat utan tillägget har därför inte sagt «nej» till serverautentisering, medan ett som bara listar ett orelaterat ändamål har sagt något mycket specifikt. Att behandla dessa två tillstånd som likvärdiga ger fel diagnos och, värre, fel reparation. Skillnaden förklarar också varför två myndigheter som ser likadana ut i en konsol beter sig helt olika i en kedja.

Bibliotekens beteende är inte heller enhetligt här. OpenSSL-dokumentationen om verifieringsalternativ beskriver sin egen behandling av ändamålskontroller på CA-certifikat, och den behandlingen är en implementeringspolicy snarare än en regel som varje TLS-stack följer identiskt. Beskriv vad din verifierare gör och bekräfta det sedan mot den version du faktiskt kör.

Återskapa felet offline innan du utfärdar på nytt

En offline-verifiering tar bort applikationen från ekvationen. Om kedjan misslyckas på samma sätt under samma ändamål är certifikatet problemet och ingen serverkonfiguration döljer det. Om kedjan går igenom offline medan tjänsten fortfarande vägrar, begär applikationen ett annat ändamål eller använder en annan kedja än den du testade.

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

-show_chain spelar roll eftersom det skriver ut den väg som verktyget byggde, och den är ofta inte den filordning du angav. Den utdatan är det snabbaste sättet att upptäcka att ett andra mellanliggande certifikat hämtas från ett förtroendelager, att servern skickar en korssignerad variant som du inte avsåg, eller att den ändamålsflagga du kopierade från en handledning tillhör en annan roll än den som betjänas.

Rätta utfärdandepolicyn, inte verifieringsanropet

Den hållbara reparationen är ett mellanliggande certifikat utfärdat enligt en policy som tillåter de ändamål det måste tjäna, med begränsningen nedskriven och granskad. Att lägga till varje ändamål hos varje myndighet är inte en policy; det tar bort den begränsning som gav tillägget mening, och den överlever vanligtvis incidenten som föranledde den. En kort anteckning i profilen som beskriver vilka roller myndigheten får certifiera hindrar nästa nyutfärdande från att upprepa samma diskussion.

Att stänga av verifiering är den andra frestande genvägen, och den förvandlar ett certifikatproblem till ett förtroendeproblem. Behåll ändamålskontrollen, rätta kedjan och kör samma offline-verifiering igen för att bekräfta att vägen nu tjänar den avsedda rollen innan du rör tjänsten igen.