Erro ao Renovar Certificado

Help Ajuda (em português)
1

Tenho um certificado Lets e ao realizar o scheduler da renovação automática, aconteceu o seguinte erro:

Comando na cron: /usr/bin/certbot renew

Saída:
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/laboratorio.hsvp.com.br/fullchain.pem (failure)

Processing /etc/letsencrypt/renewal/laboratorio.hsvp.com.br.conf

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/laboratorio.hsvp.com.br/fullchain.pem (failure)

Processing /etc/letsencrypt/renewal/laboratorio.hsvp.com.br.conf

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/laboratorio.hsvp.com.br/fullchain.pem (failure)

Lendo em alguns tópicos, este erro pode ocorrer por conta da geração do certificado. Estou trabalhando com um Tomcat, na LocalWeb. O comando que utilizei para gerar o certificado foi:

certbot certonly --manual --preferred-challenges dns-01 -d laboratorio.hsvp.com.br --server https://acme-v02.api.letsencrypt.org/directory --register-unsafely-without-email

Pelo que vi nos tópicos, com esse parâmetro --manual, ele não permite que seja executado nada que não seja manual. Como eu posso realizar a correção para que o site volte a ficar operacional?

Posso ler respostas em inglês: Sim.

Meu nome de domínio é: laboratorio.hsvp.com.br

Executei esse comando: Estão acima.

Produziu essa saída: Estão acima.

Meu servidor web é (com versão):

[root@vps15808 ~]# cat /etc/release
CentOS Linux release 7.6.1810 (Core)
Derived from Red Hat Enterprise Linux 7.6 (Source)
NAME=“CentOS Linux”
VERSION=“7 (Core)”
ID=“centos”
ID_LIKE=“rhel fedora”
VERSION_ID=“7”
PRETTY_NAME=“CentOS Linux 7 (Core)”
ANSI_COLOR=“0;31”
CPE_NAME=“cpe:/o:centos:centos:7”
HOME_URL=“https://www.centos.org/”
BUG_REPORT_URL=“https://bugs.centos.org/”

CENTOS_MANTISBT_PROJECT=“CentOS-7”
CENTOS_MANTISBT_PROJECT_VERSION=“7”
REDHAT_SUPPORT_PRODUCT=“centos”
REDHAT_SUPPORT_PRODUCT_VERSION=“7”

CentOS Linux release 7.6.1810 (Core)
CentOS Linux release 7.6.1810 (Core)

O sistema operacional no meu servidor web é (com versão):

O serviço de hospedagem do meu site (se aplicável) é: LocalWeb

Posso acessar um shell root na minha máquina (sim ou não, ou não sei): Sim

Uso um painel de controle para administrar meu site (não, ou indique o nome e a versão do painel de controle): Não, mas o cliente tem acesso.

Agradeço desde já.

2

Bom dia @MaikeCristian11,

Obrigado por acrescentar tantos detalhes.

É verdade que a opção --manual refere a um processo de verificação manual, que não é compatível com a renovação automática, já que o Certbot teria que informar os passos a serem seguidos, que não é possível num cronjob, que não tem nenhum usuário presente ao vivo para seguir essos passos.

Você pode fazer uma renovação interativa e não-automática re-executando o comando original.

A dificuldade é que com o dns-01 você tem que atualizar um registro DNS a cada renovação do certificado. Não é suficiente manter o registro da emissão inicial do certificado, porque a AC quer verificar seu controle contínuo sobre o nome de domínio.

Na sua configuração, talvez teria a opção de usar --webroot para que o Certbot coloque arquivos de verificação no site, em vez de mudar os registros DNS? Essa maneira de verificação é muito mais compatível com a renovação automática, porque o Certbot não precisa da sua ajuda para fazer a verificação.

A outra opção é usar uma API de DNS (que permite a atualização de registro DNS por um software, sem intervenção humana). Essa possibilidade depende do seu provedor de DNS (se oferece ou não tal API).

1 Like
3

Também existe a opção de --standalone (nesse caso o Certbot cria seu próprio servidor web temporário para fazer a verificação). Teria que parar o Tomcat durante a renovação, mas geralmente apenas por uns segundos, e apenas a cada dois meses. Isso seria algo como

certbot --standalone --pre-hook "service tomcat stop" --post-hook "service tomcat start"

Aqui --pre-hook é um comando a ser executado antes da renovação, e --post-hook é algo para executar depois dela. O Certbot se lembra dessas opções e as usa nas renovações automáticas com certbot renew (apenas realizando a renovação quando seu certificado possuir menos de 1 mês de validade).

Já que você usa o Tomcat, é provável que precisaria também de um comando --deploy-hook (comando para executar após uma renovação bem-sucedida) para criar um novo arquivo JKS para o Tomcat, e para reiniciar o Tomcat. Não acho que o Tomcat entende os arquivos PEM criados pelo Certbot, e nesse caso o processo de conversão de formato de arquivos é também necessário em combinação com uma renovação.

4

@schoen
Muito obrigado pelas respostas.
Pelo que eu entendi então, eu conseguiria renovar o Certbot, porém a renovação seria parecida com a geração de um novo certificado, pois vamos precisar gerar o certificado e toda a cadeia?
Não temos nenhum caso de alguém usando Tomcat que consiga renovar sem fazer esses passo?
Agradeço novamente a rápida resposta.

5

Quando comecei a ver o problema, achei a opção --webroot a mais plausível também. Neste caso, terei que realizar a geração de um novo certificado utilizando a opção --webroot?
Pode exemplificar o comando, por gentileza?

6

Sim, mas o Certbot pode fazer tudo de forma automática se ele tiver conhecimento de todos os comandos necessários.

7

Com a opção --webroot, tem que existir um caminho de directório de onde o Tomcat serve arquivos ao público. Isso existe na sua configuração?

8

@schoen

Seria um caminho a semelhante a esse?

<Connector port=“443” protocol=“org.apache.coyote.http11.Http11Protocol”
maxThreads=“150” SSLEnabled=“true” scheme=“https” secure=“true”
keystoreFile="/orabin01/apache-tomcat-7.0.96/ssl/laboratorio.hsvp.com.br/laboratorio.hsvp.com.br.jks"

9

Esse é o caminho do arquivo JKS, o arquivo que tem que ser substituido ao renovar o certificado, que pode ser o propósito de um script que você pode usar com --deploy-hook. Mas esse caminho não tem nada a ver com um caminho para servir conteúdos estáticos ao público (que precisará para a opção -w com --webroot).

10

O caminho que procura seria /algum/exemplo com a propriedade de que criar o arquivo /algum/exemplo/arquivo.txt resulta na disponibilidade pública de http://laboratorio.hsvp.com.br/arquivo.txt no site.

Não sempre há um caminho assim, mas muitas vezes seria possível configurar o servidor para criar um, pelo menos especificamente para /.well-known/acme-challenge, que é o que a AC usará.

Como pode ver, o Certbot tem uma integração melhor com Apache e nginx que com outras aplicações, mas temos vários usuários que conseguiram ou com --standalone (parando o Tomcat por alguns segundos durante a renovação) ou com --webroot (encontrando ou criando um caminho no sistema de arquivos adequado para tornar arquivos estáticos disponíveis em determinados caminhos no site).

11

Dessa forma, acredito que o --satndalone sirva para o meu caso. Aquele seu exemplo, eu terei que gerar um novo como standalone ou posso tentar renovar esse que eu tenho que foi gerado como --manual?
Está sendo de grande valia sua ajuda.

12

Você pode renovar com—por exemplo—

certbot certonly --standalone -d laboratorio.hsvp.com.br --pre-hook "service tomcat stop" --post-hook "service tomcat start"

Se der o erro que o certificado não está precisando de renovação (que não deve ser o caso aqui porque já estava tentando renová-lo…), você pode adicionar

certbot certonly --standalone -d laboratorio.hsvp.com.br --pre-hook "service tomcat stop" --post-hook "service tomcat start" --force-renewal

Se isso conseguir, atualizará o arquivo /etc/letsencrypt/renewal/laboratorio.hsvp.com.br.conf com aquelas escolhas (--standalone e as duas opções hook) para que se usem em próximas tentativas de renovações. Geralmente esse arquivo contém as opções e escolhas que foram usadas na emissão ou renovação bem-sucedida mais recente (com determinadas exceções), e assim o certbot renew vai usar as mesmas automaticamente para renovações não-interativas.

Quanto ao conteúdo das opções hook, tem que verificar que service tomcat start e service tomcat stop funcionam para iniciar e parar o Tomcat, e se tem um script para atualizar o arquivo JKS com o novo certificado e a nova chave nos arquivos .pem em /etc/letsencrypt/archive, pode dar o nome desse script em --deploy-hook. (Mesmo se tiver um certificado novo em /etc/letsencrypt/archive, o Tomcat não o reconhece sem atualizar também o keystoreFile JKS, o que o Certbot por padrão não sabe fazer.)

13

Rodando o comando: certbot certonly --standalone -d laboratorio.hsvp.com.br --pre-hook “service tomcat stop” --post-hook “service tomcat start”

Retorna a seguinte saída:

[root@vps15808 ~]# certbot certonly --standalone -d laboratorio.hsvp.com.br --pre-hook “service tomcat stop” --post-hook “service tomcat start”
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Cert is due for renewal, auto-renewing…
Running pre-hook command: service tomcat stop
Output from pre-hook command service:
Using CATALINA_BASE: /orabin01/apache-tomcat-7.0.96
Using CATALINA_HOME: /orabin01/apache-tomcat-7.0.96
Using CATALINA_TMPDIR: /orabin01/apache-tomcat-7.0.96/temp
Using JRE_HOME: /usr/java/jdk1.8.0_221-amd64
Using CLASSPATH: /orabin01/apache-tomcat-7.0.96/bin/bootstrap.jar:/orabin01/apache-tomcat-7.0.96/bin/tomcat-juli.jar

Error output from pre-hook command service:
Java HotSpot™ 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0

Renewing an existing certificate
Performing the following challenges:
http-01 challenge for laboratorio.hsvp.com.br
Waiting for verification…
Challenge failed for domain laboratorio.hsvp.com.br
http-01 challenge for laboratorio.hsvp.com.br
Cleaning up challenges
Running post-hook command: service tomcat start
Output from post-hook command service:
Using CATALINA_BASE: /orabin01/apache-tomcat-7.0.96
Using CATALINA_HOME: /orabin01/apache-tomcat-7.0.96
Using CATALINA_TMPDIR: /orabin01/apache-tomcat-7.0.96/temp
Using JRE_HOME: /usr/java/jdk1.8.0_221-amd64
Using CLASSPATH: /orabin01/apache-tomcat-7.0.96/bin/bootstrap.jar:/orabin01/apache-tomcat-7.0.96/bin/tomcat-juli.jar
Tomcat started.

Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: laboratorio.hsvp.com.br
    Type: connection
    Detail: Fetching
    http://laboratorio.hsvp.com.br/.well-known/acme-challenge/TOjXSwM2WHajXmZVolTc61WtE2GUTlrRR0tWDBnwoyQ:
    Error getting validation data

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.
    [root@vps15808 ~]#

14

Realizado a execução do segundo comando:

[root@vps15808 ~]# certbot certonly --standalone -d laboratorio.hsvp.com.br --pre-hook “service tomcat stop” --post-hook “service tomcat start” --force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Running pre-hook command: service tomcat stop
Output from pre-hook command service:
Using CATALINA_BASE: /orabin01/apache-tomcat-7.0.96
Using CATALINA_HOME: /orabin01/apache-tomcat-7.0.96
Using CATALINA_TMPDIR: /orabin01/apache-tomcat-7.0.96/temp
Using JRE_HOME: /usr/java/jdk1.8.0_221-amd64
Using CLASSPATH: /orabin01/apache-tomcat-7.0.96/bin/bootstrap.jar:/orabin01/apache-tomcat-7.0.96/bin/tomcat-juli.jar
2020-02-20 16:08:46.658 INFO org.glowroot - Glowroot version: 0.13.5, built 2019-07-23 01:30:08 +0000
2020-02-20 16:08:46.664 INFO org.glowroot - Java version: 1.8.0_221 (Oracle Corporation / Linux)
2020-02-20 16:08:46.666 INFO org.glowroot - Java args: -Xms1024m -Xmx1024m -XX:MaxPermSize=512m -XX:+UseG1GC -XX:+DisableExplicitGC -javaagent:/orabin01/apache-tomcat-7.0.96/glowroot/glowroot.jar

Error output from pre-hook command service:
Java HotSpot™ 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0

Renewing an existing certificate
Performing the following challenges:
http-01 challenge for laboratorio.hsvp.com.br
Waiting for verification…
Challenge failed for domain laboratorio.hsvp.com.br
http-01 challenge for laboratorio.hsvp.com.br
Cleaning up challenges
Running post-hook command: service tomcat start
Output from post-hook command service:
Using CATALINA_BASE: /orabin01/apache-tomcat-7.0.96
Using CATALINA_HOME: /orabin01/apache-tomcat-7.0.96
Using CATALINA_TMPDIR: /orabin01/apache-tomcat-7.0.96/temp
Using JRE_HOME: /usr/java/jdk1.8.0_221-amd64
Using CLASSPATH: /orabin01/apache-tomcat-7.0.96/bin/bootstrap.jar:/orabin01/apache-tomcat-7.0.96/bin/tomcat-juli.jar
Tomcat started.

Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: laboratorio.hsvp.com.br
    Type: connection
    Detail: Fetching
    http://laboratorio.hsvp.com.br/.well-known/acme-challenge/PVYsWI0BZHKNXC2nvTpnSFuFRjPZzWEmH8Y3abEMaEE:
    Error getting validation data

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

15

Nesse momento me parece que o público não pode alcançar seu servidor no porto 80, provavelmente por causa de um firewall. Seu servidor está disponível no porto 443, mas tento conectar nele no porto 80, responde não com “ligação recusada” mas com “administrativamente proibido”, que é mais típico do comportamento de um firewall (ou no servidor ou na configuração do provedor de hospedagem).

16

Realizei a remoção dos certificados e ao tentar gerar um novo, retorna o seguinte erro:

[root@vps15808 ~]# sudo certbot certonly --standalone --preferred-challenges http -d laboratorio.hsvp.com.br
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for laboratorio.hsvp.com.br
Waiting for verification…
Challenge failed for domain laboratorio.hsvp.com.br
http-01 challenge for laboratorio.hsvp.com.br
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: laboratorio.hsvp.com.br
    Type: connection
    Detail: Fetching
    http://laboratorio.hsvp.com.br/.well-known/acme-challenge/llGkE-lgJEMICInyMmwZL0fHpuG6MKD-ycxzJn2eBO4:
    Error getting validation data

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.
    [root@vps15808 ~]#

17

O certificado antigo não tem nada a ver com esse problema, que é um problema no processo de verificação da AC na conexão com seu servidor.

18

E tens ideia de qual poderia ser esse problema? O que eu preciso verificar?

19

Eu procuraria as políticas do firewall no servidor bem como na hospedagem. No servidor, é possível que seria configurado com ufw.

20

Boa tarde, desabilitei o Firewall. Agora pode me informar como configurar no Tomcat diretamente pelo pem?