Een sertifikaat per toestel maak nie die sleutel aan die toestel gebind nie
’n Sertifikaat per toestel is ’n administrateur se keuse, nie toestelbinding nie. Wat binding bepaal, is waar die private sleutel woon, van ’n kopieerbare lêer tot ’n TPM.
Jy reik ’n aparte sertifikaat vir elke skootrekenaar uit, so jy neem aan die VPN kan hulle van mekaar onderskei. Dit kan nie. ’n Kliëntsertifikaat bewys dat wie ook al koppel die bypassende private sleutel het, en ’n gekopieerde profiel het dit ook.
Die sertifikaat per toestel is steeds ’n goeie idee. Dit doen net ’n ander werk as wat die meeste mense verwag.
Wat ’n kliëntsertifikaat werklik bewys
Tydens die handdruk onderteken die kliënt met die private sleutel wat by sy sertifikaat pas, en die bediener verifieer daardie handtekening teen die CA wat hy vertrou. Niks in daardie uitruiling beskryf die masjien nie. Enige toestel met beide die sertifikaat en die sleutel lewer ’n identiese handtekening, so ’n profiel wat na ’n tweede skootrekenaar gekopieer is lyk presies soos die oorspronklike. Die sertifikaat noem ’n identiteit; dit noem nie hardeware nie.
Uniekheid per toestel verdien steeds sy plek, want dit maak herroeping presies. Dit is ’n administratiewe eienskap, nie ’n tegniese slot nie.
Drie vlakke van sleutelberging
Die eerste vlak is ’n sleutellêer op skyf. Dit is ontwerp om draagbaar te wees, en dit is waar die meeste OpenVPN-profiele woon.
Die tweede vlak is ’n sleutel wat die bedryfstelsel as nie-uitvoerbaar merk. Windows kan ’n toestelsleutel in sy sertifikaatstoord genereer en gewone uitvoer weier, wat toevallige kopiëring stop. Dit is nie deur hardeware gerugsteun nie, en met genoeg toegang tot die masjien kan sulke sleutels herwin word, so dit verhoog die moeite eerder as om ’n muur te bou.
Die derde vlak is ’n sleutel wat binne sekuriteitshardeware gegenereer word: ’n TPM, ’n slimkaart, ’n SIM of ’n PIV-token. Daardie modules het nie die stroombaan om die sleutel wat hulle geskep het uit te voer nie, en ondertekening gebeur binne die module. Die sleutel word nooit ’n lêer wat iemand kan kopieer nie.
| Where the key lives | Copyable | What it buys you |
|---|---|---|
| Key file inside the profile | Trivially | Revocation granularity, nothing more |
| OS non-exportable key store | Hard, not impossible | Stops casual profile sharing |
| TPM or PIV token | No | Binding the server can rely on |
Daardie tabel is die hele argument in drie rye.
Wat easy-rsa kan doen en wat nie
Om sertifikate per toestel uit te reik is eenvoudig. Skep ’n afsonderlike algemene naam per toestel teen dieselfde CA, byvoorbeeld ./easyrsa build-client-full laptop-a nopass, en herhaal dit vir elke toestel. Teken aan watter algemene naam aan watter persoon en masjien behoort.
Herroeping is ewe direk: ./easyrsa revoke laptop-a, genereer die CRL weer met ./easyrsa gen-crl, en maak seker die bediener lees dit werklik deur crl-verify.
Wat die CA nie kan doen nie, is om te verifieer waar die private sleutel daarna woon. As jy die sleutel op die CA-gasheer genereer en dit na die toestel kopieer, het jy by uitreiking ’n tweede kopie geskep. ’n Nie-uitvoerbare sleutel moet op die toestel gegenereer word, of in hardeware ingevoer word wat dit nie sal vrystel nie.
Beheermaatreëls wat ’n gekopieerde profiel oorleef
Aanvaar dat die profiel gekopieer kan word en ontwerp daarom. Bind die rekening aan ’n tweede faktor sodat ’n sertifikaat alleen nie genoeg is nie. Gee elke toestel sy eie beleid sodat een identiteit se bereik beperk bly. En let op dieselfde algemene naam wat van twee adresse gelyktydig koppel, want dit is hoe ’n gedeelde profiel in ’n verbindingslog lyk.
Vinnige, gedokumenteerde herroeping is die beheermaatreël wat steeds werk nadat ’n kopie gemaak is. Al die res is voorkoming.
Die bewering waarop die bediener werklik kan staatmaak
Uniekheid kom van die CA. Toestelbinding kom van sleutelberging. Net hardeware wat nie sy sleutel kan uitvoer nie, maak van een sertifikaat per toestel ’n stelling wat die bediener afdwing, eerder as ’n beleid wat almal instem om te volg.