Per què copiar ca.key a cada client de VPN trenca la CA

En algun lloc de les instruccions de configuració, un directori es copia sencer a cada portàtil perquè era més fàcil que decidir quins fitxers hi pertanyen. Aquest directori conté ca.key, i en el moment que arriba a un segon dispositiu l’autoritat de certificació deixa de ser una autoritat. Ara qualsevol posseïdor pot emetre identitats en què confiarà la resta de la xarxa.

Val la pena aclarir aquesta confusió una vegada, perquè els dos fitxers s’assemblen i fan coses oposades.

Material de verificació i material de signatura

Un client necessita el certificat públic de la CA per comprovar que el certificat que presenta un igual ha estat signat per aquesta autoritat. Això és una tasca de verificació i no necessita cap secret. Signar el certificat d’un igual és una tasca diferent, que fa una sola vegada qui gestiona la CA, amb la clau privada que no surt mai del seu emmagatzematge protegit. Mantenir aquestes dues feines separades és tot el sentit de distribuir dos fitxers.

Per tant, ca.crt pertany al perfil i ca.key no pertany enlloc a prop seu. Els noms dels fitxers són una convenció, no una garantia, i per això cal inspeccionar el tipus en lloc de deduir-lo del nom.

Una arquitectura amb una CA intermèdia o un servei d’emissió en línia no n’és cap excepció. És la manera habitual de mantenir la capacitat de signatura lluny dels terminals mentre s’emeten certificats de dispositiu a escala.

Què ha de demostrar un client amb la seva pròpia clau

Cada dispositiu rep la seva pròpia parella de claus i el seu propi certificat, signat una vegada per la CA. El client presenta aquest certificat i demostra que posseeix la clau privada corresponent, i el servidor decideix si l’accepta. Aquesta és la identitat que es revoca quan es perd un portàtil.

El contrast és més important després d’un robatori. Amb identitats per dispositiu, un client exposat s’elimina amb una revocació o traient-lo de la llista d’iguals, i la resta del parc continua funcionant.

Una clau d’autoritat filtrada no es pot tractar així. Cada certificat que hagi signat o pogut signar esdevé sospitós, de manera que la resposta és substituir la confiança, no una revocació puntual. Això és un projecte, no un tiquet.

Llegeix un fitxer abans de copiar-lo enlloc

Dues ordres et diuen quin tipus d’objecte tens a les mans sense imprimir cap secret. La primera indica el subjecte i l’indicador de CA d’un certificat; la segona valida una clau i n’informa del tipus. Executa les dues sobre els fitxers del paquet que estàs a punt de distribuir. Tot el que es validi com a clau privada no pertany a un directori de client.

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

Si la segona ordre té èxit en un fitxer que és dins d’un paquet de client, atura’t i tracta el paquet com a compromès. La sortida que diu que una clau és vàlida també diu que hi és, i la presència és tot el problema.

Fixa’t també en la direcció contrària: un perfil de client conté legítimament la clau privada d’aquest client. Esborrar totes les claus que trobis trenca la connexió sense millorar res, així que cal identificar l’objecte abans de retirar-lo.

Contenir una clau que ja has distribuït

No donis per fet que esborrar la còpia local reverteix l’exposició. Qualsevol que hagi tingut el fitxer pot haver-lo copiat, i l’assumpció segura és que ho va fer. Segueix el procés d’incidents de l’operador i substitueix l’àncora de confiança, reemetent els certificats de dispositiu sota una CA nova.

Després canvia l’empaquetament que va crear el problema. Envia un llistat del directori amb una llista blanca explícita de fitxers, mantén la clau de la CA en una màquina que no s’uneixi mai al parc de clients i anota quin sistema la guarda.

Si l’autoritat ha d’emetre sovint, mou la signatura darrere d’un servei o d’una intermèdia amb un abast estret i una validesa curta. Així, un error futur exposa un subconjunt de l’emissió i no l’arrel de confiança de tot el desplegament.