Een VPN-client toevoegen zonder de CA opnieuw op te bouwen

Je hebt nog een certificaat nodig voor nog een laptop, maar de eerste tutorial in de zoekresultaten begint met een commando dat de PKI-map wist. Dat commando hoort bij de eerste installatie, niet bij inschrijving, en het uitvoeren kost je de CA, de uitgiftegeschiedenis en elk clientprofiel dat de oude uitgever vertrouwde. De beslissing is smaller: heeft je uitgever nog bruikbare staat, en past het nieuwe apparaat in je inschrijvingsbeleid? Drie voorwaarden beslissen, slechts één rechtvaardigt een herbouw.

Wat een herbouw werkelijk vernietigt

Een PKI opnieuw initialiseren vervangt de map door een lege structuur: nieuwe CA-sleutel en certificaat, lege uitgiftedatabase, nieuwe serienummerteller. Clients volgen niet vanzelf; hun profielen pinnen de oude CA, dus elk bestaand apparaat moet opnieuw inschrijven, en onbereikbare apparaten met de hand.

Het stilste verlies is de boekhouding. Intrekken hangt af van weten welke serienummers je aan wie hebt uitgegeven. Wis de index en je kunt nog tekenen, maar niet meer met zekerheid zeggen welke van de openstaande certificaten je wilde intrekken. Een CA-map met certificaten zonder de bijbehorende uitgeverstaat is een back-up die de verkeerde helft van het systeem herstelt.

De privésleutel van de CA naast de draaiende server kopiëren is de andere sluiproute die je moet weigeren: het maakt van een ondertekeningsautoriteit die offline hoort te staan nog een bestand op een host met onbetrouwbaar verkeer.

Eerste voorwaarde: is de staat van de uitgever nog bereikbaar?

Zoek eerst de map die de server werkelijk vertrouwt. Vergelijk het certificaat dat de server als CA presenteert met dat in je PKI-map op vingerafdruk, niet op bestandsnaam:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

Komen de vingerafdrukken overeen, dan is inschrijving incrementeel en bouw je niets opnieuw. Verschillen ze, dan teken je met een CA die de server niet vertrouwt: het certificaat installeert schoon en faalt bij de handshake, en die fout wordt urenlang verkeerd gediagnosticeerd als een clientfout.

Zoek daarna de uitgiftestaat: het indexbestand, de serieteller en het bestand met het CRL-nummer. Ontbreekt de index maar leeft de sleutel, dan kun je uitgeven, maar erft een probleem met het vastleggen van intrekkingen. Noteer dat in het wijzigingslogboek, want de volgende intrekkingsaanvraag zal het blootleggen.

Tweede voorwaarde: wie beheert de nieuwe privésleutel?

Dit is de beslissing die gebruikers voelen, dus neem hem expliciet. Een op de client gegenereerde sleutel die als aanvraag wordt ingediend, houdt de private helft vanaf het eerste commando op het apparaat, en de beheerder raakt hem nooit aan. Een op de server gegenereerde sleutel is eenvoudiger voor apparaten zonder gereedschap, maar maakt de beheerder hoeder van elke sleutel en vergroot de impact van een servercompromis.

Met Easy-RSA 3 tegen een bestaande CA zijn importeren en ondertekenen van een aanvraag twee commando’s:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Kies het certificaattype bewust. Een aanvraag die als servercertificaat in plaats van clientcertificaat wordt ondertekend, levert een bestand dat er goed uitziet en door de tegenpartij wordt geweigerd, en de foutmelding zegt zelden waarom. Bij openssl ca zit dezelfde keuze in de extensies die je meegeeft, niet in de standaardsectie.

Derde voorwaarde: heeft de server meer nodig dan een certificaat?

Voor een gewone OpenVPN-server met certificaatauthenticatie is het certificaat de inschrijving: de common name wordt de clientidentiteit, en elke clientmap, gepushte route of statisch adres hangt aan die naam. Voeg het certificaat toe en vergeet de configuratie: de tunnel verbindt, maar de benodigde routes verschijnen nooit.

Platforms veranderen dit. OpenVPN Access Server houdt een eigen gebruikersdatabase bij, dus een ondertekend certificaat is geen account; het account moet bestaan en toegestaan zijn. Andere gateways koppelen een identiteitsreeks aan een groep. Eén apparaat inschrijven raakt meestal twee systemen, en het certificaat is slechts de eerste.

De incrementele procedure en wanneer een herbouw juist is

De volgorde die één apparaat zonder schade toevoegt: bevestig de uitgever op vingerafdruk, maak een verse kopie van de PKI-map, importeer en onderteken de aanvraag voor de clientrol, lever het certificaat met zijn keten via het goedgekeurde kanaal, en verifieer voordat de gebruiker verbindt:

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

De doellijn hoort SSL client te tonen. Sluit af met het bijwerken van de CA-kopie na de uitgifte, want een kopie van voor het nieuwe serienummer herstelt een toestand zonder het apparaat dat je net hebt toegevoegd.

Een herbouw is juist in drie gevallen: de CA-sleutel is gecompromitteerd, de uitgiftestaat is onherstelbaar verloren, of je wijzigt bewust het sleutelalgoritme of het certificaatbeleid. Alle drie zijn projecten met een herinschrijvingsplan voor elke client, geen stappen in een aanvraag voor één apparaat. Geldt geen van deze, schrijf dan incrementeel in en laat de uitgever met rust.