Resumen

  • certificate_authorities, valor 47 en TLS, contiene nombres distinguidos X.501 codificados en DER para orientar qué certificado o cadena presenta la otra parte. El nombre no incorpora la clave de confianza ni demuestra que exista un camino aceptable.
  • Puede ir en ClientHello para influir en el certificado del servidor o en CertificateRequest para influir en el del cliente. Dirección, privacidad y responsable operativo cambian en cada caso.
  • Una operación defendible conserva por separado la lista transmitida, los candidatos evaluados, el camino validado y la decisión de autorización de la aplicación.

El dato que llegó demasiado lejos

En muchas plataformas, la observabilidad acaba en una etiqueta como ca_allowed. Parece útil porque condensa una sesión compleja en un resultado fácil de consultar. Pero no especifica si “allowed” significa que apareció un DN en un mensaje, que el cliente escogió una credencial, que el servidor encontró un ancla de confianza o que el servicio concedió un rol.

Esas respuestas pueden divergir sin que el protocolo esté roto. El cliente puede encontrar un certificado adecuado y el servidor rechazarlo con unknown_ca. El servidor puede validar la cadena y la aplicación negar el sujeto. También puede no existir ningún certificado compatible, en cuyo caso TLS 1.3 permite un mensaje Certificate vacío.

La mejora no consiste en buscar un booleano más exacto, sino en preservar la secuencia de decisiones y la versión de política que controló cada una.

Un DN identifica; no entrega confianza

RFC 9846 describe el contenido como un vector no vacío de nombres distinguidos DER. Cada nombre puede representar un ancla deseada o una CA subordinada dentro del espacio de autorización que el emisor quiere indicar.

No viajan el certificado de la CA, su clave pública, sus restricciones ni una entrada de almacén. Dos certificados de CA pueden compartir subject y usar claves diferentes. Incluso es posible extraer un subject de un certificado que no tenga capacidad de CA. Por ello, que el DN coincida no identifica de manera suficiente el objeto de confianza.

La validación de rutas definida por RFC 5280 necesita un ancla concreta y entradas de política; comprueba firmas, vigencia, restricciones básicas y de nombres, usos de clave y demás estado aplicable. El ancla puede omitirse de la cadena enviada porque se distribuye por otro canal. Ningún nombre de la extensión sustituye esas pruebas.

La presencia permite afirmar que el emisor anunció un DN en ese contexto. No permite afirmar que acepte cualquier certificado emitido debajo de él. La ausencia tampoco demuestra desconfianza total: la lista puede ser parcial, reducida por privacidad o generada para una población concreta de credenciales.

Cuando la misma forma apunta en sentidos contrarios

En ClientHello, el cliente ofrece información para que el servidor seleccione su certificado y una posible cadena alternativa. En CertificateRequest, el servidor guía al cliente entre sus credenciales de autenticación. No es la misma decisión observada desde dos lados: son dos decisiones con inventarios distintos.

OpenSSL advierte que los nombres de CA enviados por el cliente llegan en texto claro al servidor. Una exportación automática del almacén corporativo puede revelar nombres internos y jerarquías. Una lista del servidor demasiado extensa, por su parte, aumenta los bytes del handshake y puede afectar la elección local de credenciales.

TLS 1.3 no utiliza la antigua extensión trusted_ca_keys. Si ClientHello ofrece versiones anteriores, puede contener mecanismos heredados. Los registros deben conservar versión negociada, mensaje, dirección y tipo de extensión para no mezclar significados.

El selector resuelve varias restricciones a la vez

El DN es una condición entre muchas. También intervienen signature_algorithms, en ocasiones signature_algorithms_cert, tipo de clave, disponibilidad de la clave privada, algoritmo del certificado, Key Usage, EKU, SNI, filtros OID, validez y cadenas que la implementación realmente puede construir.

Por eso importan los candidatos descartados. Un certificado puede coincidir con la CA pero fallar por EKU; otro puede tener la clave correcta y no alcanzar una autoridad indicada; un tercero puede ser válido pero usar un algoritmo no ofrecido. El leaf elegido no explica por sí solo el proceso.

Si ningún cliente dispone de una credencial apta, un Certificate vacío conserva la verdad del estado. El servidor puede continuar según su perfil o responder certificate_required. Elegir una identidad no relacionada solo para evitar el vacío borraría una frontera útil del protocolo.

OpenSSL separa anunciar de confiar

Las familias de API que instalan una lista de nombres no cargan certificados de confianza. OpenSSL indica expresamente que las CA enumeradas no se vuelven confiables por aparecer allí; las ubicaciones de verificación se administran aparte.

La prueba operacional consiste en crear desacuerdo de forma controlada. Anuncie el subject de una CA sin confiar en su clave. El cliente puede escoger una cadena que coincida y el servidor, correctamente, puede rechazarla. Después confíe en una cadena cuyo nombre no se anuncia y observe qué hace el selector local.

La recarga en caliente puede cambiar solo una de las dos superficies. Conviene versionar y hash-ear la generación de la lista y la del almacén, con su hora de activación y procesos que aún ejecutan la generación anterior.

Además, el cargador de nombres de CA cliente extrae subjects y no restringe su entrada a certificados de CA. “El archivo se leyó” no implica “todas sus entradas son autoridades confiables”.

Validar una identidad no asigna una función

Después de verificar el camino, las reglas del protocolo interpretan los nombres del endpoint. La aplicación aún debe enlazar la identidad normalizada con un inquilino, cuenta, carga, rol y acción. Puede exigir una forma exacta de SAN, una pareja issuer–subject, un OID de política o un registro externo vigente.

Por eso una cadena aceptada puede terminar en acceso denegado. La negación no corrige TLS; aplica una autoridad que TLS no posee. Del mismo modo, el cliente no debe inferir de un handshake completado que el servidor lo considera autorizado para una operación. Puede necesitar una respuesta explícita de capa de aplicación.

Las bibliotecas ofrecen puntos de prueba, no veredictos automáticos

OpenSSL, GnuTLS y BoringSSL exponen callbacks de selección, listas de confianza y funciones de verificación. Un callback registrado prueba que la capacidad existe. Solo una invocación unida al identificador de conexión prueba que ese camino corrió.

BoringSSL limita algunas vistas de nombres al callback de selección o a la vida de un handshake pausado. La evidencia durable debe copiar o resumir los DER durante ese ámbito. GnuTLS también mantiene separados el callback que elige credenciales y la función que verifica la sesión con una lista de confianza.

En una reanudación TLS 1.3 con PSK no hay necesariamente un nuevo CertificateRequest del handshake principal. Si no hubo intercambio de certificados, la telemetría no puede declarar una nueva evaluación de la lista o de la identidad cliente.

Ensayos negativos para mantener cada autoridad en su sitio

Anuncie un DN sin la clave confiable correspondiente. Use dos CA con el mismo subject y confíe solo en una. Ofrezca un certificado cuyo nombre coincide pero cuya vigencia, EKU, política o clave privada no cumple. Guarde cada causa de descarte.

Haga que el camino valide y niegue después el sujeto en el límite del inquilino. Elimine todas las credenciales aptas y observe Certificate vacío y la decisión posterior. Cambie por separado lista y almacén para comprobar las alarmas de deriva.

Capture ClientHello y mida la exposición organizativa. Pruebe vectores grandes. Reanude una sesión y confirme que no aumenta el contador de autenticación nueva. Diferencie configurado, invocado, seleccionado, verificado y autorizado.

La evidencia forma una escalera: nombre anunciado, conjunto candidato, credencial elegida, posesión de clave, camino verificado, identidad interpretada y acción permitida. Cada peldaño responde a una autoridad distinta.

Fuentes