Um iPad precisa do seu próprio certificado de cliente VPN?

Um novo iPad entra na equipe, e o caminho mais rápido é exportar o certificado de cliente existente e instalá-lo no tablet. Isso funciona até alguém sair, perder um dispositivo ou pedir uma auditoria que mostre qual dispositivo se conectou e quando. A decisão não é sobre o arquivo do certificado, mas sobre identidade: se cada dispositivo pode ser autorizado e revogado por conta própria. Custo e esforço de gestão decidem a resposta, e ambos são menores do que parecem.

Emissor compartilhado, identidades separadas

Cada dispositivo pode confiar na mesma autoridade de certificação e conectar-se ao mesmo gateway enquanto mantém uma identidade de cliente diferente. O emissor é uma âncora de confiança, enquanto a identidade é um par de chaves cujo sujeito o servidor mapeia para uma política. Confundir os dois é o que faz um certificado compartilhado parecer inofensivo. Ele só permanece inofensivo até alguém precisar saber qual dispositivo abriu uma sessão.

Compartilhar o emissor economiza trabalho de configuração e não muda nada na responsabilização por dispositivo. Compartilhar a identidade colapsa cada dispositivo em uma única unidade revogável: revogar um revoga todos, e autorizar um substituto autoriza cada cópia da chave já feita. Essa troca vale a pena ser feita explicitamente em vez de copiar um arquivo porque é mais rápido numa sexta-feira à tarde.

Quando um segundo certificado custa caro demais

O registro por dispositivo custa um passo: um payload gerenciado, uma solicitação SCEP ou uma importação guiada com senha de uso único. Também custa um lugar para acompanhar números de série e datas de validade, a parte que a maioria das implantações esquece até o primeiro certificado expirar. Ambos os custos são únicos, e ambos diminuem assim que o fluxo de registro os automatiza.

O custo é real para uma casa com dois tablets e um único usuário, onde uma identidade compartilhada é uma decisão razoável documentada em uma frase. Não é razoável para um serviço onde o acesso precisa ser retirado por pessoa ou por dispositivo, porque a história da revogação é toda a razão para usar certificados em vez de uma senha. Julgue a implantação pela frequência com que os dispositivos trocam de mãos, não por quantos dispositivos existem hoje.

Registre o dispositivo, não copie a chave

Plataformas modernas guardam chaves privadas em um armazenamento protegido, e algumas as marcam como não exportáveis por design. É essa propriedade que torna a cópia impossível desde o início, e é também por isso que um pacote exportado de um notebook não pode simplesmente ser reimportado em um tablet de nenhuma forma suportada. Tentar mesmo assim produz um perfil que se instala limpo e depois nunca autentica.

Use o método de registro que a implantação já suporta: um payload de identidade gerenciado, um serviço SCEP ou um fluxo baseado em conta que emite uma nova chave no dispositivo. Distribuir a chave privada da autoridade de certificação para resolver uma identidade ausente é outro erro com um raio de impacto muito maior. A autoridade emite credenciais e nunca deveria viajar até o endpoint.

Verifique a revogação antes de responder

Antes de escolher a opção compartilhada, descreva como é a revogação no pior dia. Se a resposta for uma única ação que afeta vários dispositivos, o design já decidiu contra você.

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 você realmente tem: se há uma chave privada, o que o sujeito diz e se o número de série pode ser revogado individualmente. Um arquivo de certificado sem a sua chave não pode autenticar nada, e é por isso que algumas identidades copiadas falham na primeira conexão.

Apagar um aplicativo do tablet não é revogação, e o servidor continua aceitando a identidade até alguém desativá-la. Escreva essa frase no runbook antes de o primeiro dispositivo ser registrado.