Apache 2.2.3 / mod_ssl / CentOS 5.5 VPS
Nasz certyfikat wygasł w dniu 10.10.2011 i chociaż pozornie poprawnie zainstalowaliśmy nowy, przeglądanie strony nadal pokazuje wygasły certyfikat! Próbowałem usunąć pamięć podręczną przeglądarki i korzystać z kilku różnych przeglądarek. Odpowiednie wiersze z pliku ssl.conf (wykluczyłem te skomentowane.):
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>
Rzeczy, które sprawdziłem
Najpierw próbowałem przenieść stare pliki certyfikatów i kluczy do zupełnie innego folderu, aby upewnić się, że Apache nadal ich nie chwyta. Nic się nie zmieniło. Dla zabawy próbowałem tymczasowo zmienić nazwę nowego pliku certyfikatu i klucza, a Apache posłusznie narzekał i odmówił uruchomienia.
Następnie starałem się upewnić, że nie daję się oszukać, edytując niewłaściwy plik konfiguracyjny. Używając „zlokalizuj” znalazłem tylko jeden plik httpd.conf pod /etc/httpd/conf/httpd.conf. Użyłem również „locate”, aby sprawdzić, czy istnieje tylko jeden plik ssl.conf, /etc/httpd/conf.d/ssl.conf. Plik klucza wygenerowałem za pomocą OpenSSL, postępując zgodnie z instrukcjami GoDaddy dotyczącymi generowania CSR.
Potwierdziłem, że pracuję z właściwą witryną, przesyłając plik test.html do folderu /var/www/gentlemanjoe.com i sprawdzając, czy mogę do niego przejść. Ale jeśli spróbuję wyświetlić plik testowy w HTTPS, otrzymam to samo ostrzeżenie o wygaśnięciu certyfikatu.
Zweryfikowałem, że sam certyfikat ma właściwą datę ważności:
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
Próbowałem ponownie wprowadzić klucz do certyfikatu w GoDaddy za pomocą nowego CSR i wszystko wydaje się działać, ale otrzymuję ten sam wynik w przeglądarce.
Możliwa wskazówka nr 1
Ilekroć wykonuję „restart Apachectl”, widzę to w pliku dziennika 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
Technicy GoDaddy mówią mi, że www kontra inne niż www nie powinny mieć znaczenia, i raczej się zgadzam, ponieważ ostrzeżenie bezpieczeństwa w mojej przeglądarce nie narzeka na niedopasowanie nazwy serwera, ale raczej na wygaśnięcie , wskazując, że stary certyfikat jest nadal jakoś ładowany.
Możliwa wskazówka nr 2
Nagłówek odpowiedzi serwera HTTP dla http://gentlemanjoe.com mówi „Andromeda” zamiast „Apache”. Wydaje mi się to dziwne, ponieważ mój Googling „Andromeda” ujawnia projekt typu serwer medialny, który nie zostałby zainstalowany na tym serwerze (ale nie mogę tego powiedzieć z całą pewnością, ponieważ nie skonfigurowałem żadnego z nich , zwykły administrator / programista jest na wakacjach, a ja tylko pomagam znajomemu w jego witrynie.) Ponadto plik httpd.conf nie zawiera ciągu „Andromeda” wskazującego, że nie został zmodyfikowany, aby to wypluć. Więc może to jest platforma e-commerce Magento, z której korzysta, ale jaki byłby sens zastąpienia standardowego nagłówka odpowiedzi Apache?
źródło
Odpowiedzi:
Coś jest przed Apache. Sprawdź tę konfigurację:
Nasłuchuje tylko na localhost, więc klienci internetowi nie korzystają bezpośrednio z tej usługi - prawdopodobnie uzyskują dostęp do serwera proxy.
Aby sprawdzić poczytalność, że Apache ładuje odpowiedni certyfikat, kliknij usługę bezpośrednio na odbiorniku Apache:
openssl s_client -connect 127.0.0.1:443 -showcertsNie jestem pewien co do nagłówka Andromeda, więc znajdźmy proces:
lsof -i.Apache będzie miał
127.0.0.1:443, podczas gdy inne usługi mają0.0.0.0:443(lub adres publiczny VPS:443) - to ten, który potrzebuje nowego certyfikatu.źródło
Częstym źródłem tego problemu jest wiele uruchomionych instancji Apache. Zmiany konfiguracji są odbierane przez proces, który uruchamiasz (ponownie), ale żądanie jest obsługiwane przez stary proces, który działa ze starą konfiguracją.
Zatrzymaj usługę:
Sprawdź, czy strona jest nadal dostępna. Jeśli tak, to określiłeś przyczynę.
Teraz biegnij
Otrzymasz listę uruchomionych procesów Apache2 i ich PID. Zabij ich wszystkich (uwaga: to polecenie może również zwrócić niepowiązane procesy z Apache w nazwie / użytkowniku itp., Takim jak Apache Tomcat, możesz nie chcieć ich zabić).
Uruchom ponownie ps aux i upewnij się, że procesy już nie działają.
Sprawdź ponownie, czy strona jest dostępna. Nie powinno tak być.
Teraz uruchom usługę Apache
Sprawdź, czy nowy certyfikat jest obsługiwany.
Jeśli nie chcesz zabijać procesów, możesz zrestartować system. Będzie miał ten sam efekt.
źródło