Inventario de certificados VPN: qué puede demostrar el registro de la CA
Una carpeta del servidor, un registro de la CA, una lista de revocación y una tabla de sesiones responden preguntas distintas. Manténgalos separados cuando inventaríe identidades VPN.
Su puerta de enlace acepta un certificado de cliente que nunca ha visto, porque aquello con lo que está configurada es un emisor de confianza, y el certificado llega durante el handshake. Así es como el protocolo debe funcionar, y por eso mismo un listado de directorio en el servidor es un inventario deficiente. El emisor sabe qué creó, el servidor sabe qué se conectó, y el estado de revocación sabe qué se retiró. Un inventario que mezcla esos tres registros acaba afirmando algo que ninguno de ellos dijo.
La puerta de enlace confía en un emisor, no en un listado de archivos
La validación compara un certificado presentado con un anclaje de confianza, de modo que una identidad creada ayer por el mismo emisor se conecta sin haber existido nunca en el disco del servidor. No hay que copiar nada para que eso ocurra, y nadie tiene que aprobarlo a mano. Los registros propios del servidor describen, por tanto, llegadas, no la población de identidades que podrían llegar.
La brecha inversa es igual de incómoda. Un directorio puede contener certificados caducados, revocados e identidades emitidas para dispositivos que nunca se desplegaron. Contar archivos responde cuántos archivos hay, que es una pregunta que nadie hizo. Empiece en cambio por los registros que tienen significado.
Cuatro preguntas, cuatro registros distintos
Cada tipo de registro responde bien a una pregunta y mal a las demás, por eso un informe que los fusiona parece completo mientras es incorrecto de una manera concreta. La tabla siguiente los ordena por la pregunta que resuelven y no por el sistema que los produce.
| Question you are answering | Where the answer lives | How quickly it changes | What it will never show |
|---|---|---|---|
| Was this identity ever created? | The issuer's issuance database | Only when something is issued | Whether the device still exists |
| Is a copy sitting on this host? | The paths you actually inspected | Whenever anyone copies files | Certificates that were never copied here |
| Has the issuer withdrawn it? | Published revocation state | When the issuer next publishes | Withdrawals that are not published yet |
| Is it connected right now? | The live session table | Continuously | Anything about past or future sessions |
Un archivo de certificados públicos no es un secreto, ya que no contiene claves privadas, pero tampoco es compartible. Los sujetos y los nombres de dispositivo revelan detalles operativos, y el informe debe quedarse con el público que lo necesita. Las claves privadas quedan completamente fuera del inventario, porque el inventario necesita metadatos y no credenciales.
Emisor y número de serie son la única clave estable
Los sujetos se reciclan y los nombres de archivo se reutilizan, así que un nombre que el año pasado identificaba un dispositivo puede ahora identificar otro. Ninguno de los dos es una clave, y un informe basado en cualquiera de ellos acabará fusionando dos identidades en una línea.
El par emisor y número de serie identifica un certificado de forma única, y ambos campos salen del propio certificado. Regístrelos con el sujeto, las fechas de validez, la fuente de la que vino la copia y la persona o el dispositivo responsable. Añada el estado de revocación y de despliegue como campos separados con sus propios tiempos de observación, porque un certificado dentro de su ventana de validez no queda autorizado automáticamente. Esos dos hechos viven en sistemas distintos, y fusionarlos oculta el caso en que una identidad se retiró mientras su archivo todavía parece vigente.
Lea un certificado cada vez
Un comodín que se expande por un directorio no es una interfaz por lotes, y oculta qué archivo produjo qué salida. Lea los metadatos certificado a certificado, y lea la parte de revocación desde su propio artefacto. La referencia de OpenSSL x509 enumera los campos que imprimen esas opciones.
openssl x509 -in <cert>.pem -noout -issuer -serial -subject -dates -fingerprint -sha256
openssl crl -in <issuer>.crl -noout -text | head -n 40Para un PKI Easy-RSA gestionado, consulte la base de datos de emisión mediante el flujo de trabajo que la herramienta admite en lugar de suponer una disposición de directorios, y mantenga los originales en solo lectura mientras se arma el inventario. El formato del registro es lo bastante regular para contar las entradas válidas y listar las retiradas sin abrir la base de datos a mano.
grep -c '^V' pki/index.txt
grep '^R' pki/index.txt | cut -f4,5Un inventario que sobrevive a la próxima emisión
Un volcado puntual de un directorio queda obsoleto en el momento en que se emite el siguiente certificado, así que construya el informe desde el flujo de emisión y deje que se actualice como parte del funcionamiento normal. Eso también hace que el informe sea reproducible, lo que importa cuando dos personas discrepan sobre qué se emitió.
Use el resultado para decisiones de renovación y retirada y no como un ejercicio de hoja de cálculo. Borrar una copia local no invalida las copias remotas que ya existen. Retire la identidad mediante el flujo de revocación y autorización configurado, y después registre la retirada con su fecha. Una identidad que ha desaparecido del servidor pero en la que el emisor aún confía no se ha retirado, y esa diferencia separa un inventario exacto de uno que solo tranquiliza.