Precisa un iPad o seu propio certificado de cliente VPN?

Un iPad novo súmase ao equipo, e o camiño máis rápido é exportar o certificado de cliente existente e instalalo na tableta. Iso funciona ata que alguén marcha, perde un dispositivo ou pide unha auditoría que diga que dispositivo se conectou e cando. A decisión non trata do ficheiro do certificado senón da identidade: se cada dispositivo pode autorizarse e revogarse por separado. O custo e o esforzo de xestión deciden a resposta, e ambos son menores do que parecen.

Emisor compartido, identidades separadas

Cada dispositivo pode confiar na mesma autoridade de certificación e conectarse á mesma pasarela mentres posúe unha identidade de cliente distinta. O emisor é unha áncora de confianza, mentres que a identidade é un par de claves cuxo suxeito o servidor asigna a unha política. Confundir ambas é o que fai que un certificado compartido pareza inofensivo. Só segue sendo inofensivo ata que alguén necesita saber que dispositivo abriu unha sesión.

Compartir o emisor aforra traballo de configuración e non cambia nada na responsabilidade por dispositivo. Compartir a identidade colapsa cada dispositivo nunha soa unidade revogable: revogar un revoga todos, e autorizar un substituto autoriza cada copia da clave que se fixera. Ese intercambio merece facerse explícito en lugar de copiar un ficheiro porque é máis rápido un venres pola tarde.

Cando un segundo certificado custa demasiado

O rexistro por dispositivo custa un paso: unha carga xestionada, unha solicitude SCEP ou unha importación guiada cun contrasinal dun só uso. Tamén custa un lugar onde seguir os números de serie e as datas de caducidade, a parte que a maioría dos despregamentos esquecen ata que caduca o primeiro certificado. Ambos custos son únicos, e ambos diminúen en canto o fluxo de rexistro os automatiza.

O custo é real para un fogar con dúas tabletas e un só usuario, onde unha identidade compartida é unha decisión razoable documentada nunha frase. Non é razoable para un servizo onde o acceso debe retirarse por persoa ou por dispositivo, porque a historia da revogación é toda a razón para usar certificados en lugar dun contrasinal. Xulgue o despregamento pola frecuencia con que os dispositivos cambian de mans, non por cantos dispositivos existen hoxe.

Inscriba o dispositivo, non copie a clave

As plataformas modernas gardan as claves privadas nun almacén protexido, e algunhas márcanas como non exportables por deseño. Esa propiedade é o que fai imposible copialas de entrada, e tamén é a razón pola que un paquete exportado dun portátil non se pode reimportar sen máis nunha tableta de ningún xeito admitido. Intentalo aínda así produce un perfil que se instala limpiamente e logo nunca autentica.

Use o método de rexistro que o despregamento xa admite: unha carga de identidade xestionada, un servizo SCEP ou un fluxo baseado en conta que emita unha clave nova no dispositivo. Distribuír a clave privada da autoridade de certificación para resolver unha identidade ausente é outro erro cun raio de impacto moito maior. A autoridade emite credenciais e nunca debería viaxar ao punto final.

Comprobe a revogación antes de responder

Antes de escoller a opción compartida, describa como é a revogación o peor día. Se a resposta é unha acción que afecta varios dispositivos, o deseño xa decidiu en contra súa.

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

Examine o material que realmente ten: se hai unha clave privada, que di o suxeito e se o número de serie pode revogarse individualmente. Un ficheiro de certificado sen a súa clave non pode autenticar nada, e por iso algunhas identidades copiadas fallan na primeira conexión.

Borrar unha aplicación da tableta non é revogación, e o servidor segue aceptando a identidade ata que alguén a desactive. Escriba esa frase no runbook antes de inscribir o primeiro dispositivo.