Apache parece estar usando un certificado antiguo vencido a pesar de que está instalado uno nuevo

15

Apache 2.2.3 / mod_ssl / CentOS 5.5 VPS

Nuestro certificado expiró el 06/10/2011, y aunque aparentemente hemos instalado el nuevo correctamente, ¡ navegar al sitio aún muestra un certificado vencido! Intenté eliminar el caché de mi navegador y usar varios navegadores diferentes. Líneas relevantes del archivo ssl.conf (he excluido las comentadas):

Listen 127.0.0.1:443
SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
# Note - I tried disabling SSLSessionCache with the "none" setting but it didn't help.
<VirtualHost 127.0.0.1:443>
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.crt
SSLCertificateKeyFile /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.key
SSLCertificateChainFile /var/certs/gentlemanjoe.com/new2011/gd_bundle.crt
SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
ServerAdmin [email protected]
DocumentRoot /var/www/gentlemanjoe.com
ServerName gentlemanjoe.com
<Directory /var/www/gentlemanjoe.com>
    AllowOverride All
    Order deny,allow
    allow from all
</Directory>          
</VirtualHost>

Cosas que he revisado

Primero intenté mover los viejos archivos cert y key a una carpeta completamente diferente para asegurarme de que Apache todavía no los estuviera agarrando de alguna manera. Nada ha cambiado. Por diversión, intenté renombrar temporalmente los nuevos archivos cert y key, y Apache se quejó obedientemente y se negó a comenzar.

Luego traté de asegurarme de que no me engañaran editando el archivo de configuración incorrecto. Usando "localizar" encontré solo un archivo httpd.conf en /etc/httpd/conf/httpd.conf. También utilicé "localizar" para verificar que solo hay un archivo ssl.conf, /etc/httpd/conf.d/ssl.conf. El archivo de clave es lo que generé usando OpenSSL, siguiendo las instrucciones que GoDaddy dio para generar la CSR.

Verifiqué que estoy trabajando con el sitio correcto cargando un archivo test.html en la carpeta /var/www/gentlemanjoe.com y verificando que puedo buscarlo. Pero si intento ver el archivo de prueba en HTTPS, aparece la misma advertencia de vencimiento del certificado.

Verifiqué que el certificado en sí tiene la fecha de vencimiento correcta:

openssl x509 -in /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.crt -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            07:e7:49:69:97:96:16
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority/serialNumber=07969287
        Validity
            Not Before: Oct 21 17:37:55 2011 GMT
            Not After : Oct  8 21:16:03 2013 GMT
        Subject: C=CA, ST=BC, L=Burnaby, O=Diamond Bailey Consolidated Commercial Services Ltd, OU= , CN=www.gentlemanjoe.com

Intenté volver a escribir el certificado en GoDaddy con una nueva CSR y todo parece funcionar, pero obtengo el mismo resultado en el navegador.

Posible pista # 1

Cada vez que hago "apachectl restart", veo esto en el archivo error_log:

[Fri Oct 21 18:03:33 2011] [notice] SIGHUP received.  Attempting to restart
[Fri Oct 21 18:03:33 2011] [notice] Digest: generating secret for digest authentication ...
[Fri Oct 21 18:03:33 2011] [notice] Digest: done
[Fri Oct 21 18:03:33 2011] [info] APR LDAP: Built with OpenLDAP LDAP SDK
[Fri Oct 21 18:03:33 2011] [info] LDAP: SSL support available
[Fri Oct 21 18:03:33 2011] [info] Init: Seeding PRNG with 256 bytes of entropy
[Fri Oct 21 18:03:33 2011] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Fri Oct 21 18:03:33 2011] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Fri Oct 21 18:03:33 2011] [info] Shared memory session cache initialised
[Fri Oct 21 18:03:33 2011] [info] Init: Initializing (virtual) servers for SSL
[Fri Oct 21 18:03:33 2011] [warn] RSA server certificate CommonName (CN) `www.gentlemanjoe.com' does NOT match server name!?
[Fri Oct 21 18:03:33 2011] [info] Server: Apache/2.2.3, Interface: mod_ssl/2.2.3, Library: OpenSSL/0.9.8e-fips-rhel5
[Fri Oct 21 18:03:34 2011] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations
[Fri Oct 21 18:03:34 2011] [info] Server built: Aug 30 2010 12:28:40

Los técnicos de GoDaddy me dicen que www vs non-www no debería importar, y tiendo a estar de acuerdo, ya que la advertencia de seguridad en mi navegador no se queja de una falta de coincidencia del nombre del servidor, sino de una caducidad , lo que indica que el certificado anterior aún siendo cargado de alguna manera.

Posible pista # 2

El encabezado de respuesta del servidor HTTP para http://gentlemanjoe.com dice "Andromeda" en lugar de "Apache". Esto me parece extraño ya que mi Google de "Andromeda" presenta un proyecto de tipo servidor de medios, que no se instalaría en este servidor (pero no puedo decirlo con certeza ya que no configuré nada de esto , el administrador / desarrollador habitual está de vacaciones y solo estoy ayudando a un amigo con su sitio.) Además, el archivo httpd.conf no contiene la cadena "Andromeda" que indica que no se ha modificado para escupir esto. Entonces, podría ser la plataforma de comercio electrónico Magento que está utilizando, pero ¿cuál sería el punto de reemplazar el encabezado de respuesta Apache estándar?

apache-2.2 ssl-certificate Jordan Rieger
fuente
¿Cuál es este error: el certificado del servidor RSA CommonName (CN) `www.gentlemanjoe.com 'NO coincide con el nombre del servidor !?
mdpc
No estoy realmente seguro, creo que se está quejando de que www.gentlemanjoe.com no coincide con gentlemanjoe.com, pero eso no explica por qué el sitio todavía usa un certificado caducado. Si solo se trata de un error de coincidencia de nombre común / nombre de servidor, ¿no vería eso reflejado en la advertencia de seguridad del navegador? El nuevo certificado no debería aparecer como caducado , pero con una advertencia diferente sobre el nombre mistmatch, ¿verdad?
Jordan Rieger

Respuestas:

17

Algo está frente a Apache. Echa un vistazo a esa configuración:

Listen 127.0.0.1:443
....
<VirtualHost 127.0.0.1:443>

Está escuchando solo en el host local, por lo que los clientes de Internet no están accediendo a este servicio directamente, es probable que se estén aproximando.

Para comprobar la cordura de que Apache está cargando el certificado correcto, acceda al servicio directamente en el oyente de Apache: openssl s_client -connect 127.0.0.1:443 -showcerts

No estoy seguro sobre la cabecera de Andrómeda, así, vamos a encontrar el proceso: lsof -i.

Apache tendrá 127.0.0.1:443, mientras que otro servicio tiene 0.0.0.0:443(o la dirección pública del VPS :443), ese es el que necesita el nuevo certificado.

Shane Madden
fuente
¡Si! Gracias Shane, eso fue muy lógico. Chico, esta fue una pregunta difícil. El proceso resultó ser un servidor proxy llamado nginx, escuchando en una dirección IP que ni siquiera sabía que estaba asociada con el servidor y luego transmitiendo solicitudes HTTPS y HTTP a Apache. No tengo idea de por qué el último chico pensó que era una buena idea, parece ser un cerdo de rendimiento sin sentido. Y nginx me exigió que reformatee los certificados que GoDaddy proporcionó para colocar el certificado del servidor y la cadena de autoridad en un archivo en un orden determinado. De todos modos, ¡funciona ahora! ¡Gracias!
Jordan Rieger
2
@JordanRieger ¡Qué bueno escuchar! En general, se considera que nginx es más liviano y rápido que Apache, por lo que podría ser un caso si maneja algunas solicitudes internamente (por ejemplo, el contenido estático) y pasa solo un subconjunto específico de solicitudes a Apache ... pero parece que es simplemente enviando todo a Apache, así que tienes razón, solo un desperdicio de rendimiento.
Shane Madden
En nuestro caso, fue AWS ELB.
Akshay
0

Una fuente común de este problema son las múltiples instancias en ejecución de Apache. Los cambios de configuración son recogidos por un proceso que usted (re) inicia pero la solicitud es atendida por un proceso antiguo que se ejecuta con la configuración anterior.

Detener el servicio:

service apache2 stop

Verifique si el sitio aún es accesible. En caso afirmativo, ha identificado la causa.

Ahora corre 

ps aux | grep apache

Le dará una lista de ejecución del proceso apache2 y sus PID. Mátalos a todos (tenga en cuenta que este comando también puede devolver procesos no relacionados con Apache en su nombre / usuario, etc., como Apache Tomcat, es posible que no desee matarlos).

kill <pid>

Ejecute ps aux nuevamente y asegúrese de que los procesos ya no se ejecuten.

Verifique nuevamente si el sitio es accesible. No debe ser

Ahora inicie el servicio apache

service apache2 start

Verifique que se esté sirviendo el nuevo certificado.

Si no desea eliminar procesos, puede reiniciar el sistema. Tendrá el mismo efecto.

Dojo
fuente