Zelfondertekend clientcertificaat? De VPN-server weigert het nog steeds

De operator stuurt een adres en een gebruikersnaam, en de client vraagt om een CA-bestand, een certificaat en een sleutel. Die drie lokaal genereren voelt als de voor de hand liggende volgende stap. Het levert een certificaat op waar alleen uw eigen machine in gelooft. Het vertrouwen van de server is verankerd in een CA die u niet beheert, dus de handshake eindigt voordat hij begint.

Vertrouwen woont op de server, niet in uw profiel

Certificaatauthenticatie is een vergelijking. De client toont een certificaat; de gateway controleert of het is ondertekend door een van de CA's in zijn configuratie.

Uw profiel noemt het CA-bestand dat de client moet gebruiken om de server te verifiëren. Het kan geen CA noemen die de server moet gebruiken om u te verifiëren. Die helft van de configuratie is niet van u.

Een zelfgemaakt certificaat faalt voor deze vergelijking, zelfs wanneer het technisch perfect is. Het heeft een geldige handtekening, een subject en datums, maar de uitgever is een CA waar de gateway nooit van heeft gehoord. De fout verschijnt tijdens de handshake, nadat de server al om een certificaat heeft gevraagd. Niets in het clientprofiel kan het antwoord veranderen.

Waarom een zelfondertekend certificaat het niet kan vervangen

Een zelfondertekend certificaat is ondertekend met zijn eigen sleutel. De handtekening verifieert tegen hetzelfde bestand, wat het zelfconsistent en nutteloos maakt als referentie voor andermans gateway.

De gateway vraagt niet of het certificaat intern consistent is. Hij vraagt of een vertrouwde uitgever het heeft ondertekend.

Daarom zijn de foutmeldingen verwarrend. De client kan een verificatiefout melden die klinkt als een serverprobleem, terwijl de server een onbekende uitgever logt. Beide beschrijven dezelfde mismatch vanaf tegenovergestelde uiteinden.

Het CSR-pad bewaart uw privésleutel

U kunt het meeste werk nog lokaal doen. Genereer een sleutelpaar, bouw een aanvraag voor certificaatondertekening rond de openbare helft en stuur die aanvraag naar de operator. Alleen de aanvraag verlaat uw machine. De privéhelft blijft waar u hem hebt gegenereerd.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

De operator ondertekent de aanvraag met zijn CA en stuurt een certificaat terug. Uw privésleutel heeft nooit gereisd, en het resultaat ketent naar het anker dat de gateway vertrouwt.

Beheerde diensten slaan de CSR vaak over en geven de hele bundel uit. Dat is een redelijke ruil wanneer dezelfde provider de tunnel al beëindigt en de CA bezit. De bewaring van de sleutel wordt niet beter door hem te houden, want de provider kan op elk moment een nieuwe maken.

Bundels worden geïmporteerd, niet geïnstalleerd

Leveranciersbundels met veilig klinkende namen zijn vaak OpenVPN-profielen. Ze bevatten configuratie en soms certificaten, en ze installeren niets. Importeer het bestand in een client die het protocol spreekt, en de verbinding is geconfigureerd.

De behandelingsregel volgt uit de inhoud. Als het profiel een privésleutel insluit, is het een referentie en verdient het dezelfde zorg als een wachtwoord: geen e-mail, geen repository, geen gedeelde downloadmap. Wanneer de operator ca.crt, client.crt en client.key apart levert, bewaar ze dan samen met beperkte rechten en wijs het profiel erop.

Voeg de controles toe die de operator mogelijk heeft overgeslagen

Een door de router gegenereerd profiel mist soms peer-verificatie. remote-cert-tls server vereist dat het peercertificaat het doel serverauthenticatie draagt, zodat een clientcertificaat niet als server kan worden herspeeld. Die ene regel is een kleine wijziging met een duidelijke rechtvaardiging.

verify-x509-name gaat verder wanneer de operator het verwachte subject of de SAN kan noemen. Beide zijn kleine toevoegingen aan een profiel, en beide zijn verdedigbaar. Inspecteer wat u hebt ontvangen voordat u het importeert.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Verificatie-instellingen zijn geen reparatie van een gebroken keten. Als de uitgever verkeerd is, is het antwoord een certificaat van de juiste CA, niet een vlag die de controle uitzet. Verificatie uitzetten maakt van een authenticatiefout een onontdekte fout.

Vraag om één bundel: het certificaat van de autoriteit als PEM, een clientcertificaat dat die autoriteit heeft ondertekend, een sleutel die u zelf hebt gegenereerd of die via een kanaal kwam dat u vertrouwt, en de exacte servernaam die het certificaat moet presenteren. Noteer de vervaldatum in hetzelfde bericht, want een verlopen certificaat lijkt maanden later op een netwerkstoring.