Apache scheint ein altes abgelaufenes Zertifikat zu verwenden, obwohl ein neues installiert ist


15

Apache 2.2.3 / mod_ssl / CentOS 5.5 VPS

Unser Zertifikat ist am 06.10.2011 abgelaufen. Auch wenn wir das neue scheinbar korrekt installiert haben, zeigt das Surfen auf der Website immer noch ein abgelaufenes Zertifikat an! Ich habe versucht, meinen Browser-Cache zu löschen und mehrere verschiedene Browser zu verwenden. Relevante Zeilen aus der ssl.conf-Datei (die auskommentierten habe ich ausgeschlossen.):

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>

Dinge, die ich überprüft habe

Zuerst habe ich versucht, die alten Zertifikats- und Schlüsseldateien in einen völlig anderen Ordner zu verschieben, um sicherzustellen, dass Apache sie nicht noch irgendwie abruft. Nichts hat sich verändert. Aus Spaß habe ich versucht, die neuen Zertifikats- und Schlüsseldateien vorübergehend umzubenennen, und Apache hat sich pflichtbewusst beschwert und den Start abgelehnt.

Dann habe ich versucht, mich nicht täuschen zu lassen, indem ich die falsche Konfigurationsdatei bearbeitet habe. Mit "locate" fand ich nur eine httpd.conf-Datei unter /etc/httpd/conf/httpd.conf. Ich habe auch "locate" verwendet, um zu überprüfen, ob es nur eine ssl.conf-Datei gibt, /etc/httpd/conf.d/ssl.conf. Die Schlüsseldatei habe ich mit OpenSSL generiert. Dabei habe ich die Anweisungen von GoDaddy zum Generieren der CSR befolgt.

Ich habe überprüft, ob ich mit der richtigen Site arbeite, indem ich eine test.html-Datei in den Ordner /var/www/gentlemanjoe.com hochgeladen und überprüft habe, ob ich darauf zugreifen kann. Wenn ich jedoch versuche, die Testdatei in HTTPS anzuzeigen, wird dieselbe Warnung zum Ablauf des Zertifikats angezeigt.

Ich habe überprüft, ob das Zertifikat selbst das richtige Ablaufdatum hat:

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

Ich habe versucht, das Zertifikat bei GoDaddy mit einer neuen CSR zu tasten, und alles scheint zu funktionieren, aber ich erhalte das gleiche Ergebnis im Browser.

Möglicher Hinweis # 1

Wann immer ich "apachectl restart" mache, sehe ich dies in der error_log-Datei:

[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

Die GoDaddy-Techniker sagen mir, dass das Www und das Nicht-Www keine Rolle spielen sollten, und ich stimme dem eher zu, da die Sicherheitswarnung in meinem Browser nicht die Nichtübereinstimmung von Servernamen beanstandet, sondern einen Ablauf , der anzeigt, dass das alte Zertifikat noch vorhanden ist irgendwie geladen werden.

Möglicher Hinweis # 2

Der HTTP-Server-Antwortheader für http://gentlemanjoe.com lautet "Andromeda" und nicht "Apache". Das kommt mir komisch vor, da mein Googeln von "Andromeda" ein Medienserver-Projekt aufwirft, das auf diesem Server nicht installiert werden würde (aber das kann ich nicht mit Sicherheit sagen, da ich nichts davon eingerichtet habe , der übliche Administrator / Entwickler ist im Urlaub und ich helfe nur einem Freund mit seiner Site.) Außerdem enthält die httpd.conf-Datei nicht die Zeichenfolge "Andromeda", die angibt, dass sie nicht geändert wurde, um dies auszuspucken. Es könnte also die von ihm verwendete Magento-E-Commerce-Plattform sein, aber wozu sollte der standardmäßige Apache-Antwortheader ersetzt werden?


Was ist dieser Fehler: Das RSA-Serverzertifikat CommonName (CN) `www.gentlemanjoe.com 'stimmt NICHT mit dem Servernamen überein !?
mdpc

Ich bin mir nicht sicher, ich denke, es beklagt sich, dass www.gentlemanjoe.com nicht mit gentlemanjoe.com übereinstimmt, aber das erklärt nicht, warum auf der Website immer noch ein abgelaufenes Zertifikat verwendet wird. Wenn es sich nur um einen allgemeinen Namens- / Servernamensfehler handelte, würde ich das nicht in der Sicherheitswarnung des Browsers sehen? Das neue Zertifikat sollte nicht als abgelaufen angezeigt werden, sondern mit einer anderen Warnung zum Namen mistmatch, oder?
Jordan Rieger

Antworten:


17

Etwas ist vor Apache. Schau dir diese Konfiguration an:

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

Es wird nur auf localhost abgehört, sodass Internet-Clients diesen Service nicht direkt nutzen - sie werden wahrscheinlich von Proxyservern vertreten.

Um zu überprüfen, ob Apache das richtige Zertifikat lädt, rufen Sie den Dienst direkt beim Apache-Listener auf: openssl s_client -connect 127.0.0.1:443 -showcerts

Nicht sicher über die Andromeda - Header, so wollen wir den Prozess finden: lsof -i.

Apache wird haben 127.0.0.1:443, während ein anderer Dienst hat 0.0.0.0:443(oder die öffentliche Adresse des VPS :443) - das ist derjenige, der das neue Zertifikat benötigt.


Ja! Danke Shane, das war sehr logisch. Junge, das war eine schwierige Frage. Es stellte sich heraus, dass es sich um einen Proxyserver namens nginx handelte, der eine IP-Adresse abhörte, von der ich nicht einmal wusste, dass sie mit dem Server verknüpft war, und dann HTTPS- und HTTP-Anforderungen an Apache weiterleitete . Ich habe keine Ahnung, warum der letzte Mann das für eine gute Idee hielt, es scheint ein sinnloses Leistungsschwein zu sein. Und nginx forderte mich auf, die von GoDaddy bereitgestellten Zertifikate neu zu formatieren, um das Serverzertifikat und die Zertifizierungsstellenkette in einer bestimmten Reihenfolge in einer Datei abzulegen. Sowieso funktioniert es jetzt! Vielen Dank!
Jordan Rieger

2
@JordanRieger Schön zu hören! nginx gilt allgemein als leichter und schneller als Apache. Es kann also durchaus sinnvoll sein, einige Anforderungen intern zu verarbeiten (z. B. den statischen Inhalt) und nur eine bestimmte Teilmenge von Anforderungen an Apache zu übergeben Senden Sie einfach alles an Apache, damit Sie Recht haben - nur eine Verschwendung von Leistung.
Shane Madden

In unserem Fall war es AWS ELB.
Akshay

0

Eine häufige Ursache für dieses Problem sind mehrere laufende Instanzen von Apache. Die Konfigurationsänderungen werden von einem Prozess übernommen, den Sie (neu) starten, aber die Anforderung wird von einem alten Prozess bedient, der mit alter Konfiguration ausgeführt wird.

Beenden Sie den Dienst:

service apache2 stop

Überprüfen Sie, ob die Site noch zugänglich ist. Wenn ja, haben Sie die Ursache identifiziert.

Jetzt lauf

ps aux | grep apache

Sie erhalten eine Liste der ausgeführten Apache2-Prozesse und ihrer PIDs. Töte sie alle (Beachten Sie, dass dieser Befehl möglicherweise auch nicht verwandte Prozesse mit Apache in ihrem Namen / Benutzer usw. zurückgibt, wie z. B. Apache Tomcat. Möglicherweise möchten Sie sie nicht töten.)

kill <pid>

Führen Sie ps aux erneut aus und stellen Sie sicher, dass keine Prozesse mehr ausgeführt werden.

Überprüfen Sie erneut, ob die Site zugänglich ist. Das sollte nicht sein.

Starten Sie nun den Apache-Dienst

service apache2 start

Stellen Sie sicher, dass das neue Zertifikat bereitgestellt wird.

Wenn Sie keine Prozesse beenden möchten, können Sie das System neu starten. Es wird den gleichen Effekt haben.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.