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 [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>
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?
la source
Réponses:
Quelque chose est devant Apache. Découvrez cette configuration:
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 -showcertsPas 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 ont0.0.0.0:443(ou l'adresse publique du VPS:443) - c'est celui qui a besoin du nouveau certificat.la source
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:
Vérifiez si le site est toujours accessible. Si oui, alors vous avez identifié la cause.
Maintenant, lancez
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.)
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
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.
la source