AWS Client VPN: que CA debe emitir os certificados de cliente?
Unha CA existente, un emisor propio e AWS Private CA reparten o traballo de forma distinta. Decida quen aproba, renova e revoga os certificados de cliente antes do lanzamento.
A pregunta sobre os certificados en AWS Client VPN exponse como unha pregunta de produto, e en realidade é unha pregunta de operacións. Calquera das tres configuracións habituais manterá un túnel funcionando: unha CA organizativa existente, un emisor propio dedicado ou AWS Private CA. Diferéncianse en quen aproba un dispositivo, quen garda a clave de sinatura e quen responde cando un portátil desaparece a unha hora incómoda. Escolla a opción cuxo responsable poida nomear.
AWS non require Private CA para a autenticación con certificados. Colocar un certificado de servidor en ACM é un paso de despregamento, non un proceso de inscrición.
As tres condicións que o deciden
Tres condicións separan as opcións con claridade: se xa existe un proceso aprobado de inscrición de dispositivos, se pode operar unha clave de sinatura con copias de seguridade e un responsable nomeado, e como chega unha revogación ao punto de conexión. Cada unha está preto dun si ou un non, e o primeiro non adoita decidir a arquitectura.
Trábeas en orde. Saltar directamente a unha comparación de custos é como os equipos acaban cunha CA xestionada e ninguén que saiba quen emite o seguinte certificado de portátil.
| Option | You still own | Fits when |
|---|---|---|
| Existing organizational CA | Enrollment, approvals, revocation list | A device process already exists |
| Self-run issuer | Signing-key custody, backups, revocation list | You can staff key custody |
| AWS Private CA | Policy, permissions, certificate delivery | Your PKI already lives in AWS |
Condición primeira: xa existe a inscrición?
Se a súa organización xa opera unha CA cunha ruta aprobada de inscrición de dispositivos, emitir desde ela os certificados de cliente de Client VPN é a ruta máis curta. As aprobacións, o proceso e os rexistros de activos xa están alí. Un emisor subordinado dedicado dentro desa xerarquía adoita ser mellor que a CA emisora de propósito xeral, porque lle dá á VPN a súa propia fronteira de confianza e a súa propia lista de revogación. Manteña esa lista separada do resto da xerarquía para que un incidente de VPN non obrigue a un cambio en todo o PKI.
Se non existe tal proceso, a verdadeira pregunta é se quere construír un. Unha CA é fácil de comezar e cara de posuír mal.
Condición segunda: pode operar unha clave de sinatura?
Un emisor propio funciona co modelo de importación documentado, e EasyRSA ou unha pequena ferramenta interna poden producir o material. Executar o comando non é a parte difícil. A parte difícil son as copias de seguridade sen conexión da clave de sinatura, unha ruta de recuperación que alguén probase de verdade, un responsable que non estea de vacacións e unha regra de que a clave nunca acabe nun paquete de cliente nin nunha exportación de configuración. Escríbao como procedemento antes de emitir o primeiro certificado, non despois do primeiro incidente.
AWS Private CA traslada esa custodia a un servizo xestionado. Non traslada a política de inscrición, o paso de aprobación nin a entrega do certificado ao dispositivo.
Condición terceira: como chega a revogación?
Client VPN consome unha lista de revogación de certificados de cliente que vostede importa no punto de conexión, tal como se describe na guía do ciclo de vida dos certificados. Publicar unha CRL noutro lugar do seu PKI non a empurra ao servizo. A importación é unha operación aparte e programada, e unha lista caducada detén as conexións en lugar de degradarse en silencio. Poña a renovación no mesmo calendario que os propios certificados.
Iso converte a renovación nun elemento de monitorización con responsable, non nunha tarefa que se termina no lanzamento. Revogue un certificado de proba de principio a fin antes de necesitar o mecanismo de verdade.
O que ningunha das opcións elimina
Toda opción segue necesitando un certificado de cliente e unha clave distintos por cada dispositivo xestionado de forma independente. Un titorial que reparte unha soa identidade a todos é un atallo de titorial, e ademais fai imposible a revogación selectiva.
Os certificados de servidor importados en ACM non teñen renovación xestionada, así que o responsable debe obter o substituto, volver importalo e despois confirmar que o punto de conexión o adoptou. Renovar o certificado de servidor non renova as credenciais de cliente que xa están nos portátiles. Son ciclos de vida separados con calendarios separados.
Comprobe os tipos de clave e as extensións que acepta o servizo antes de emitir nada. Que unha CA admita un algoritmo non significa que o punto de conexión vaia aceptalo.
Antes do lanzamento, execute unha renovación e unha retirada de cliente polo fluxo de traballo que escolleu, e anote que credencial cambiou, que axuste do punto de conexión cambiou e que ocorreu coa sesión activa. Se ese exercicio remata sen un responsable claro, a elección de emisor non está terminada.