What is my webroot?

Eu tentei umas 5 vezes, vou terminar o processo e te dou o retorno

Outra dúvida: qual a versão do Certbot que está usando? (certbot --version)

(Me pergunto se achou um bug em --standalone porque não terminou em alguma circunstância.)

1 Like

A versão é a 0.10.2

Eu executei e retornou isso:

Failed authorization procedure. www.agendamentoonline.portalssi.com.br (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.agendamentoonline.portalssi.com.br/.well-known/acme-challenge/sYNa1eXRSDq7AXQ30LKLN0va41yoV2t_hXkVRD18MMU: Connection refused, agendamentoonline.portalssi.com.br (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://agendamentoonline.portalssi.com.br/.well-known/acme-challenge/Q8ECBDdFMkNf8mIE11_Pms2JXnIClD-xMZBo0fxoAA8: Connection refused

IMPORTANT NOTES:

Dessa vez no servidor do EC2? Que tem o endereço IP 18.217.126.142?

1 Like

Ontem eu tinha tentando e não consegui, ai apareceu uma mensagem dizendo para executar um comando, e esse comando era o que processo retornou 8739

Muito velha então, mas não acho que isso é o problema na emissão do certificado. :slight_smile:

1 Like

Talvez você tentava com --manual daquela vez?

1 Like

Ainda não, estou sem o acesso a linha de comando no servidor do ec2, vou falar com o meu superior para me conceder o acesso.

Eu só consigo acessar o console do glassfish por enquanto

Exatamente, eu tentei com o --manual

Bom, a AC tentava contectar-se no endereço 18.217.126.142, então precisa executar o Certbot naquele servidor. :slight_smile:

1 Like

Bom, felizmente isso não é um bug no --standalone. É que com o --manual precisa também terminar o processo uma vez que a verificação concluiu (seja uma verificação bem ou mal sucedida).

1 Like

Certo! Eu vou tentar aqui pelo outro servidor.

Muito obrigado pela atenção e pela gentileza, mais tarde eu te dou um retorno, ok?

Outra dica de um colega (traduzindo e parafraseando um pouco):

As pessoas que usam um proxy, mais comumente nginx, para fins de terminação de TLS (ou seja, receber as conexões da Internet na primeira instância) muitas vezes têm uma experiência melhor. Nessa configuração o processo nginx está configurado com o certificado e aceita as conexões em porta 443. Repassa as conexões a outro processo no localhost, em outra porta, que pertence à aplicação web.

Entre outras coisas tal configuração pode ser mais fácil, por exemplo porque o usuário pode usar algo como certbot --nginx (que acho que ainda não existia na versão que você tem aí, então valeria a pena atualizar seu Certbot). Uma vantagem é não ter que se preocupar com a configuração de certificados dentro do ambiente Java, que muitas vezes tem suporte menos amplo e atualizado, e um conjunto menos amplo de ferramentas, para HTTPS. Outra vantagem é que um servidor como nginx pode ser mais eficiente ao servir arquivos estáticos, se existem alguns na sua aplicação.

1 Like

@schoen Deu certo!

Eu me conectei no servidor do ec2 e consegui gerar o certificado. :+1:

Eu segui este tutorial: https://gist.github.com/douglasjunior/9cb1ff566823a37f07e72aa2c34ab0fb
Ele é próprio pro GlassFish.

Muito obrigado!

Beleza!

Uma coisa importante para saber é que os certificados têm um prazo de 90 dias. É preciso emitir novo certificado antes do vencimento para evitar erros de segurança. Aconselhamos criar um processo automático para isso, que faz todos os passos necessários.

Pode ver os comentários do autor do seu tutorial ao respeito:

A única ressalva, é que os certificados do Let's Encrypt tem uma curta duranção de validade, o que te obriga a fazer a renovação e re-executar todos esses passos no máximo em 90 dias.
Pretendo criar uma forma de automatizar esse script em breve para que seja possível agendar, por exemplo, uma tarefa CRON no linux e facilitar o processo de renovação.

1 Like

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