nem támogatott tanúsítványcél: miért bukik el a köztes CA

A kiszolgálótanúsítvány célja helyesnek tűnik, a kulcs illeszkedik, a dátumok rendben vannak, és a kapcsolat mégis unsupported certificate purpose hibával meghiúsul. A megoldást adó részlet általában ugyanabban a sorban van, mint a hiba: egy mélységérték és egy subject, amelyek a láncban feljebb lévő tanúsítványt neveznek meg. Két különböző vizsgálat fut, és csak az egyik szól a levélről. Összehasonlításuk megmagyarázza, miért nem változtat semmit a kiszolgálótanúsítvány cseréje.

Melyik tanúsítványt utasította el valójában az ellenőrző

A lánc nem egy háromszor megismételt objektum. A levél hordozza a kiszolgáló nevét és kulcsát, a köztes tanúsítványok egy gyökérhez kapcsolják, és mindegyiknek saját érvényességi ideje, megkötései és felhasználásai vannak. Amikor a hiba mélységet nevez meg, az a szám a láncban egy pozíciót azonosít, amelyet az ellenőrző épített, és ez nem feltétlenül az a pozíció, amelyre számít, ha a kiszolgáló váratlan láncot küld.

Az adott mélységű tanúsítvány mezőit olvassa, ne azt, amelyet bűnösnek feltételezett. Kérje le a kiadást korlátozó két kiterjesztést, ahelyett hogy minden mezőt kiírna, mert a válasz szinte mindig valamelyikben van. A kiterjesztések kimenete megosztható; a privát kulcsok soha.

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

Ha a megnevezett tanúsítvány olyan köztes, amelynek kiterjesztett kulcshasználata a TLS-kiszolgáló-hitelesítéshez nem kapcsolódó dolgot említ, a hiba többi része mechanikusan következik. A lánc nem használható arra a célra, amelyet OpenVPN kért.

A levél célja és a lánc szabályzata két vizsgálat

A levélvizsgálat szűk kérdést tesz fel: engedélyezi ez a végponti tanúsítvány a kiszolgáló-hitelesítést ehhez a névhez? A láncvizsgálat szélesebbet: szolgálhatja-e az útvonal minden tanúsítványa ezt a célt? Egy olyan tanúsító hatóság, amely csak kliens-tanúsítványokat adhat ki, átmegy a saját aláírás-ellenőrzésein, és mégis elbukik a második vizsgálaton, mert az általa engedélyezett útvonal nem tartalmazza az alkalmazás által igényelt célt. A két vizsgálat ugyanazokkal a szavakkal bukik el, és teljesen eltérő javításokat igényel.

Ezért bukhat el azonnal egy frissen kiadott levél, amely minden látható mezőjében helyes. Ezért tartozik a javítás általában a kiadó hatóság profiljához, nem a VPN konfigurációjához.

A hiányzó EKU nem korlátozó EKU

Az RFC 5280 a kiterjesztett kulcshasználat kiterjesztést választhatóvá teszi, és ha jelen van, korlátozóvá. A kiterjesztés nélküli CA-tanúsítvány tehát nem mondott „nem”-et a kiszolgáló-hitelesítésre, míg az, amely csak egy nem kapcsolódó célt sorol fel, valami nagyon konkrétat mondott. E két állapot egyenértékűként kezelése rossz diagnózishoz és, ami rosszabb, rossz javításhoz vezet. A különbség azt is megmagyarázza, miért viselkedik két, a konzolon hasonlónak tűnő hatóság teljesen másként egy láncban.

A könyvtárak viselkedése itt sem egységes. az OpenSSL dokumentuma az ellenőrzési lehetőségekről leírja a saját kezelését a CA-tanúsítványok célvizsgálataira, és ez a kezelés megvalósítási szabályzat, nem pedig minden TLS-verem által azonosan követett szabály. Írja le, mit tesz az ellenőrzője, majd erősítse meg a ténylegesen futtatott verzióval.

Reprodukálja a hibát offline, mielőtt újra kiad

Az offline ellenőrzés kiveszi az alkalmazást a kérdésből. Ha a lánc ugyanúgy bukik el ugyanazon cél mellett, a tanúsítvány a probléma, és semmilyen kiszolgálókonfiguráció nem rejti el. Ha a lánc offline átmegy, miközben a szolgáltatás továbbra is elutasít, az alkalmazás más célt kér, vagy más láncot használ, mint amelyet tesztelt.

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

-show_chain azért számít, mert kiírja az eszköz által épített útvonalat, amely gyakran nem az Ön által megadott fájlsorrend. Ez a kimenet a leggyorsabb módja annak felfedezésére, hogy egy második köztes tanúsítvány egy bizalmi tárból kerül elő, hogy a kiszolgáló egy nem szándékolt kereszt-aláírt változatot küld, vagy hogy a bemutatóanyagból másolt céljelző más szerephez tartozik, mint a kiszolgált.

A kiadási szabályzatot javítsa, ne az ellenőrző hívást

A tartós javítás egy olyan köztes tanúsítvány, amely olyan szabályzat alatt készült, amely engedélyezi a szolgálandó célokat, és a megkötés le van írva és át van nézve. Minden célt minden hatósághoz hozzáadni nem szabályzat; eltávolítja azt a megkötést, amely értelmet adott a kiterjesztésnek, és általában túléli az azt kiváltó incidenst. Egy rövid megjegyzés a profilban arról, hogy a hatóság mely szerepeket tanúsíthatja, megakadályozza, hogy a következő újrakiadás ugyanazt a vitát ismételje.

Az ellenőrzés kikapcsolása a másik csábító rövidítés, és a tanúsítványproblémát bizalmi problémává alakítja. Tartsa meg a célvizsgálatot, javítsa a láncot, és futtassa újra ugyanazt az offline ellenőrzést annak megerősítésére, hogy az útvonal most a szándékolt szerepet szolgálja, mielőtt újra hozzányúl a szolgáltatáshoz.