Wygląda na to, że Apache używa starego, wygasłego certyfikatu, mimo że nowy jest zainstalowany


15

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 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>

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?


Co to za błąd: certyfikat serwera RSA CommonName (CN) `www.gentlemanjoe.com 'NIE pasuje do nazwy serwera !?
mdpc,

Nie jestem do końca pewien, myślę, że narzeka, że ​​www.gentlemanjoe.com nie pasuje do gentlemanjoe.com, ale to nie wyjaśnia, dlaczego strona nadal używa wygasłego certyfikatu. Gdyby to był tylko błąd polegający na błędnym dopasowaniu nazwy / nazwy serwera, czy nie zobaczyłbym tego w ostrzeżeniu dotyczącym bezpieczeństwa przeglądarki? Nowy certyfikat nie powinien pojawiać się jako wygasły , ale z innym ostrzeżeniem o nazwie mistmatch, prawda?
Jordan Rieger

Odpowiedzi:


17

Coś jest przed Apache. Sprawdź tę konfigurację:

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

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 -showcerts

Nie 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.


Tak! Dziękuję Shane, to było bardzo logiczne. Chłopak, to było trudne. Okazało się, że jest to serwer proxy o nazwie nginx, nasłuchujący na adresie IP, o którym nawet nie wiedziałem, że jest powiązany z serwerem, a następnie przekazujący żądania HTTPS i HTTP do Apache. Nie mam pojęcia, dlaczego ostatni facet pomyślał, że to dobry pomysł, wydaje się, że to bezsensowny świnia. Nginx wymagał ode mnie sformatowania certyfikatów dostarczonych przez GoDaddy, aby umieścić certyfikat serwera i łańcuch uprawnień w jednym pliku w określonej kolejności. W każdym razie działa teraz! Dziękuję Ci!
Jordan Rieger

2
@JordanRieger Dobrze słyszeć! nginx jest ogólnie uważany za lżejszy i szybszy niż Apache, więc może tak być, jeśli obsługuje on niektóre żądania wewnętrznie (powiedzmy, zawartość statyczną) i przekazuje tylko określony podzbiór żądań do Apache. po prostu wysyłając wszystko do Apache, więc masz rację - tylko marnowanie wydajności.
Shane Madden

W naszym przypadku był to AWS ELB.
Akshay

1

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ę:

service apache2 stop

Sprawdź, czy strona jest nadal dostępna. Jeśli tak, to określiłeś przyczynę.

Teraz biegnij

ps aux | grep apache

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ć).

kill <pid>

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

service apache2 start

Sprawdź, czy nowy certyfikat jest obsługiwany.

Jeśli nie chcesz zabijać procesów, możesz zrestartować system. Będzie miał ten sam efekt.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.