niet-ondersteund certificaatdoel: waarom de tussenliggende CA faalt

Het doel van het servercertificaat lijkt juist, de sleutel komt overeen, de datums zijn in orde, en de verbinding mislukt nog steeds met unsupported certificate purpose. Het detail dat dit oplost staat meestal op dezelfde regel als de fout: een dieptewaarde en een subject die een certificaat hoger in de keten benoemen. Er worden twee verschillende tests uitgevoerd, en slechts één daarvan gaat over het eindcertificaat. Ze vergelijken verklaart waarom het vervangen van het servercertificaat niets verandert.

Welk certificaat de verifier daadwerkelijk afwees

Een keten is niet één object dat drie keer wordt herhaald. Het eindcertificaat draagt de naam en sleutel van de server, de tussenliggende certificaten verbinden het met een wortel, en elk heeft zijn eigen geldigheidsduur, beperkingen en gebruik. Wanneer de fout een diepte noemt, identificeert dat getal een positie in de keten die de verifier heeft opgebouwd, en dat is misschien niet de positie die u verwacht als de server een onverwachte keten stuurt.

Lees de velden van het certificaat op die diepte in plaats van het certificaat dat u als schuldige aannam. Vraag de twee extensies die de uitgifte beperken in plaats van elk veld te dumpen, want het antwoord zit bijna altijd in een van beide. Extensie-uitvoer is veilig om te delen; persoonlijke sleutels nooit.

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

Als het genoemde certificaat een tussenliggend certificaat is waarvan het uitgebreide sleutelgebruik iets noemt dat niets met TLS-serverauthenticatie te maken heeft, volgt de rest van de fout mechanisch. De keten kan niet worden gebruikt voor het doel dat OpenVPN heeft aangevraagd.

Het doel van het eindcertificaat en het ketenbeleid zijn twee tests

De eindcertificaattest stelt een smalle vraag: staat dit eindentiteitscertificaat serverauthenticatie voor deze naam toe? De ketentest stelt een bredere: mag elk certificaat in het pad dat doel dienen? Een certificaatautoriteit die alleen clientcertificaten mag uitgeven, slaagt voor haar eigen handtekeningcontroles en faalt toch voor de tweede test, omdat het pad dat zij autoriseert niet het doel bevat dat de applicatie nodig heeft. De twee tests falen met dezelfde woorden en hebben volledig verschillende reparaties.

Daarom kan een pas uitgegeven eindcertificaat, correct in elk zichtbaar veld, onmiddellijk falen. Daarom hoort de correctie meestal bij het profiel van de uitgevende autoriteit en niet bij de VPN-configuratie.

Een ontbrekende EKU is geen beperkende EKU

RFC 5280 maakt de uitgebreide sleutelgebruikextensie optioneel en, wanneer aanwezig, beperkend. Een CA-certificaat zonder de extensie heeft dus geen «nee» gezegd tegen serverauthenticatie, terwijl een certificaat dat alleen een ongerelateerd doel vermeldt iets heel specifieks heeft gezegd. Die twee toestanden als gelijkwaardig behandelen levert de verkeerde diagnose op en, erger, de verkeerde reparatie. Het onderscheid verklaart ook waarom twee autoriteiten die er in een console hetzelfde uitzien, zich in een keten volstrekt anders gedragen.

Ook het gedrag van bibliotheken is hier niet uniform. OpenSSL-documentatie over verificatieopties beschrijft de eigen behandeling van doelcontroles op CA-certificaten, en die behandeling is een implementatiebeleid en geen regel die elke TLS-stack identiek volgt. Beschrijf wat uw verifier doet en bevestig dat vervolgens tegen de versie die u daadwerkelijk draait.

Reproduceer de fout offline voordat u opnieuw uitgeeft

Een offline verificatie haalt de applicatie uit de vergelijking. Als de keten op dezelfde manier faalt onder hetzelfde doel, is het certificaat het probleem en verbergt geen enkele serverconfiguratie dat. Als de keten offline slaagt terwijl de dienst nog steeds weigert, vraagt de applicatie een ander doel aan of gebruikt zij een andere keten dan degene die u heeft getest.

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

-show_chain is belangrijk omdat het het pad afdrukt dat de tool heeft opgebouwd, en dat is vaak niet de bestandsvolgorde die u heeft opgegeven. Die uitvoer is de snelste manier om te ontdekken dat een tweede tussenliggend certificaat uit een vertrouwensopslag wordt gehaald, dat de server een kruisondertekende variant stuurt die u niet bedoelde, of dat de doelvlag die u uit een handleiding kopieerde bij een andere rol hoort dan degene die wordt bediend.

Corrigeer het uitgiftebeleid, niet de verificatieaanroep

De duurzame reparatie is een tussenliggend certificaat dat is uitgegeven onder een beleid dat de doelen toestaat die het moet dienen, met de beperking opgeschreven en beoordeeld. Elk doel aan elke autoriteit toevoegen is geen beleid; het verwijdert de beperking die de extensie betekenis gaf, en overleeft meestal het incident dat het veroorzaakte. Een korte notitie in het profiel die beschrijft welke rollen de autoriteit mag certificeren, voorkomt dat de volgende heruitgifte dezelfde discussie herhaalt.

Verificatie uitschakelen is de andere verleidelijke snelkoppeling, en het verandert een certificaatprobleem in een vertrouwensprobleem. Houd de doelcontrole in stand, corrigeer de keten en voer dezelfde offline verificatie opnieuw uit om te bevestigen dat het pad nu de beoogde rol dient voordat u de dienst weer aanraakt.