Elige la comprobación que responde al fallo
Una web puede aceptar una conexión TCP, presentar un certificado y mostrar después una página de error. Son etapas distintas. Una prueba de puerto comprueba si se establece la conexión desde el servidor de prueba. La comprobación del certificado examina la conexión TLS y el certificado que recibe para un nombre concreto. Una consulta HTTP observa la respuesta de la aplicación. Anota en qué etapa aparece el fallo antes de cambiar la configuración.
Empieza por la dirección exacta que falla en el navegador, incluido un subdominio como tienda.example.com. Guarda el mensaje de advertencia, la hora y los dispositivos afectados. Un problema limitado a un teléfono antiguo no requiere la misma investigación que una conexión que agota el tiempo de espera en todos los equipos. Cambia un solo ajuste y repite la misma prueba para poder interpretar la diferencia.
| Prueba | Qué observa | Qué no demuestra |
|---|---|---|
| Puerto TCP | Se estableció una conexión al puerto elegido | Que el certificado o la página sean correctos |
| Certificado TLS | El certificado recibido y el resultado de validación | La seguridad completa de la web o todos los dispositivos |
| Respuesta HTTP | Un estado y contenido devueltos por el servidor | Que funcionen todos los enlaces, accesos y pagos |
Usa el nombre que visitan los usuarios
En una consulta del certificado se introduce el nombre público del servidor, no una contraseña, una ruta privada ni la dirección del panel del alojamiento. En https://tienda.example.com/cesta, el nombre es tienda.example.com. La ruta /cesta no elige el certificado TLS. El puerto HTTPS habitual es 443, pero manda la configuración del servicio. Una redirección desde una dirección HTTPS también necesita una conexión TLS válida antes de que el navegador pueda recibirla.
El dominio raíz y su versión con www son nombres diferentes. Un certificado para example.com no cubre automáticamente www.example.com. Un comodín como *.example.com suele cubrir tienda.example.com, pero no el dominio raíz ni un nombre más profundo como pago.tienda.example.com. Compara los nombres alternativos del certificado con el nombre consultado. El nombre descriptivo que muestra el panel no sustituye a esa lista.
Lee los campos por orden de utilidad
Revisa primero la coincidencia del nombre, el periodo de validez y el resultado de confianza. Los nombres alternativos del sujeto, o SAN, indican los nombres incluidos en el certificado. El emisor identifica a la entidad que figura como emisora. Ninguno de esos datos certifica la calidad de los productos de la web, la honradez de su operador o la ausencia de fallos en su programa. Una conexión autenticada también puede llevar a una web maliciosa.
Compara la fecha y hora de caducidad con la hora de la consulta, no con una captura antigua. Comprueba asimismo el comienzo de la validez: un certificado puede caducar dentro de meses y todavía no ser válido. Una fecha sin hora oculta casos próximos al cambio de día. Los días restantes ayudan a organizar una renovación, pero conviene conservar las marcas de tiempo completas al comunicar un problema.
Las fechas son solo una comprobación
Separa el nombre correcto de la confianza
Un certificado puede incluir el nombre correcto y fallar la validación de confianza. Una cadena incompleta, un certificado intermedio caducado, una autoridad privada o un almacén de confianza antiguo son problemas diferentes. La cadena permite relacionar el certificado de la web con una autoridad que el cliente reconoce. Importan tanto la instalación del servidor como la configuración del cliente. Sustituir el certificado final no arregla por sí solo todos estos casos.
La comprobación del servidor utiliza su biblioteca TLS y su almacén de confianza. No garantiza el mismo resultado en cada navegador, teléfono o aparato conectado. Compara la versión del equipo que falla, su reloj y el mensaje exacto con un navegador actualizado. No instales una autoridad desconocida ni desactives la validación para ocultar la advertencia. Pide al alojamiento su procedimiento de instalación y la cadena compatible que recomienda.
Revisa la CSR antes de solicitar el certificado
Una solicitud de firma de certificado, o CSR, contiene una clave pública y datos de identidad solicitados. No es el certificado emitido, y descodificarla no consulta la web en funcionamiento. Pega únicamente el bloque de la CSR en el descodificador, con sus marcadores de principio y fin. Un archivo marcado PRIVATE KEY debe permanecer en el almacenamiento protegido de claves, nunca en un formulario público, una consulta de soporte o una captura.
Compara los nombres y los datos de la clave con el pedido del certificado y el plan de instalación. El descodificador muestra campos presentes; no decide qué nombres necesita el negocio ni promete qué extensiones emitirá la autoridad. La ausencia de un SAN solicitado no demuestra el contenido de un certificado futuro. Revisa las opciones del pedido y comprueba después el certificado realmente emitido.
Entiende el límite de la descodificación
Leer la estructura de una CSR no equivale a verificar su firma ni a demostrar que existe la clave privada correspondiente en el servidor. Un nombre descodificado es una afirmación de la solicitud, no una prueba de control del dominio. La autoridad realiza su propia validación. El descodificador de Savvy Toolkit ayuda a inspeccionar la petición; una lectura correcta no significa que el pedido haya sido aprobado ni que la instalación pueda completarse.
Un administrador puede revisar una copia local con openssl req -in request.csr -text -verify -noout. La opción -verify comprueba la firma de la propia solicitud, no la confianza pública de un futuro certificado. Ejecuta la orden con la CSR guardada y evita incluir archivos de clave privada en registros compartidos. Analizar los campos sin verificar la firma responde a una pregunta más limitada y debe describirse así.
Interpreta la prueba de un puerto TCP
Comprueba un solo puerto de un servicio público propio o que tengas autorización para probar. Usa el nombre o la IP pública y el puerto TCP configurado. Una conexión aceptada significa que algo respondió en ese destino desde la red del comprobador y en ese momento. No identifica el programa, no prueba un inicio de sesión y no determina que el servicio deba permanecer expuesto a Internet.
Una conexión rechazada y una espera agotada no son lo mismo. El rechazo suele indicar una respuesta explícita en algún punto del recorrido. El tiempo agotado indica que no se completó la conexión dentro del plazo; siguen siendo posibles filtros, problemas de ruta, una dirección incorrecta o un servicio detenido. No conviertas cada espera agotada en la etiqueta puerto cerrado. La prueba no comprueba UDP; TCP 53 no demuestra el funcionamiento de DNS por UDP.
Comprueba toda la ruta del reenvío de puertos
Para probar un servidor doméstico, la aplicación debe estar en marcha y escuchar en la dirección local y el puerto adecuados. La regla de reenvío dirige un puerto exterior hacia ese equipo y servicio. El cortafuegos del ordenador, el router y la red del proveedor pueden cambiar el resultado. Comprueba primero el servicio dentro de la red. Mantén los ajustes ajenos al problema y evita abrir rangos enteros para investigar un único puerto.
Compara la dirección WAN del router con la dirección pública observada desde fuera. Una dirección privada, CGNAT o un segundo router pueden impedir que la regla del router más cercano describa toda la ruta. IPv6 público tiene un modelo de exposición y cortafuegos distinto al de NAT en IPv4. Una prueba realizada desde el mismo Wi-Fi también puede recorrer un camino diferente al de una conexión exterior.
Cuando DNS y el alojamiento no coinciden
Tras una migración, algunas direcciones pueden alcanzar el servidor antiguo y otras el nuevo. Un dominio puede publicar registros IPv4 e IPv6 cuyos destinos entreguen certificados diferentes. Una red de distribución de contenido puede terminar la conexión TLS del visitante antes de enviar tráfico al origen. Por eso el certificado público no siempre es el que acabas de instalar en el servidor de alojamiento.
Anota el nombre consultado y la dirección de destino cuando el resultado la incluya. Compara los registros DNS con las instrucciones del proveedor y revisa las dos familias de direcciones. Conserva el nombre en la prueba TLS: conectar solo a la IP puede provocar que un servidor compartido entregue el certificado predeterminado. Evita cambiar DNS repetidamente mientras comparas resultados; añade variables y dificulta encontrar la causa.
Un diagnóstico basado en observaciones
Imagina una tienda donde https://example.com funciona y https://www.example.com muestra una advertencia de nombre. Ambos destinos aceptan conexiones en el puerto 443. El certificado recibido para www.example.com solo incluye example.com en la lista SAN. Esos resultados apuntan a cobertura del nombre o asignación del certificado al servidor virtual. Abrir otro puerto del cortafuegos no corrige el nombre ausente. Revisa qué certificado debe servir la versión www.
Cambia ahora la observación: ambos nombres presentan el certificado esperado, pero un equipo antiguo muestra un emisor no reconocido. Comprueba la cadena entregada, el reloj y las autoridades admitidas por ese equipo. No deduzcas que todos los usuarios necesitan un certificado nuevo. Estos casos ilustran cómo relacionar resultados; no son mediciones de una tienda real ni garantizan que la misma solución resuelva cualquier advertencia.
Deja una reparación que se pueda comprobar
Después de modificar el certificado o la cadena, repite la consulta original. Guarda el nuevo número de serie, huella o fechas solo cuando esos campos estén disponibles. El mensaje instalado del panel aporta menos información que una conexión nueva que devuelve el certificado previsto. Revisa cada nombre público, el navegador que fallaba y los puertos independientes que use la aplicación. Retira cualquier exposición temporal creada para el diagnóstico.
Al pedir soporte, incluye el nombre público, el puerto, la hora, el mensaje exacto y un resultado breve de antes y después. Excluye contraseñas, claves privadas, cookies de sesión y datos de clientes. Solicita al proveedor la comprobación de la asignación, los certificados intermedios y el proceso de renovación. Una consulta es una instantánea: establece quién se encargará de renovar y cómo se detectarán los fallos futuros.