Apache 2.2.3 / mod_ssl / CentOS 5.5 VPS
Nosso certificado expirou em 06/10/2011 e, apesar de aparentemente termos instalado o novo corretamente, a navegação no site ainda mostra um certificado expirado! Tentei excluir o cache do navegador e usar vários navegadores diferentes. Linhas relevantes do arquivo ssl.conf (excluí as que foram comentadas.):
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>
Coisas que eu verifiquei
Primeiro, tentei mover o certificado antigo e os arquivos de chave para uma pasta completamente diferente para garantir que o Apache ainda não os estivesse pegando. Nada mudou. Por diversão, tentei renomear temporariamente o novo certificado e os arquivos de chave, e o Apache reclamou e se recusou a iniciar.
Depois, tentei me certificar de que não estava sendo enganado editando o arquivo de configuração errado. Usando "localizar", encontrei apenas um arquivo httpd.conf em /etc/httpd/conf/httpd.conf. Também usei "localizar" para verificar se há apenas um arquivo ssl.conf, /etc/httpd/conf.d/ssl.conf. O arquivo-chave é o que eu gerei usando o OpenSSL, seguindo as instruções que o GoDaddy deu para gerar o CSR.
Verifiquei que estou trabalhando com o site certo, enviando um arquivo test.html para a pasta /var/www/gentlemanjoe.com e verificando se consigo navegar nele. Mas se eu tentar visualizar o arquivo de teste em HTTPS, recebo o mesmo aviso de expiração de certificado.
Eu verifiquei que o certificado em si tem a data de vencimento correta:
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
Tentei redigitar o certificado no GoDaddy com um novo CSR e tudo parece funcionar, mas obtenho o mesmo resultado no navegador.
Possível pista nº 1
Sempre que eu faço "apachectl restart", vejo isso no arquivo 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
Os técnicos do GoDaddy me dizem que o www vs não-www não deve importar, e eu concordo, pois o aviso de segurança no meu navegador não está reclamando de uma incompatibilidade de nome de servidor, mas de uma expiração , indicando que o certificado antigo ainda está sendo carregado de alguma forma.
Possível pista 2
O cabeçalho de resposta do servidor HTTP para http://gentlemanjoe.com diz "Andromeda" em vez de "Apache". Isso me parece estranho, já que meu Google de "Andromeda" exibe um projeto do tipo servidor de mídia, que não seria instalado nesse servidor (mas não posso dizer isso com certeza, pois não configurei nada disso , o administrador / desenvolvedor habitual está de férias e estou apenas ajudando um amigo com o site dele.) Além disso, o arquivo httpd.conf não contém a string "Andromeda", indicando que não foi modificado para cuspir isso. Pode ser a plataforma de comércio eletrônico Magento que ele está usando, mas qual seria o sentido de substituir o cabeçalho de resposta padrão do Apache?
fonte
Respostas:
Algo está na frente do Apache. Confira essa configuração:
Ele está escutando apenas no host local, portanto, os clientes da Internet não estão acessando esse serviço diretamente - provavelmente estão recebendo proxy.
Para verificar se o Apache está carregando o certificado certo, acesse o serviço diretamente no ouvinte do Apache:
openssl s_client -connect 127.0.0.1:443 -showcertsNão tenho certeza sobre o cabeçalho Andromeda, por isso, vamos encontrar o processo:
lsof -i.O Apache terá
127.0.0.1:443, enquanto algum outro serviço possui0.0.0.0:443(ou o endereço público do VPS:443) - esse é o que precisa do novo certificado.fonte
Uma fonte comum desse problema são várias instâncias em execução do Apache. As alterações na configuração são identificadas por um processo que você (re) inicia, mas a solicitação é atendida por um processo antigo que está sendo executado com a configuração antiga.
Pare o serviço:
Verifique se o site ainda está acessível. Se sim, você identificou a causa.
Agora corra
Ele fornecerá uma lista do processo apache2 em execução e seus PIDs. Mate todos eles (observe, este comando também pode retornar processos não relacionados com o Apache em seus nomes / usuários etc., como o Apache Tomcat, você pode não querer matá-los.)
Execute o ps aux novamente e verifique se os processos não estão mais em execução.
Verifique novamente se o site está acessível. Não deveria ser.
Agora inicie o serviço apache
Verifique se o novo certificado está sendo veiculado.
Se você não deseja interromper os processos, pode reiniciar o sistema. Terá o mesmo efeito.
fonte