Resolución de problemas PKI

Diagnostica emisión de certificados, OCSP y CRL.

Esta guía ayuda al operador PKI a localizar fallos de emisión y publicación de estado. Conserva versión de Lamassu, operación, CA, emisor, serie, hora y error devuelto. No incluyas claves privadas ni tokens en el diagnóstico.

Para Gateway, inicio de sesión, pods, dependencias y mensajería, consulta Diagnóstico de Despliegue. Para enrolamiento de dispositivos, consulta Diagnóstico EST.

La emisión falla

ComprobaciónQué revisarSiguiente paso
CAExiste, está activa y sus fechas son utilizables.Autoridades.
ClaveEl registro tiene clave privada utilizable y el motor puede firmar.Prueba Sign / Verify en KMS; revisa permisos y disponibilidad del proveedor.
CSRPEM correcto y firma verificable.openssl req -in request.csr -noout -verify -text.
PerfilFuente seleccionada, ID existente, algoritmo y tamaño admitidos.Revisa la precedencia de Perfiles; CA y DMS resuelven de forma distinta.
ResultadoSujeto, SAN, usos y fechas adecuados.Compara CSR, perfil y certificado; emitir correctamente no demuestra aceptación por el consumidor.

Si el certificado emitido tiene campos inesperados, revisa Honor Subject, Honor Key Usage, Honor Extended Key Usages y Honor Extensions. Esta última solo conserva SAN, sin validar el derecho a esos nombres. La validez no se recorta automáticamente al vencimiento de la CA.

Si falla la reemisión de una CA, comprueba revocación y fecha: no se admite para una CA revocada o ya vencida. Para cambiar la clave, utiliza Jerarquía y rotación.

OCSP o CRL no reflejan un cambio

Revisa cada frontera por separado:

  1. Registro: vuelve a leer el certificado correcto por serie y emisor. Confirma estado, razón y hora; los registros expirados o revocados definitivamente no admiten otra transición.
  2. Endpoint: inspecciona AIA y CDP del certificado. Consulta esas URLs desde la red del consumidor; una ruta antigua o un emisor incorrecto puede explicar la diferencia.
  3. OCSP: guarda una respuesta nueva, verifica firma y tiempos y observa su estado. Un error HTTP por una serie ausente no equivale a Good ni garantiza un Unknown firmado.
  4. CRL: compara latest_crl, número y tiempos de la lista descargada. Confirma la serie en el contenido. Si no cambia, revisa regenerate_on_revoke, entrega del evento, trabajos, firma y almacenamiento con el operador de Despliegue.
  5. Cliente: comprueba caché, política ante evidencia vencida o no disponible, extensión IDP crítica y rechazo de una conexión nueva.

Una reactivación desde CertificateHold requiere una CRL nueva para que el cliente deje de ver la suspensión. Reactivar una CA no restaura su cascada de descendientes; revisa todos los estados y los errores individuales de la operación.

La cadena se valida pero la conexión falla

Comprueba la identidad esperada, SAN, KU/EKU, clave correspondiente, intermedias enviadas y permisos del consumidor. Diferencia confianza TLS en el servidor, autenticación del cliente y autorización de la acción. Sigue Validación para una prueba positiva y otras de rechazo.

Cuando necesites escalar un problema, entrega los identificadores, error y evidencia pública relevante, con tiempos de consulta y versión. Esto permite distinguir un fallo de emisión, de publicación o de la aplicación consumidora.

En esta página