Validar el certificado en el cliente: cadena, nombre y vigencia

Cuando un servidor presenta su certificado, el cliente comprueba tres cosas. Que la cadena llega hasta una raíz en la que el dispositivo confía. Que el nombre del certificado coincide con el host al que la app quería conectar. Y que está vigente, ni caducado ni aún no válido. Basta con que falle una para que la conexión no deba establecerse, aunque las otras dos estén bien.

Por eso un certificado perfectamente emitido pero para otro nombre sigue siendo rechazable: demuestra que alguien tiene un certificado válido, no que sea el servidor que la app buscaba.

La salida de validación de la sesión de laboratorio lista tres hosts. Dos de ellos fallan una comprobación y aun así la conexión se estableció, y la última columna dice por qué: no los aceptó la plataforma sino un componente propio de la app. Es la señal de que el código sustituyó la validación.

El analizador estático confirma el hallazgo con su regla de gestor de confianza que no valida la cadena, y marca el archivo donde vive. Es el dato que el equipo de desarrollo necesita para corregirlo.

Uno de los dos hosts que pasaron sin deber falla en el nombre: la app visitó un host y el certificado que recibió estaba emitido para otro. Es un fallo real de configuración del servidor, y a la vez una prueba de que la comprobación de nombre de la app estaba apagada, porque con la validación de la plataforma esa conexión habría fallado.

Distingue las dos lecturas en el informe: el servidor presentó el certificado equivocado, y la app lo aceptó cuando debía rechazarlo. Son dos correcciones, de dos dueños distintos.

El extracto del código lleva un comentario del autor: la validación se anuló «para que funcione con el servidor de pruebas». La corrección no es ajustar la validación propia: es eliminarla y dejar que la plataforma valide, y dar al servidor de pruebas un certificado con su nombre emitido por una autoridad interna que solo se instale en las compilaciones de desarrollo. Una excepción para pruebas no debe viajar a la versión de publicación.

Antes de calificar la gravedad hay que mirar el alcance de la compilación. En esta revisión el analizador indica que los cuatro archivos se enlazan en la versión de publicación, y por eso el defecto afecta a los usuarios reales; un defecto igual en código que no llega a publicación pesa mucho menos.