Apache sembra utilizzare il vecchio certificato scaduto anche se ne è installato uno nuovo


15

Apache 2.2.3 / mod_ssl / CentOS 5.5 VPS

Il nostro certificato è scaduto il 06/10/2011 e, sebbene apparentemente abbiamo installato quello nuovo correttamente, la navigazione sul sito mostra ancora un certificato scaduto! Ho provato a eliminare la cache del browser e a utilizzare diversi browser. Righe pertinenti dal file ssl.conf (ho escluso quelle commentate.):

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>

Cose che ho controllato

Per prima cosa ho provato a spostare i vecchi file di certificati e chiavi in ​​una cartella completamente diversa per assicurarmi che Apache non li stesse ancora afferrando in qualche modo. Niente è cambiato. Per divertimento ho provato a rinominare temporaneamente i nuovi file cert e key e Apache si è lamentato e si è rifiutato di iniziare.

Quindi ho cercato di assicurarmi di non essere stato ingannato modificando il file di configurazione errato. Usando "individuare" ho trovato solo un file httpd.conf in /etc/httpd/conf/httpd.conf. Ho anche usato "individuare" per verificare che ci sia un solo file ssl.conf, /etc/httpd/conf.d/ssl.conf. Il file chiave è quello che ho generato usando OpenSSL, seguendo le istruzioni fornite da GoDaddy per generare il CSR.

Ho verificato che sto lavorando con il sito giusto caricando un file test.html nella cartella /var/www/gentlemanjoe.com e verificando che posso accedervi. Ma se provo a visualizzare il file di prova in HTTPS, ricevo lo stesso avviso di scadenza del certificato.

Ho verificato che il certificato stesso abbia la data di scadenza corretta:

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

Ho provato a digitare nuovamente il certificato in GoDaddy con un nuovo CSR e tutto sembra funzionare, ma ottengo lo stesso risultato nel browser.

Possibile indizio n. 1

Ogni volta che faccio "apachectl restart", vedo questo nel file 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

I tecnici di GoDaddy mi dicono che il www vs non-www non dovrebbe importare, e tendo ad essere d'accordo, poiché l'avviso di sicurezza nel mio browser non si lamenta di una mancata corrispondenza del nome del server, ma piuttosto di una scadenza , indicando che il vecchio certificato è ancora essere caricato in qualche modo.

Possibile indizio n. 2

L'intestazione della risposta del server HTTP per http://gentlemanjoe.com dice "Andromeda" anziché "Apache". Questo mi sembra strano dal momento che il mio Google di "Andromeda" rivela un progetto di tipo media-server, che non sarebbe installato su questo server (ma non posso dirlo con certezza poiché non ho impostato nulla di tutto ciò , il solito amministratore / sviluppatore è in vacanza e sto solo aiutando un amico con il suo sito.) Inoltre, il file httpd.conf non contiene la stringa "Andromeda" che indica che non è stato modificato per sputarlo. Quindi potrebbe essere la piattaforma di e-commerce Magento che sta utilizzando, ma quale sarebbe il punto di sostituire l'intestazione di risposta standard di Apache?


Che cos'è questo errore: il certificato del server RSA CommonName (CN) `www.gentlemanjoe.com 'NON corrisponde al nome del server !?
mdpc,

Non ne sono davvero sicuro, penso che si stia lamentando che www.gentlemanjoe.com non corrisponda a gentlemanjoe.com, ma ciò non spiega perché il sito stia ancora utilizzando un certificato scaduto. Se fosse solo un errore mistmatch nome comune / nome server, non vedrei ciò riflesso nell'avviso di sicurezza del browser? Il nuovo certificato non dovrebbe apparire come scaduto , ma con un avviso diverso sul nome mistmatch, giusto?
Jordan Rieger,

Risposte:


17

C'è qualcosa di fronte ad Apache. Dai un'occhiata a quella configurazione:

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

È in ascolto solo su localhost, quindi i client Internet non stanno colpendo direttamente questo servizio - probabilmente stanno subendo un proxy.

Per la sanità mentale verifica che Apache stia caricando il certificato corretto, premi il servizio direttamente sul listener di Apache: openssl s_client -connect 127.0.0.1:443 -showcerts

Non sono sicuro circa l'intestazione Andromeda, così, cerchiamo di trovare il processo: lsof -i.

Apache avrà 127.0.0.1:443, mentre qualche altro servizio ha 0.0.0.0:443(o l'indirizzo pubblico del VPS :443) - quello è quello che ha bisogno del nuovo certificato.


Sì! Grazie Shane, è stato molto logico. Ragazzo questo è stato difficile. Il processo si è rivelato essere un server proxy chiamato nginx, ascoltando un indirizzo IP che non sapevo nemmeno fosse associato al server e quindi inoltrando le richieste HTTPS e HTTP ad Apache. Non ho idea del perché l'ultimo ragazzo abbia pensato che fosse una buona idea, sembra essere un inutile maiale delle prestazioni. E nginx mi ha richiesto di riformattare i certificati forniti da GoDaddy per inserire il certificato del server e la catena di autorità in un file in un determinato ordine. Ad ogni modo, ora funziona! Grazie!
Jordan Rieger,

2
@JordanRieger Buono a sapersi! nginx è generalmente considerato più leggero e più veloce di Apache, quindi potrebbe esserci un caso se sta gestendo alcune richieste internamente (diciamo, il contenuto statico) e passando ad Apache solo un sottoinsieme specifico di richieste .. ma sembra che sia inviando tutto ad Apache, quindi hai ragione, solo uno spreco di prestazioni.
Shane Madden

Nel nostro caso, era AWS ELB.
Akshay,

0

Una fonte comune di questo problema sono più istanze in esecuzione di Apache. Le modifiche alla configurazione vengono rilevate da un processo che si riavvia, ma la richiesta viene fornita da un vecchio processo in esecuzione con la vecchia configurazione.

Interrompere il servizio:

service apache2 stop

Controlla se il sito è ancora accessibile. Se sì, allora hai identificato la causa.

Adesso corri

ps aux | grep apache

Ti fornirà un elenco di processi apache2 in esecuzione e dei loro PID. Uccidili tutti (Nota, questo comando può anche restituire processi non correlati con Apache nel loro nome / utente ecc. Come Apache Tomcat, potresti non volerlo uccidere.)

kill <pid>

Eseguire di nuovo ps aux e assicurarsi che i processi non siano più in esecuzione.

Controlla di nuovo se il sito è accessibile. Non dovrebbe essere.

Ora avvia il servizio apache

service apache2 start

Verificare che il nuovo certificato sia stato offerto.

Se non si desidera interrompere i processi, è possibile riavviare il sistema. Avrà lo stesso effetto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.