Esse certificado nao pode ser verificado junto a uma autoridade confiavel

My domain is: http://zabbix.imcnet.com.br

I ran this command: Certbot - Centosrhel8 Apache

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.


Congratulations! You have successfully enabled https://zabbix.imcnet.com.br


IMPORTANT NOTES:

My web server is (include version): Apache/2.4.37 (centos)

The operating system my web server runs on is (include version): CentOS Linux release 8.3
My hosting provider, if applicable, is: MINDNET

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.13.0

Oi @Joanessp,

Atualmente temos uma grande onda de pessoas em CentOS com Apache com esse mesmo problema. :frowning:

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. :frowning: (E n√£o sei exatamente qual o melhor jeito de solucion√°-lo de forma mais geral.)

Ola,

Em primeiro lugar agradeço o rápido retorno e atenção !

Sou realmente leigo quando o assunto se trata de apache, teria algum link para indicar? Seria de grande ajuda !

Quero encontrar uma solução geral para todos os usuários do CentOS com esse mesmo problema, mas não tenho uma por enquanto.

Pode mostrar a saida de executar

sudo httpd -t -D DUMP_VHOSTS

?

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.

cat /etc/httpd/conf.d/ssl.conf

Desculpe, segue saida do arquivo ssl.conf:

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

Acho que só foi uma parte do arquivo, porque termina com </VirtualHost> (fechar VirtualHost) mas não começa com <VirtualHost> (abrir 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.)

Aqui também teria que reiniciar o httpd.

1 Like

Obrigado! :grinning:

Parab√©ns! E obrigado por compartilhar todas as informa√ß√Ķes acima.

Acho que n√£o, esse jeitinho, mesmo sendo imperfeito, deveria ser duradouro. :slight_smile:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.