Hoe u een VPN-clientsleutel genereert en een CSR ter ondertekening indient

Vroeg of laat biedt een VPN-gebruiker aan een privésleutel per e-mail te sturen zodat de beheerder een certificaat kan maken, en juist dat aanbod moet je weigeren. De werkende stroom houdt de sleutel vanaf het eerste commando bij de client: de client genereert hem, stuurt een certificaatondertekeningsverzoek, de uitgever verifieert en autoriseert het, en het ondertekende certificaat komt terug om naast de sleutel te staan die het heeft gemaakt. De checklist hieronder faalt gesloten bij elke stap, en dat is het punt, want twee van de vijf stappen zijn precies degene die mensen overslaan als ze haast hebben.

Stap 1: genereer de sleutel waar hij zal leven

Genereer op de machine die de sleutel gaat houden, en laat hem daar. Een softwaresleutel belandt in een bestand met strikte rechten; een hardwaresleutel of een sleutel in een beheerde opslag wordt nooit een bestand, en het registratiepad is meestal een apart hulpprogramma in plaats van een OpenSSL-commando. Hoe dan ook, niemand hoeft de private helft te zien.

De softwarestroom ziet er zo uit, waarbij de sleutel en het verzoek in één sessie worden gemaakt:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

De regel umask is belangrijker dan hij lijkt. Zonder die regel wordt de sleutel op een standaard toestemmend systeem wereldleesbaar geschreven, en het later rondkopiëren van het bestand verspreidt dat. Een bestaande sleutel hergebruiken is legitiem wanneer hij al beschermd is en bij uw beleid past; per apparaat een nieuwe genereren is makkelijker te verantwoorden.

Stap 2: zet de identiteit in het verzoek, niet in de e-mail

Bepaal wat de VPN werkelijk authenticeert voordat het verzoek wordt gemaakt, want dat antwoord hoort binnen de CSR. OpenVPN koppelt van oudsher de clientidentiteit aan de common name van het certificaat, en hulpmiddelen zoals strongSwan vergelijken een identiteitsreeks met het subject of een alternatieve subjectnaam. Een e-mail die zegt dat ik alice heet is geen bewijs, en een verzoek waarvan het subject hetzelfde zegt is slechts iets beter.

Voeg een alternatieve subjectnaam toe wanneer uw verifieerder er een controleert, omdat moderne vergelijking de oude CN vaak negeert:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

Houd de CN kort, stabiel en aan het account gebonden in plaats van aan een laptopmodel. Een naam met het serienummer van het apparaat van de gebruiker is een supportprobleem dat wacht op de eerste hardwarevervanging.

Stap 3: verifieer het verzoek voordat u het ondertekent

De uitgever verifieert twee verschillende dingen, en ze door elkaar halen is de klassieke fout. Ten eerste dat het verzoek intern consistent is: de handtekening wordt geverifieerd tegen de publieke sleutel die het draagt. Ten tweede dat de aanvrager recht heeft op wat het verzoek vraagt, en daar kan geen enkele cryptografische controle antwoord op geven.

Het mechanische deel is één commando, en het zou een verificatieresultaat samen met het subject moeten afdrukken:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

Let op wat dat bewijst. Een verzoek dat verifieert toont alleen dat de afzender op het moment van indienen de bijbehorende privésleutel had; het bewijst niet dat de afzender de persoon is die in het subject wordt genoemd, en het autoriseert de gevraagde groep- of routetoegang niet. Inschrijvingsbeoordeling is een aparte poort, en een verzoek voor een groep die niemand heeft goedgekeurd zou moeten worden afgewezen in plaats van stil te worden bewerkt.

Stap 4: autoriseer en onderteken dan met expliciete extensies

Ondertekenen is waar de CA beleid bepaalt in plaats van het verzoek letterlijk over te nemen. Geldigheid, sleutelgebruik en de roluitbreiding horen in een extensiebestand, niet in standaardwaarden die u zes maanden later niet meer herinnert. Een clientcertificaat voor VPN-authenticatie heeft clientauthenticatie als doel nodig.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

Gebruik -CAserial met het bestaande serienummerbestand als er al een in gebruik is, en houd de CA-sleutel offline of in de beschermde opslag die uw beleid noemt. Serienummers van certificaten moeten uniek zijn per uitgever; het serienummerbestand vanaf nul opnieuw maken riskeert botsingen die intrekking dubbelzinnig maken.

Leg vast wat is uitgegeven: serienummer, subject, gevraagde identiteit, goedkeurende persoon en vervaldatum. Die registratie is waarop een intrekkingsbeslissing later steunt, en hij kan niet alleen uit het certificaat worden gereconstrueerd als het inschrijvingsspoor alleen in een postbus leeft.

Stap 5: installeer het naast de bijbehorende sleutel en bewijs het paar

De client ontvangt het certificaat en de keten van de uitgever, nooit een sleutel. Bevestig voor het verbinden dat het certificaat echt paart met de sleutel die al op schijf staat, want een niet-passend paar levert veel later een verwarrende handshake-fout op:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

De twee digests moeten overeenkomen. Verbind daarna en bevestig dat de identiteit die de server logt de door u geautoriseerde is, en niet alleen dat de tunnel omhoog kwam. Als de sleutel verloren gaat of het apparaat wordt vervangen, is het antwoord intrekking plus een nieuw verzoek vanaf het nieuwe apparaat; de beheerder vragen een sleutel van elders terug te sturen herstelt het origineel niet en breekt stil het model dat het verzoek veilig maakte.