Por qué copiar ca.key a cada cliente de VPN rompe la CA
El cliente verifica el certificado público de la CA; nunca necesita la clave que firma. Copiar ca.key a cada dispositivo entrega la capacidad de emisión a quien se lleve una copia.
En algún punto de las instrucciones de configuración, un directorio se copia entero en cada portátil porque resultaba más fácil que decidir qué archivos pertenecen allí. Ese directorio contiene ca.key, y en el momento en que llega a un segundo dispositivo la autoridad de certificación deja de ser una autoridad. Cualquier poseedor puede ahora emitir identidades en las que confiará el resto de la red.
Merece la pena desenredar esta confusión una vez, porque los dos archivos se parecen y hacen cosas opuestas.
Material de verificación y material de firma
Un cliente necesita el certificado público de la CA para comprobar que el certificado que presenta un par fue firmado por esa autoridad. Es una tarea de verificación y no necesita ningún secreto. Firmar el certificado de un par es otra tarea, que realiza una sola vez quien opera la CA, con la clave privada que nunca sale de su almacenamiento protegido. Mantener esas dos tareas separadas es todo el sentido de entregar dos archivos.
Por tanto, ca.crt pertenece al perfil y ca.key no pertenece a ningún sitio cercano. Los nombres de archivo son una convención, no una garantía, y por eso hay que inspeccionar el tipo en lugar de deducirlo del nombre.
Una arquitectura con una CA intermedia o un servicio de emisión en línea no es una excepción. Es la forma habitual de mantener la capacidad de firma lejos de los extremos y aun así emitir certificados de dispositivo a escala.
Qué debe demostrar un cliente con su propia clave
Cada dispositivo recibe su propio par de claves y su propio certificado, firmado una vez por la CA. El cliente presenta ese certificado y demuestra que posee la clave privada correspondiente, y el servidor decide si lo acepta. Esta es la identidad que se revoca cuando se pierde un portátil.
El contraste importa sobre todo después de un robo. Con identidades por dispositivo, un cliente expuesto se retira mediante revocación o eliminando el par, y el resto de la flota sigue funcionando.
Una clave de autoridad filtrada no se puede tratar así. Todos los certificados que haya firmado o pudiera firmar pasan a ser sospechosos, así que la respuesta es sustituir la confianza y no una revocación puntual. Eso es un proyecto, no un ticket.
| File | Role | Belongs on |
|---|---|---|
ca.crt | Public certificate used to verify signatures | Every client profile |
ca.key | Private key that issues certificates | Protected CA storage only |
| client key pair | Proves one device's identity | That device alone |
Leer un archivo antes de copiarlo a cualquier sitio
Dos comandos le dicen qué clase de objeto tiene en la mano sin imprimir ningún secreto. El primero indica el sujeto y el indicador de CA de un certificado; el segundo valida una clave e informa de su tipo. Ejecute ambos sobre los archivos del paquete que va a distribuir. Todo lo que se valide como clave privada no pertenece a un directorio de cliente.
openssl x509 -in ca.crt -noout -subject -ext basicConstraints openssl pkey -in ca.key -noout -check
Si el segundo comando tiene éxito en un archivo que está dentro de un paquete de cliente, deténgase y trate el paquete como comprometido. La salida que dice que una clave es válida también dice que está presente, y la presencia es todo el problema.
Fíjese también en la dirección contraria: un perfil de cliente contiene legítimamente la clave privada de ese cliente. Borrar todas las claves que encuentre rompe la conexión sin mejorar nada, así que hay que identificar el objeto antes de retirarlo.
Contener una clave que ya ha distribuido
No dé por hecho que borrar la copia local revierte la exposición. Cualquiera que haya tenido el archivo pudo haberlo copiado, y la suposición segura es que lo hizo. Siga el proceso de incidentes del operador y sustituya el ancla de confianza, reemitiendo los certificados de dispositivo bajo una CA nueva.
Después cambie el empaquetado que creó el problema. Envíe un listado del directorio con una lista blanca explícita de archivos, mantenga la clave de la CA en una máquina que nunca se une a la flota de clientes y anote qué sistema la guarda.
Si la autoridad debe emitir con frecuencia, mueva la firma detrás de un servicio o de una intermedia con alcance estrecho y validez corta. Así un error futuro expone un subconjunto de la emisión y no la raíz de confianza de todo el despliegue.