Behöver en iPad ett eget VPN-klientcertifikat?

En ny iPad ansluter till teamet, och den snabbaste vägen är att exportera det befintliga klientcertifikatet och installera det på surfplattan. Det fungerar tills någon slutar, tappar bort en enhet eller begär en revision som visar vilken enhet som anslöt och när. Beslutet handlar inte om certifikatfilen utan om identitet: om varje enhet kan auktoriseras och återkallas för sig själv. Kostnad och administrationsarbete avgör svaret, och båda är mindre än de ser ut.

Delad utfärdare, åtskilda identiteter

Varje enhet kan lita på samma certifikatmyndighet och ansluta till samma gateway medan den har en annan klientidentitet. Utfärdaren är ett förtroendeankare, medan identiteten är ett nyckelpar vars subjekt servern mappar till en policy. Det är sammanblandningen av de två som får ett delat certifikat att kännas ofarligt. Det förblir ofarligt bara tills någon behöver veta vilken enhet som öppnade en session.

Att dela utfärdaren sparar konfigurationsarbete och ändrar ingenting i ansvarigheten per enhet. Att dela identiteten pressar samman varje enhet till en enda återkallbar enhet: återkalla en och alla återkallas, och att auktorisera en ersättare auktoriserar varje kopia av nyckeln som någonsin skapats. Den byteshandeln är värd att göra uttryckligen i stället för att kopiera en fil för att det är snabbare en fredagseftermiddag.

När ett extra certifikat kostar för mycket

Registrering per enhet kostar ett steg: en hanterad profil, en SCEP-begäran eller en guidad import med ett engångslösenord. Det kostar också en plats att spåra serienummer och utgångsdatum, den del som de flesta utrullningar glömmer tills det första certifikatet löper ut. Båda kostnaderna är engångskostnader, och båda krymper när registreringsflödet automatiserar dem.

Kostnaden är verklig för ett hushåll med två surfplattor och en användare, där en delad identitet är ett rimligt beslut dokumenterat i en mening. Den är inte rimlig för en tjänst där åtkomst måste dras tillbaka per person eller per enhet, eftersom återkallningshistoriken är hela skälet att använda certifikat i stället för ett lösenord. Bedöm utrullningen efter hur ofta enheter byter ägare, inte efter hur många enheter som finns i dag.

Registrera enheten, kopiera inte nyckeln

Moderna plattformar förvarar privata nycklar i ett skyddat lager, och vissa markerar dem som icke-exporterbara enligt design. Den egenskapen är det som gör kopiering omöjlig från början, och det är också skälet till att ett exporterat paket från en bärbar dator inte bara kan importeras igen på en surfplatta på något stödd sätt. Försöket ger ändå en profil som installeras rent och sedan aldrig autentiserar.

Använd den registreringsmetod som utrullningen redan stöder: en hanterad identitetsprofil, en SCEP-tjänst eller ett kontobaserat flöde som utfärdar en ny nyckel på enheten. Att distribuera certifikatmyndighetens privata nyckel för att lösa en saknad identitet är ett annat misstag med en mycket större radie. Myndigheten utfärdar autentiseringsuppgifter och bör aldrig resa till slutpunkten.

Kontrollera återkallningen innan du svarar

Innan du väljer det delade alternativet, beskriv hur återkallning ser ut den värsta dagen. Om svaret är en enda åtgärd som påverkar flera enheter, har designen redan beslutat mot dig.

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

Undersök materialet du faktiskt har: om det finns en privat nyckel, vad subjektet säger och om serienumret kan återkallas individuellt. En certifikatfil utan sin nyckel kan inte autentisera något, och därför misslyckas vissa kopierade identiteter vid den första anslutningen.

Att radera en app från surfplattan är inte återkallning, och servern fortsätter att acceptera identiteten tills någon inaktiverar den. Skriv den meningen i runbooken innan den första enheten registreras.