Je geeft elk laptop een apart certificaat uit, dus je neemt aan dat de VPN ze uit elkaar kan houden. Dat kan die niet. Een cliëntcertificaat bewijst dat wie verbindt de bijpassende privésleutel heeft, en een gekopieerd profiel heeft die ook.

Het certificaat per apparaat is nog steeds een goed idee. Het doet alleen ander werk dan de meeste mensen verwachten.

Wat een cliëntcertificaat werkelijk bewijst

Tijdens de handshake ondertekent de cliënt met de privésleutel die bij zijn certificaat past, en de server verifieert die handtekening tegen de CA die hij vertrouwt. Niets in die uitwisseling beschrijft de machine. Elk apparaat met zowel het certificaat als de sleutel produceert een identieke handtekening, dus een profiel dat naar een tweede laptop is gekopieerd ziet er precies zo uit als het origineel. Het certificaat noemt een identiteit; het noemt geen hardware.

Uniciteit per apparaat loont nog steeds, omdat het intrekken nauwkeurig maakt. Het is een administratieve eigenschap, geen technisch slot.

Drie niveaus van sleutelopslag

Het eerste niveau is een sleutelbestand op schijf. Het is draagbaar van ontwerp, en daar leven de meeste OpenVPN-profielen.

Het tweede niveau is een sleutel die het besturingssysteem als niet-exporteerbaar markeert. Windows kan een apparaatsleutel in zijn certificaatarchief genereren en gewone export weigeren, wat achteloos kopiëren stopt. Hij is niet hardwarematig ondersteund, en met genoeg toegang tot de machine zijn zulke sleutels te herstellen, dus het verhoogt de inspanning in plaats van een muur te bouwen.

Het derde niveau is een sleutel die in beveiligingshardware wordt gegenereerd: een TPM, een smartcard, een simkaart of een PIV-token. Die modules hebben de circuits niet om de sleutel die ze hebben gegenereerd te exporteren, en het ondertekenen gebeurt in de module. De sleutel wordt nooit een bestand dat iemand kan kopiëren.

Where the key livesCopyableWhat it buys you
Key file inside the profileTriviallyRevocation granularity, nothing more
OS non-exportable key storeHard, not impossibleStops casual profile sharing
TPM or PIV tokenNoBinding the server can rely on

Die tabel is het hele argument in drie rijen.

Wat easy-rsa wel en niet kan

Certificaten per apparaat uitgeven is eenvoudig. Maak een aparte common name per apparaat tegen dezelfde CA, bijvoorbeeld ./easyrsa build-client-full laptop-a nopass, en herhaal dat voor elk apparaat. Leg vast welke common name bij welke persoon en machine hoort.

Intrekken is even direct: ./easyrsa revoke laptop-a, genereer de CRL opnieuw met ./easyrsa gen-crl, en zorg dat de server hem echt leest via crl-verify.

Wat de CA niet kan, is verifiëren waar de privésleutel daarna staat. Als je de sleutel op de CA-host genereert en naar het apparaat kopieert, heb je bij de uitgifte een tweede kopie gemaakt. Een niet-exporteerbare sleutel moet op het apparaat worden gegenereerd, of worden geïmporteerd in hardware die hem niet vrijgeeft.

Maatregelen die een gekopieerd profiel overleven

Ga ervan uit dat het profiel kan worden gekopieerd en ontwerp daarop. Bind het account aan een tweede factor zodat een certificaat alleen niet genoeg is. Geef elk apparaat zijn eigen beleid zodat het bereik van één identiteit beperkt blijft. En let op dezelfde common name die tegelijk vanaf twee adressen verbindt, want zo ziet een gedeeld profiel eruit in een verbindingslog.

Snel, gedocumenteerd intrekken is de maatregel die nog werkt nadat er een kopie is gemaakt. Al het andere is preventie.

De bewering waarop de server echt kan vertrouwen

Uniciteit komt van de CA. Apparaatbinding komt van sleutelopslag. Alleen hardware die zijn sleutel niet kan exporteren, maakt van één certificaat per apparaat een bewering die de server afdwingt, in plaats van een beleid waar iedereen mee instemt.

Gerelateerde artikelen