It produced this output:
1: Attempt to reinstall this existing certificate
2: Renew & replace the certificate (may be subject to CA rate limits)
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Keeping the existing certificate
Deploying Certificate to VirtualHost /etc/httpd/conf.d/zabbix-le-ssl.conf
Enhancement redirect was already set.
Atualmente temos uma grande onda de pessoas em CentOS com Apache com esse mesmo problema.
Parece que tem algo a ver com o arquivo /etc/httpd/ssl.conf que cria um VirtualServer "padrão" (default) com um certificado autoassinado (assim não aceito por navegadores). Por algum motivo, o servidor Apache em CentOS usa esse VirtualServer no lugar do VirtualServer mais específico criado pelo Certbot.
Você entende configurar o Apache editando arquivos de configuração? Minha explicação é suficience para você, ou precisará de passos mais concretos?
Estou com dificuldades aqui porque eu realmente achava que a gente já havía solucionado esse problema há um ano ou mais, mas nessas últimas semanas voltou a afetar muitos usuários. (E não sei exatamente qual o melhor jeito de solucioná-lo de forma mais geral.)
Outra coisa, pela curiosidade de um colega sobre a origem desse problema (para todos), pode também mostrar a saída de
grep zabbix.imcnet.com.br /etc/hosts
?
É possível que a saida será vazia, ou poderá conter um endereço IP e o nome zabbix.imcnet.com.br. Esse colega acha que a saida seria a segunda opção (um endereço IP com o nome).
Obrigado, é útil para nós saber como isso esteja acontecendo...
Pode compartilhar o conteúdo do arquivo /etc/httpd/conf.d/ssl.conf? Acho que teremos que fazer uma mudança pequena nele para permitir que o servidor use o certificado Let's Encrypt.
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is sent or allowed to be received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is sent and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
Obrigado. Vamos aprendendo sobre o problema e suas informações ajudam nisso. Com certeza, teremos que falar com os desenvolvidores do CentOS para pedir umas mudanças no comportamento padrão dele.
Temos duas dicas pelo presente... as duas são "jeitinhos" (se entendi corretamente essa gíria brasileira), e não soluções "corretas".
(1) Abrindo o arquivo ssl.conf num editor de texto, pode apagar o # do começa da línha
#ServerName www.example.com:443
ou seja, mudando para
ServerName www.example.com:443
O efeito disso (que esperamos) seria limitar o ámbito desse VirtualHost (com o certificado autoassinado) apenas para o nome www.example.com, que não existe no seu servidor e assim nunca será usado na prática.
Logo, teria que reiniciar o httpd (sudo service httpd reload ou parecido).
Se isso não der certo, a segunda dica:
(2) Mover o arquivo /etc/httpd/conf.d/ssl.conf para outro lugar fora de /etc/httpd/conf.d. Um exemplo possível:
sudo mv -i /etc/httpd/conf.d/ssl.conf /root
No outro lugar, esse arquivo não terá efeito nenhum! (Mas ainda existirá, se precisar do conteúdo dele em algum momento no futuro.)
