O Apache parece estar usando um certificado expirado antigo, mesmo que um novo esteja instalado


15

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

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?


O que é esse erro: O certificado do servidor RSA CommonName (CN) `www.gentlemanjoe.com 'NÃO corresponde ao nome do servidor !?
Mdpc

Não tenho muita certeza, acho que está reclamando que www.gentlemanjoe.com não corresponde a gentlemanjoe.com, mas isso não explica por que o site ainda está usando um certificado expirado. Se fosse apenas um erro de erro de correspondência de nome comum / nome do servidor, eu não veria isso refletido no aviso de segurança do navegador? O novo certificado não deve aparecer como expirado , mas com um aviso diferente sobre o nome Mistmatch, certo?
Jordan Rieger

Respostas:


17

Algo está na frente do Apache. Confira essa configuração:

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

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

Nã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 possui 0.0.0.0:443(ou o endereço público do VPS :443) - esse é o que precisa do novo certificado.


Sim! Obrigado Shane, isso foi muito lógico. Garoto, isso foi difícil. O processo acabou sendo um servidor proxy chamado nginx, escutando um endereço IP que eu nem sabia que estava associado ao servidor e depois retransmitindo solicitações HTTPS e HTTP para o Apache. Eu não tenho idéia do por que o último cara achou que era uma boa ideia, parece ser um porco sem desempenho. E o nginx exigiu que eu reformatasse os certificados fornecidos pelo GoDaddy para colocar o certificado do servidor e a cadeia de autoridade em um arquivo em uma determinada ordem. Enfim, ele funciona agora! Obrigado!
Jordan Rieger

2
@JordanRieger É bom ouvir! O nginx é geralmente considerado mais leve e mais rápido que o Apache; portanto, pode haver um caso para ele se estiver lidando com algumas solicitações internamente (por exemplo, o conteúdo estático) e passando apenas um subconjunto específico de solicitações para o Apache .. mas parece que é apenas enviando tudo para o Apache, então você está certo - apenas um desperdício de desempenho.
Shane Madden

No nosso caso, era o AWS ELB.
Akshay

0

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:

service apache2 stop

Verifique se o site ainda está acessível. Se sim, você identificou a causa.

Agora corra

ps aux | grep apache

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

kill <pid>

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

service apache2 start

Verifique se o novo certificado está sendo veiculado.

Se você não deseja interromper os processos, pode reiniciar o sistema. Terá o mesmo efeito.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.