Apache semble utiliser l'ancien certificat expiré même si un nouveau est installé


15

Apache 2.2.3 / mod_ssl / CentOS 5.5 VPS

Notre certificat a expiré le 2011-10-06, et même si nous avons apparemment installé le nouveau correctement, la navigation sur le site montre toujours un certificat expiré! J'ai essayé de supprimer le cache de mon navigateur et d'utiliser plusieurs navigateurs différents. Lignes pertinentes du fichier ssl.conf (j'ai exclu celles commentées.):

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 webmaster@donotemailme.com
DocumentRoot /var/www/gentlemanjoe.com
ServerName gentlemanjoe.com
<Directory /var/www/gentlemanjoe.com>
    AllowOverride All
    Order deny,allow
    allow from all
</Directory>          
</VirtualHost>

Choses que j'ai vérifiées

J'ai d'abord essayé de déplacer les anciens fichiers de certificats et de clés vers un dossier complètement différent pour m'assurer qu'Apache ne les saisissait toujours pas. Rien n'a changé. Pour le plaisir, j'ai essayé de renommer temporairement les nouveaux fichiers de certificats et de clés, et Apache s'est plaint consciencieusement et a refusé de commencer.

Ensuite, j'ai essayé de m'assurer que je n'étais pas dupe en modifiant le mauvais fichier de configuration. En utilisant "Locate", je n'ai trouvé qu'un seul fichier httpd.conf sous /etc/httpd/conf/httpd.conf. J'ai également utilisé "Locate" pour vérifier qu'il n'y a qu'un seul fichier ssl.conf, /etc/httpd/conf.d/ssl.conf. Le fichier de clé est ce que j'ai généré à l'aide d'OpenSSL, en suivant les instructions que GoDaddy a données pour générer la CSR.

J'ai vérifié que je travaille avec le bon site en téléchargeant un fichier test.html dans le dossier /var/www/gentlemanjoe.com et en vérifiant que je peux y accéder. Mais si j'essaie d'afficher le fichier de test en HTTPS, j'obtiens le même avertissement d'expiration de certificat.

J'ai vérifié que le certificat lui-même a la bonne date d'expiration:

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

J'ai essayé de retaper le certificat chez GoDaddy avec une nouvelle CSR et tout semble fonctionner, mais j'obtiens le même résultat dans le navigateur.

Indice possible n ° 1

Chaque fois que je fais "apachectl restart", je vois cela dans le fichier 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

Les techniciens GoDaddy me disent que le www vs non-www ne devrait pas avoir d'importance, et j'ai tendance à être d'accord, car l'avertissement de sécurité dans mon navigateur ne se plaint pas d'une incompatibilité de nom de serveur, mais plutôt d'une expiration , indiquant que l'ancien certificat est toujours être chargé en quelque sorte.

Indice possible n ° 2

L'en-tête de réponse du serveur HTTP pour http://gentlemanjoe.com indique "Andromeda" plutôt que "Apache". Cela me semble bizarre puisque mon googler "Andromeda" se présente comme un projet de type serveur multimédia, qui ne serait pas installé sur ce serveur (mais je ne peux pas le dire avec certitude car je n'ai rien configuré de tout cela) , l'administrateur / développeur habituel est en vacances et j'aide juste un ami avec son site.) De plus, le fichier httpd.conf ne contient pas la chaîne "Andromeda" indiquant qu'il n'a pas été modifié pour cracher cela. Il pourrait donc s'agir de la plate-forme de commerce électronique Magento qu'il utilise, mais à quoi servirait de remplacer l'en-tête de réponse Apache standard?


Quelle est cette erreur: le certificat de serveur RSA CommonName (CN) `www.gentlemanjoe.com 'ne correspond pas au nom du serveur!?
mdpc

Je ne suis pas vraiment sûr, je pense que cela se plaint que www.gentlemanjoe.com ne correspond pas à gentlemanjoe.com, mais cela n'explique pas pourquoi le site utilise toujours un certificat expiré. S'il ne s'agissait que d'une erreur de correspondance de nom commun / nom de serveur, ne verrais-je pas cela dans l'avertissement de sécurité du navigateur? Le nouveau certificat ne devrait pas apparaître comme expiré , mais avec un avertissement différent sur le nom de la correspondance erronée, non?
Jordan Rieger

Réponses:


17

Quelque chose est devant Apache. Découvrez cette configuration:

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

Il écoute uniquement sur localhost, de sorte que les clients Internet ne consultent pas directement ce service - ils sont probablement mandatés.

Pour vérifier si Apache charge le bon certificat, appuyez directement sur le service d'écoute d'Apache: openssl s_client -connect 127.0.0.1:443 -showcerts

Pas sûr de l' en- tête d' Andromède, donc, nous allons trouver le processus: lsof -i.

Apache aura 127.0.0.1:443, tandis que certains autres services ont 0.0.0.0:443(ou l'adresse publique du VPS :443) - c'est celui qui a besoin du nouveau certificat.


Oui! Merci Shane, c'était très logique. C'était difficile. Le processus s'est avéré être un serveur proxy appelé nginx, écoutant une adresse IP que je ne savais même pas associée au serveur, puis relayant les requêtes HTTPS et HTTP à Apache. Je ne sais pas pourquoi le dernier gars a pensé que c'était une bonne idée, cela semble être un porc de performance inutile. Et nginx m'a demandé de reformater les certificats fournis par GoDaddy pour mettre le certificat du serveur et la chaîne d'autorité dans un fichier dans un certain ordre. Quoi qu'il en soit, cela fonctionne maintenant! Je vous remercie!
Jordan Rieger

2
@JordanRieger Bon à entendre! nginx est généralement considéré comme plus léger et plus rapide qu'Apache, donc il pourrait y avoir un cas s'il gère certaines demandes en interne (par exemple, le contenu statique) et en ne transmettant qu'un sous-ensemble spécifique de demandes à Apache .. mais il semble que ce soit envoyer tout simplement à Apache, donc vous avez raison - juste un gaspillage de performances.
Shane Madden

Dans notre cas, c'était AWS ELB.
Akshay

0

Une source courante de ce problème est plusieurs instances en cours d'exécution d'Apache. Les changements de configuration sont récupérés par un processus que vous (re) démarrez mais la demande est servie par un ancien processus qui s'exécute avec l'ancienne configuration.

Arrêtez le service:

service apache2 stop

Vérifiez si le site est toujours accessible. Si oui, alors vous avez identifié la cause.

Maintenant, lancez

ps aux | grep apache

Il vous donnera la liste des processus apache2 en cours d'exécution et leurs PID. Tuez-les tous (Remarque, cette commande peut également renvoyer des processus non liés avec Apache dans leur nom / utilisateur, etc. comme Apache Tomcat, vous ne voudrez peut-être pas les tuer.)

kill <pid>

Exécutez à nouveau ps aux et assurez-vous que les processus ne sont plus en cours d'exécution.

Vérifiez à nouveau si le site est accessible. Ça ne devrait pas l'être.

Maintenant, démarrez le service apache

service apache2 start

Vérifiez que le nouveau certificat est servi.

Si vous ne voulez pas tuer les processus, vous pouvez redémarrer le système. Cela aura le même effet.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.