¿Cómo funciona la validación de certificados TLS y cómo se depuran las fallas?

Pregunta y contexto aplicable

Después de que api.example.com rota su certificado TLS, los navegadores y una solicitud normal de curl https://api.example.com tienen éxito. Un worker de Java 21 que utiliza un truststore personalizado falla con SunCertPathBuilderException: unable to find valid certification path. Mientras tanto, curl https://203.0.113.10 llega al mismo balanceador de carga pero falla la verificación de identidad.

Explique cómo un cliente TLS construye y valida una ruta de certificación, cómo coincide con la identidad de servicio prevista, por qué estos clientes pueden llegar a resultados diferentes y cómo diagnosticaría y repararía el incidente sin deshabilitar la verificación de certificados ni de nombres de host.

Utilice estas suposiciones explícitas: api.example.com y 203.0.113.10 son ficticios; el endpoint utiliza un certificado de servidor ordinario de confianza pública; el truststore personalizado del worker de Java es independiente de la configuración de confianza del navegador; y el balanceador de carga puede alojar múltiples nombres TLS en una sola dirección IP. La tarea consiste en la autenticación de certificados y el diagnóstico operativo. La negociación de conjuntos de cifrado, el programa de claves de TLS 1.3 y 0-RTT están fuera del alcance principal.

Esta pregunta encaja en entrevistas de ingeniería de software general, redes, SRE, plataforma, seguridad, backend y clientes. Una respuesta útil debe conectar las reglas de PKI con el comportamiento observable del cliente en lugar de simplemente recitar "hoja, intermedio, raíz".

Qué evalúa el entrevistador

En primer lugar, ¿puede el candidato separar cuatro decisiones que a menudo se agrupan en una sola?

1. Construcción de la ruta: encontrar una secuencia candidata desde la hoja a través de cero o

más intermedios hasta un ancla de confianza configurada localmente.

1. Validación de la ruta: verificar que la ruta candidata satisfaga firmas, tiempo,

restricciones de CA, uso de claves, restricciones de nombres, extensiones críticas, requisitos de algoritmos y políticas, y el propósito previsto del servidor TLS.

1. Coincidencia de identidad del servicio: hacer coincidir el nombre de host o la dirección IP de

referencia configurada con el identificador subjectAltName correspondiente.

1. Prueba de handshake: verificar CertificateVerify para que el par demuestre la posesión de

la clave privada del certificado hoja y la vincule a este handshake.

En segundo lugar, ¿puede el candidato explicar la discrepancia entre clientes sin inventar una causa universal? Los navegadores, las herramientas del sistema operativo, los contenedores, las JVM, las aplicaciones móviles y los proxies corporativos pueden usar diferentes anclas de confianza, intermedios en caché o detectables, relojes, algoritmos, políticas de revocación e identidades de referencia.

En tercer lugar, ¿puede el candidato ejecutar una investigación controlada? Una respuesta sólida captura la cadena exacta de certificados entregada con el SNI correcto, reproduce la validación con el material de confianza del cliente que falla, preserva el nombre de host mientras fija una IP, compara las rutas exitosas y fallidas, y verifica cada instancia del balanceador de carga.

Finalmente, ¿puede el candidato reparar la confianza de manera segura? Importar una hoja arbitraria, aceptar todos los certificados, omitir las verificaciones de nombres de host o usar curl -k solo oculta el control de seguridad fallido. La reparación debe restaurar la cadena o política de confianza prevista e incluir un plan de reversión y caducidad para cualquier cambio temporal de confianza.

Preguntas para aclarar antes de responder

• ¿Qué URL e identidad de referencia exacta utiliza cada cliente? Conectarse a una IP

literal solicita una identidad de IP. Conectarse a la misma IP manteniendo la URL https://api.example.com solicita la identidad DNS api.example.com.

• ¿Qué almacén de confianza está activo en tiempo de ejecución? Confirme las opciones reales de la JVM, la

imagen del contenedor, el usuario, el entorno del proceso y el truststore montado en lugar de inspeccionar el almacén predeterminado de la laptop de un desarrollador.

• ¿Qué cadena recibió la solicitud que falló? El SNI, el listener del balanceador de carga, la región,

el proxy, IPv4 versus IPv6 y el desfase de despliegue pueden cambiar el certificado presentado.

• ¿Fallaron todos los clientes al mismo tiempo? Verifique la hora local, la validez del certificado,

la versión del paquete de CA, la política de algoritmos y si solo una instancia de backend o de borde sirve la nueva cadena.

• ¿Se intercepta TLS? Un proxy corporativo puede reemplazar la hoja pública con un

certificado emitido por una raíz empresarial en la que un navegador confía pero el truststore personalizado de la JVM no.

• ¿Qué identifica el error? Un error de construcción de ruta, un certificado expirado,

una discordancia de nombre de host, un algoritmo no compatible, una falla de revocación y una falla de negociación TLS son ramas diferentes. Conserve la excepción completa y el rastro de validación.

Marco de respuesta de 30 segundos

“Divido la verificación en construcción de ruta, validación de ruta, coincidencia de identidad de servicio y prueba de clave privada. El servidor normalmente envía su hoja y los intermedios requeridos; el cliente construye una ruta hacia un ancla de confianza en la que ya confía localmente. Luego valida firmas, tiempo, restricciones de CA y de claves, extensiones críticas, algoritmos y el propósito del servidor. Por separado, hace coincidir el nombre DNS o la dirección IP configurada con el mismo tipo de entrada SAN. El SNI ayuda al servidor a seleccionar un certificado, pero no establece confianza ni prueba el nombre de host.

El éxito del navegador no demuestra que la ruta de Java sea válida porque el truststore personalizado de la JVM, el descubrimiento de intermedios, las raíces de proxy, el reloj y las políticas pueden diferir. Capturaría la cadena con el SNI correcto, la reproduciría contra el truststore exacto del worker, compararía las rutas construidas y usaría curl --resolve para mantener constante la identidad DNS mientras apunto a la IP. Corregiría el intermedio servido o el ancla de confianza administrada deliberadamente, nunca deshabilitaría la verificación y volvería a probar cada borde más el worker real”.

Análisis detallado paso a paso

1. Establecer las tres entradas independientes. El verificador necesita un certificado hoja de destino, un conjunto de certificados intermedios no confiables que puedan ayudar a construir una ruta y una o más anclas de confianza locales. "No confiable" aquí no significa malicioso; significa que un intermedio es material de construcción de ruta y no se convierte en un ancla de confianza simplemente porque el servidor lo envió.

Un servidor HTTPS normalmente envía el certificado hoja seguido de los intermedios que el cliente necesita. Por lo general, no necesita enviar la raíz. La decisión de confianza del verificador termina en una raíz u otra ancla configurada por la política local. Enviar una raíz no puede hacer que una raíz desconocida sea confiable.

2. Construir rutas candidatas antes de validar una. La hoja nombra a un emisor; un intermedio puede nombrar a otro emisor; las CA con firma cruzada pueden crear más de una ruta posible. Un cliente puede obtener intermedios del handshake, de una caché o de un mecanismo de descubrimiento específico de la implementación. El RFC 5280 define la validación de rutas, pero deliberadamente deja el procedimiento para obtener la secuencia candidata fuera de su alcance. Por lo tanto, dos clientes que cumplen con los estándares pueden tener diferentes entradas de construcción y seleccionar diferentes rutas.

Un SunCertPathBuilderException significa que el constructor de rutas de Java no encontró una ruta que pudiera aceptar con sus certificados y políticas disponibles. Las causas plausibles incluyen un intermedio faltante, un ancla de confianza ausente en el almacén personalizado, una ruta alternativa inutilizable o una restricción de política. La excepción por sí sola no prueba cuál de ellas ocurrió.

3. Validar la ruta seleccionada. Para cada enlace relevante, el cliente verifica la firma del certificado con la clave pública del emisor y procesa las restricciones. Las comprobaciones importantes incluyen:

• la hora actual se encuentra dentro del intervalo de validez del certificado;
• cada certificado emisor tiene permitido actuar como CA bajo basicConstraints, y

se respeta cualquier límite de longitud de ruta;

• el uso de claves de CA permite la firma de certificados, mientras que la hoja es adecuada para el propósito previsto

del servidor TLS según la política aplicable de uso de claves y uso extendido de claves;

• las restricciones de nombres, las políticas de certificados y las extensiones críticas reconocidas se

procesan correctamente;

• los algoritmos y las fortalezas de clave satisfacen la política de seguridad actual del cliente; y
• la ruta termina en un ancla de confianza seleccionada por la política local.

La revocación es otra dimensión de la política. Los clientes difieren en cómo obtienen y manejan CRLs, respuestas OCSP, estado grapado (stapled), errores de red y condiciones de falla suave (soft-fail) versus falla dura (hard-fail). No asuma que "la validación de ruta RFC 5280 aprobada" demuestra que cada cliente realizó las mismas verificaciones de revocación en línea.

4. Hacer coincidir la identidad del servicio por separado. La identidad de referencia proviene de una entrada confiable como la URL HTTPS configurada, no del DNS inverso, del certificado mismo ni de cualquier nombre que proporcione un atacante. Bajo el RFC 9525, la identidad del servicio moderna se representa en subjectAltName; los clientes no deben recurrir al Common Name del sujeto para este propósito.

Los nombres DNS y las direcciones IP utilizan diferentes tipos de SAN. https://api.example.com requiere un DNS-ID coincidente. https://203.0.113.10 requiere la dirección IP exacta en un SAN iPAddress; un SAN DNS que contenga api.example.com no lo satisface. Si se admite, un comodín debe ser la etiqueta más a la izquierda completa y coincide con exactamente una etiqueta: *.example.com puede coincidir con api.example.com, pero no con v2.api.example.com o example.com.

El SNI y la verificación tienen tareas diferentes. El SNI le dice a un servidor multiinquilino qué certificado presentar. La identidad de referencia le dice al cliente qué nombre debe cubrir ese certificado. Una solicitud puede enviar el SNI correcto y aun así fallar en la verificación del nombre de host, o bien omitir el SNI, recibir un certificado predeterminado y luego fallar por una razón diferente.

5. Verificar la posesión de la clave privada de la hoja. Una ruta válida y un SAN coincidente vinculan una identidad a una clave pública. Durante un handshake TLS 1.3 autenticado por certificado, CertificateVerify firma la transcripción del handshake con la clave privada correspondiente. Verificarlo demuestra que el par controla esa clave privada en esta negociación. Esto es distinto de construir la ruta y hacer coincidir el nombre de host.

6. Explicar por qué las tres observaciones son compatibles. Las observaciones no se contradicen entre sí:

7. Reproducir el endpoint y la ruta de forma independiente. Comience con el nombre DNS y el SNI exactos. Los siguientes flags apuntan a OpenSSL 3.6; verifique openssl version primero porque el LibreSSL del sistema macOS y los paquetes más antiguos exponen opciones diferentes. -showcerts muestra lo que envió el servidor; -verify_return_error se detiene ante errores de verificación; -verify_hostname verifica la identidad DNS prevista.

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  -showcerts \
  -verify_return_error \
  -verify_hostname api.example.com \
  </dev/null

Guarde los certificados hoja e intermedios como archivos PEM separados, obtenga las raíces de confianza exactas del entorno que falla a través de una exportación aprobada y repita la validación de la ruta explícitamente:

openssl verify \
  -CAfile worker-roots.pem \
  -untrusted served-intermediates.pem \
  -purpose sslserver \
  -verify_hostname api.example.com \
  leaf.pem

Este experimento distingue las anclas de confianza de los intermedios. No emula perfectamente todas las reglas de algoritmos, revocación o proveedores de la JVM, por lo que la reproducción decisiva aún se ejecuta dentro de la misma imagen de Java con la salida de depuración del trust-manager y el mismo truststore. Redacte los nombres internos y el material de los certificados antes de compartir los registros.

Para apuntar a una dirección de balanceador de carga específica sin cambiar el nombre de referencia HTTPS, preserve la URL y anule la resolución:

curl --resolve api.example.com:443:203.0.113.10 \
  https://api.example.com/health

Repita para cada dirección IPv4 e IPv6, región e instancia perimetral anunciadas. Solicitar directamente https://203.0.113.10 es una prueba de identidad diferente y no debe usarse como prueba de que el certificado para api.example.com es incorrecto.

8. Reparar la capa fallida y probar la ruta de reversión. Si el servidor omite un intermedio necesario, despliegue el paquete correcto de hoja más intermedio en cada terminador TLS y confirme la cadena servida. Si la organización utiliza intencionalmente una CA privada o de proxy, distribuya su raíz aprobada a través del proceso de truststore administrado registrando la propiedad, el alcance, la huella digital, la caducidad y la reversión. Si se emitió el SAN incorrecto, reemplace el certificado. Si los relojes, las instancias desactualizadas o las políticas de algoritmos difieren, corrija esas condiciones directamente.

No importe la hoja del endpoint como una raíz permanente, no copie un certificado inexplicado de la caché de un navegador, no desactive la identificación de endpoints, no instale un trust manager permisivo ni implemente curl -k. Después de la reparación, verifique el worker real, el navegador, curl, cada dirección de borde, la eliminación del certificado anterior, el monitoreo antes del vencimiento y el comportamiento ante fallas para un nombre de host deliberadamente incorrecto y una cadena de prueba no confiable.

Respuesta de muestra de alta calidad

“No deduciría que Java está equivocado porque el navegador funciona. Cada verificador toma una decisión a partir de su propio certificado de destino, conjunto de intermedios, anclas de confianza, identidad de referencia, tiempo y política.

Separo cuatro comprobaciones. Primero, la construcción de la ruta encuentra una secuencia desde la hoja a través de intermedios hasta un ancla confiable localmente. Los certificados enviados por el servidor son solo entradas de construcción; no crean confianza. Segundo, la validación de la ruta verifica firmas, validez, restricciones de CA y de claves, extensiones críticas, algoritmos, políticas y el propósito de autenticación del servidor. Tercero, la identificación del endpoint compara el nombre configurado con el SAN. Una URL DNS necesita un DNS-ID, mientras que una URL con IP literal necesita un IP-ID. El SNI solo selecciona el certificado del host virtual. Cuarto, TLS verifica CertificateVerify para demostrar que el par posee la clave privada de la hoja para este handshake.

El navegador puede tener un almacén de raíces diferente, un intermedio en caché o descubierto, o una raíz de proxy empresarial. El truststore personalizado del worker de Java 21 puede carecer del ancla necesaria o de la entrada de construcción, y su excepción solo dice que no se construyó ninguna ruta aceptable. La falla de curl por IP es esperada si el certificado cubre el nombre DNS pero no tiene un SAN de IP.

Primero capturaría la cadena exacta con openssl s_client, SNI correcto, -verify_return_error y -verify_hostname. Haría un inventario de SANs, emisores, validez, restricciones básicas, uso de claves, EKU, algoritmos y huellas digitales. Luego validaría la hoja guardada y los intermedios servidos contra una exportación aprobada de las raíces del worker, y lo reproduciría dentro del contenedor Java con sus flags de tiempo de ejecución reales. curl --resolve me permite probar cada IP del balanceador de carga manteniendo api.example.com tanto como la identidad de la URL como el SNI.

Si falta un intermedio, corrijo el paquete de la cadena en todos los terminadores TLS. Si falta una raíz privada o de proxy aprobada, distribuyo esa raíz a través del flujo de trabajo de truststore administrado en lugar de confiar en una hoja. Si el SAN, el reloj o la política son incorrectos, reparo esa capa exacta. Nunca uso trust-all, ni deshabilito la verificación de nombres de host, ni acepto -k como una solución. Cierro el incidente solo cuando el worker real tiene éxito en cada borde y las pruebas negativas aún rechazan el nombre de host incorrecto y una cadena no confiable”.

Errores comunes

• Tratar la construcción y la validación de cadenas como una sola operación → los clientes pueden descubrir

diferentes rutas candidatas antes de la validación → **nombre el destino, el conjunto de intermedios, las anclas de confianza y la política por separado.**

• Confiar en una raíz porque el servidor la envió → las anclas de confianza provienen de la política local

→ trate los certificados proporcionados por el servidor como entradas de construcción no confiables.

• Verificar firmas pero omitir restricciones de CA → una firma válida por sí sola no

autoriza a un emisor a firmar certificados → **verifique restricciones básicas, longitud de ruta, uso de claves, extensiones críticas y propósito.**

• Usar el nombre del certificado como la identidad esperada → eso permite que los datos presentados

elijan lo que deben probar → derive la identidad de referencia a partir de la URL configurada.

• Asumir que SNI realiza la verificación del nombre de host → SNI selecciona un host virtual →

realice la coincidencia de SAN como una verificación de cliente independiente.

• Esperar que un SAN DNS valide una URL de IP → DNS-ID e IP-ID son tipos diferentes

→ use --resolve cuando el objetivo sea fijar el enrutamiento mientras se preserva la identidad DNS.

• Culpar a un intermedio faltante a partir de una sola excepción → el truststore, la política, el tiempo,

el proxy y el desfase de despliegue pueden producir síntomas similares → **capture la cadena real y reproduzca con entradas de tiempo de ejecución exactas.**

• Reparar con -k o trust-all → esto convierte un canal autenticado en uno

no autenticado → corrija la cadena, la identidad, la raíz administrada, el reloj o la política.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Debería el servidor enviar el certificado raíz?

Por lo general, no. El servidor debe enviar la hoja y los intermedios necesarios para llegar a una raíz en la que el cliente ya confíe. Una raíz enviada por el servidor es redundante para un cliente que confía en ella e inútil para un cliente que no lo hace. También desperdicia bytes en el handshake.

Pregunta de seguimiento 2: ¿Por qué un navegador puede recuperarse de un intermedio faltante mientras que otro cliente falla?

Las implementaciones pueden tener diferentes cachés de intermedios o comportamientos de descubrimiento. Un navegador puede poseer ya el intermedio u obtenerlo a través de un mecanismo específico de la implementación, mientras que un worker aislado solo tiene el handshake y su almacén personalizado. Por eso los servidores deben entregar los intermedios requeridos en lugar de depender de la recuperación del cliente. Confirme la ruta real en lugar de asumir que todos los navegadores se comportan de la misma manera.

Pregunta de seguimiento 3: ¿Un nombre de host coincidente hace que un certificado autofirmado sea seguro?

No. La coincidencia de identidad y la confianza en la ruta son independientes. Un certificado puede contener el SAN DNS correcto y aun así no tener una ruta hacia un ancla confiable localmente. Un despliegue privado puede confiar en una raíz autofirmada mediante un aprovisionamiento controlado, pero la simple coincidencia del nombre no establece esa confianza.

Pregunta de seguimiento 4: ¿Cómo se debe abordar la revocación en la respuesta de una entrevista?

Indique el límite de la política. Las CRL, OCSP, el grapado (stapling), el estado en caché, el acceso a la red y las reglas de soft-fail o hard-fail difieren entre los clientes. Determine qué verifica el verificador real y cómo se comporta cuando el estado no está disponible. No afirme que todos los clientes realizan comprobaciones idénticas en línea y no debilite silenciosamente una política obligatoria de hard-fail para hacer desaparecer una interrupción.

Pregunta de seguimiento 5: ¿Qué evidencia da por cerrado este incidente?

Registre las huellas digitales de la hoja y de los intermedios servidos por borde, la ruta construida bajo las raíces exactas del worker, la prueba exitosa del nombre DNS y de la clave privada, y las solicitudes exitosas del worker real. Agregue pruebas negativas para un nombre DNS incorrecto, una IP literal sin IP-ID y una cadena no confiable. Confirme que no quede ningún bypass, que todas las instancias del balanceador de carga sirvan el paquete previsto, que el monitoreo cubra la caducidad y la rotación, y que cualquier raíz temporal o artefacto de diagnóstico tenga un responsable y una fecha de eliminación.