remote-cert-tls server: wat de richtlijn in een OpenVPN-profiel controleert

Drie verschillende vragen worden beantwoord door drie verschillende delen van een OpenVPN-profiel, en het samenvoegen daarvan is hoe mensen uiteindelijk een controle uitschakelen die werkte. Is het certificaat van de tegenpartij ondertekend door de autoriteit die ik vertrouw? Declareert dat certificaat de TLS-serverrol? Is het precies de server die ik wilde bereiken? remote-cert-tls server beantwoordt alleen de middelste vraag, en doet dat door extensies in het certificaat te lezen.

Drie controles die je gemakkelijk in je hoofd samenvoegt

Het vertrouwensanker zit in de richtlijn ca. De rolcontrole hoort bij remote-cert-tls. De identiteitscontrole hoort bij verify-x509-name, wanneer een profiel die gebruikt, of bij welke naamcontrole de uitrol dan ook toevoegt.

Ze dekken verschillende fouten:

Een profiel kan alle drie hebben en toch zwak zijn als de CA te breed wordt gedeeld, wat een kwestie van sleutelbeheer is en niet van richtlijnen.

Wat de rolcontrole leest

De richtlijn is een macro. Ze breidt uit naar een eis voor sleutelgebruik en een eis voor uitgebreid sleutelgebruik die de TLS-webserverrol noemt, dus het certificaat van de tegenpartij moet dat doel daadwerkelijk declareren. Een certificaat dat is uitgegeven voor clientauthenticatie voldoet daar niet aan, zelfs wanneer dezelfde autoriteit beide heeft ondertekend.

Dat is belangrijk omdat een gedeelde CA gebruikelijk is in kleine uitrollingen. Eén autoriteit ondertekent elke client en de server, en zonder rolcontrole zou elk van die certificaten de serverszijde van de handdruk kunnen voltooien. De controle maakt dat scenario niet onmogelijk, maar verwijdert de triviale versie ervan.

De richtlijn is bewust asymmetrisch: clients dragen remote-cert-tls server, en servers dragen remote-cert-tls client. Wissel ze om en elke verbinding mislukt met een rolfout die op een kapot certificaat lijkt.

Oudere profielen gebruiken soms ns-cert-type voor hetzelfde doel. Huidige manpages beschouwen die optie als vervangen, dus een profiel dat er nog op vertrouwt, is het waard om te migreren in plaats van te debuggen.

Waarom het uitschakelen als een oplossing voelt

Wanneer de rolcontrole mislukt, stopt de verbinding met een verificatiefout en de voor de hand liggende stap is de regel verwijderen. De verbinding komt dan op, wat als vooruitgang voelt en eigenlijk de faalmodus is die de richtlijn bestaat om te voorkomen. U accepteert nu een tegenpartij wiens certificaat nooit voor die rol bedoeld was.

Lees in plaats daarvan de fout. Die noemt de controle die mislukte, en het certificaat aan de andere kant kan worden onderzocht om te zien welke extensies het werkelijk draagt. Twee minuten lezen beslist of de fout in de uitgifte of in de configuratie zit. Gissen kost een middag en eindigt meestal met een verzwakt profiel. Een vernieuwd servercertificaat dat zijn uitgebreide sleutelgebruik kwijt is, is een echte fout in de vernieuwing, geen reden om de client te verslappen.

De naamcontrole is een aparte richtlijn

Voldoen aan de rolcontrole zegt dat de tegenpartij een of andere server is die door uw autoriteit is ondertekend. Het zegt niets over welke, wat uitmaakt wanneer dezelfde CA certificaten uitgeeft voor meerdere gateways en een ervan is gecompromitteerd of hergebruikt.

verify-x509-name vergelijkt het onderwerp van het certificaat met een waarde die u configureert, met overeenkomstenmodi voor een exact onderwerp, een voorvoegsel of één veld. Gebruik het veld dat de gateway werkelijk identificeert, en verwacht het bewust bij te werken wanneer de naam verandert.

Geen van beide richtlijnen vervangt goed sleutelbeheer. Als het clientsleutelbestand samen met het profiel rond wordt gekopieerd, is de identiteit van de tegenpartij slechts zo sterk als de distributielijst.

Inspecteer het certificaat voordat u het profiel bewerkt

Lees het certificaat van de tegenpartij en de clientlog, in die volgorde. Het certificaat vertelt welke rollen het declareert; de log vertelt welke controle het heeft afgewezen.

Deze opdrachten drukken de gebruiksextensies en de verificatieregels van een uitgebreide verbinding af:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

Als de extensies de serverrol tonen en de log nog steeds een rolfout meldt, wijst het profiel waarschijnlijk op het verkeerde certificaatbestand in plaats van op een slecht certificaat. Als de extensies alleen clientauthenticatie tonen, stop dan met naar de client te kijken en herstel de uitgifte. Herstel in ieder geval de controle voordat u de verbinding gezond noemt, want een geslaagde handdruk na het verwijderen van verificatie bewijst minder dan de fout die hij verving.