¿El sitio web muestra el certificado equivocado? Encuentre el proceso que escucha

Instalar software VPN en un alojamiento web puede reorganizar servicios, pero un certificado inesperado no demuestra que los archivos de Apache se hayan reescrito. Algo presentó ese certificado a su navegador, y la primera tarea es nombrarlo. Hasta que se identifiquen el proceso que escucha y el host virtual, cada reparación es una conjetura aplicada a la capa equivocada. Toda la comprobación siguiente es de solo lectura.

No se reinicia, desinstala ni sobrescribe nada mientras reúne los hechos que deciden el caso.

Lea el certificado que el navegador recibió realmente

Anote el nombre de host, la dirección resuelta para cada familia, el puerto y los detalles del certificado de los que se quejó el navegador. Un nombre que se resuelve tanto en un registro A como en uno AAAA puede llegar a dos interfaces distintas, y solo una de ellas puede ser el host al que tiene acceso de shell. Un navegador detrás de un proxy puede tomar de nuevo un tercer camino. Suponer cuál de ellos produjo la advertencia desperdicia la única observación que tiene.

Después reproduzca el handshake desde una máquina en el mismo camino, nombrando la dirección explícitamente y enviando el nombre de servidor previsto para que la respuesta refleje el sitio en lugar del host predeterminado.

openssl s_client -connect 198.51.100.37:443 -servername www.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -fingerprint -sha256 -ext subjectAltName

Compare los nombres alternativos del sujeto y la huella con el certificado que espera, no con un emisor conocido. Conectarse a una dirección desnuda sin el nombre de servidor puede seleccionar un certificado predeterminado, que entonces parece el archivo equivocado cuando en realidad es la pregunta equivocada.

Identifique el proceso vinculado a ese puerto

En el host que debería recibir la conexión, enumere los procesos que escuchan y anote la dirección de enlace, la familia de direcciones y el propietario del proceso. Un servicio vinculado a la dirección de bucle local no es lo mismo que uno vinculado a todas las interfaces, y una publicación de contenedor puede situar el proceso público que escucha en un lugar completamente distinto.

sudo ss -ltnp 'sport = :443'
sudo ss -ltnp | grep -E ':(443|943)\b'

Si TLS lo termina un equilibrador de carga o un proxy situado delante, deténgase aquí e inspeccione esa interfaz frontal en su lugar. La instancia de Apache que hay detrás puede que nunca presente un certificado a un navegador público, así que editar su configuración no cambia nada de lo que ve el navegador. La vista de sockets y el handshake externo deben describir el mismo camino, y eso es lo que establece esta comparación.

Coincida el host virtual antes que el archivo

Cuando Apache es el terminador, pregúntele qué host virtual gana para esa dirección y ese nombre. El comando de control imprime la disposición efectiva, incluido el grupo asociado a cada socket, los nombres de servidor declarados y el host que se trata como predeterminado. Editar un archivo de certificado sin esa respuesta es como el sitio equivocado acaba sirviéndose desde un archivo correcto.

sudo apachectl -S

Las preguntas frecuentes sobre SSL de Apache explican cómo la indicación de nombre de servidor selecciona un certificado. La cabecera Host de HTTP llega después del handshake y no puede cambiar retroactivamente lo que ya se presentó, así que un nombre que no coincide o que falta recae en el host predeterminado.

Un host virtual nombrado con una errata en ServerAlias produce exactamente este síntoma, y también un segundo archivo de configuración que cargue primero un host comodín. Ambos son visibles en ese listado de disposición.

Verifique la corrección en cada camino que afirme

Tras un cambio aprobado, repita la comprobación específica del nombre de host para cada familia de direcciones y termine con la validación ordinaria del navegador en lugar de un indicador de omisión. Conserve una ruta de administración separada antes de tocar ajustes compartidos del proceso que escucha, porque un error ahí elimina el acceso que usaría para deshacerlo. Luego anote qué proceso respondió, qué host virtual coincidió y qué certificado se sirvió antes y después.

Eliminar un paquete puede cambiar la disposición y dejar la discrepancia original sin explicar, y por eso ese registro sobrevive a la reparación.

Lo que quiere es el sitio previsto en el punto de entrada previsto. Un certificado distinto después de que haya desaparecido un servicio no relacionado no es ese resultado, ni siquiera cuando el navegador deja de quejarse.