Certbot: autônomo deve permitir que portas alternativas se liguem (mas não se autentiquem)

Acredito que o cliente já tenha a funcionalidade desejada, no entanto, não é apresentada de uma forma muito amigável, pois é usada principalmente para testes. O cliente tem os seguintes sinalizadores:

  --tls-sni-01-port TLS_SNI_01_PORT
                        Port number to perform tls-sni-01 challenge. Boulder
                        in testing mode defaults to 5001. (default: 443)
  --http-01-port HTTP01_PORT
                        Port used in the SimpleHttp challenge. (default: 80)

Esses sinalizadores permitem especificar para quais portas o cliente configura os desafios de validação de domínio. Em geral, --tls-sni-01 deve ser a porta para a qual você roteou o tráfego de entrada da porta 443 e --http-01-port deve ser a porta para a qual você roteou o tráfego de entrada da porta 80.

Você não precisaria usar os dois sinalizadores, no entanto, autônomo por padrão executa desafios acima de 443. Você pode controlar esse comportamento usando o seguinte sinalizador:

  --standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
                        Supported challenges. Preferred in the order they are
                        listed. (default: tls-sni-01,http-01)

Eu espero que isso ajude!

Obrigado, vou tentar isso amanhã.

Se isso funcionar, deve realmente ser usado como exemplo. É muito mais fácil reiniciar um servidor para habilitar/desabilitar a passagem de proxy nessas portas do que deixar tudo offline para lidar com o processo de verificação,

Em 22 de março de 2016, às 15h16, bmw [email protected] escreveu:

Acredito que o cliente já tenha a funcionalidade desejada, no entanto, não é apresentada de uma forma muito amigável, pois é usada principalmente para testes. O cliente tem os seguintes sinalizadores:

--tls-sni-01-port TLS_SNI_01_PORT
Número da porta para executar o desafio tls-sni-01. Pedregulho
no modo de teste, o padrão é 5001. (padrão: 443)
--http-01-port HTTP01_PORT
Porta usada no desafio SimpleHttp. (padrão: 80)
Esses sinalizadores permitem especificar para quais portas o cliente configura os desafios de validação de domínio. Em geral, --tls-sni-01 deve ser a porta para a qual você roteou o tráfego da porta 443 de entrada e --http-01-port deve ser a porta para a qual roteou o tráfego da porta 80 de entrada.

Você não precisaria usar os dois sinalizadores, no entanto, autônomo por padrão executa desafios acima de 443. Você pode controlar esse comportamento usando o seguinte sinalizador:

--standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
Desafios suportados. Preferidas na ordem em que são
listados. (padrão: tls-sni-01,http-01)
Eu espero que isso ajude!

—
Você está recebendo isso porque foi o autor do tópico.
Responda a este e-mail diretamente ou visualize-o no GitHub

@jvanasco a maioria das pessoas usa o plugin webroot para esse caso de uso, mas sim, um exemplo de proxy pass nginx pode ser bom. Sinta-se à vontade para fazer um PR que adicione um aos documentos; este é um caso de uso suficientemente especializado que provavelmente deve obter uma nova seção na parte inferior deste arquivo:

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst

No entanto, você pode vinculá-lo a partir da seção Standalone existente:

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst#standalone

Nós nunca ouvimos de volta sobre isso, então estou encerrando esta questão. Por favor, comente gritando comigo se você quiser que eu reabra.

Isso não parece funcionar. @BMW

/usr/local/bin/certbot-auto certonly --http-01-port 8484 --config-dir /etc/letsencrypt --work-dir /var/lib/letsencrypt --logs-dir /var/log/letsencrypt --standalone --standalone-supported-challenges http-01 --email [email protected] --domains example.com --agree-tos --non-interactive

tcp        0      0 0.0.0.0:8484                0.0.0.0:*                   LISTEN      7270/python2

Eu vejo a autenticação na porta 80, no entanto, o servidor python2 foi iniciado em 8484.

Nginx na porta 80

66.133.109.36 - - [25/Aug/2016:12:41:15 +0100] "GET /.well-known/acme-challenge/xxxxxxxx HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

EDITAR:
Vejo que --tls-sni-01-port 5001 --http-01-port 5002 são necessários!

Editar:
Ainda não sei como o autônomo pode ativar um servidor e autenticá-lo

Também tendo problemas com --tls-sni-01-port sendo ignorado:

# certbot certonly --noninteractive --email "matt.hanley@****" --domain **** --agree-tos --tls-sni-01-port 40443 --http-01-port 4080 --standalone  
Failed authorization procedure. ****** (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 2af2853170e5be7e86cdff79d0ca****.febd4f14bb130b15910f30587cf4****.acme.invalid from 185.***.***.***:443. Received certificate containing '*****'

Observe que a solicitação foi para :443 ; Eu já tenho um serviço HTTPS rodando em :443 servindo um certificado diferente. Isso, no entanto, funciona com renew .

Também tem problema com --tls-sni-01-port :

certbot certonly -n -d example.com --agree-tos --email "[email protected]" --standalone --tls-sni-01-port 8443 --http-01-port 8080

Failed to connect to 1.2.3.4:443 for TLS-SNI-01

--http-01-port / --tls-sni-01-port não permite que você especifique em qual porta o Let's Encrypt se conectará ao seu servidor. Ele sempre usará 80/443 respectivamente. Todos esses sinalizadores permitem que você controle quais portas o Certbot escuta para plugins como autônomos. Isso é útil se você estiver roteando todo o tráfego da porta 80 para a porta 8080, por exemplo.

Sim, apenas um aviso, você basicamente precisa ter a porta 80 acessível no endereço IP público.

Algo que está muito carente na documentação, também significa que o Let's Encrypt não é adequado para uma minoria que não pode controlar o tráfego de entrada em 80 (provavelmente China / certos ISPs, firewalls Corp)

Eu li vários posts sobre isso, quase parece que a capacidade de ouvir em 80 é considerada um ganho de segurança / medida de confiança porque é uma porta privilegiada em uma caixa Nix.

Embora pareça que vamos criptografar não reconhecer um uso para certificados fora de servidores da web .. por exemplo, um servidor de e-mail etc, eu posso querer uma inicialização rápida na porta 7722 de um aplicativo de nó para lidar com a autenticação e desligar como eu não t executar um servidor web .. mas vá entender.

Também significa que, se você usar automação como o Chef, por exemplo, precisará configurar certificados autoassinados para poder inicializar seu nginx, pois a configuração terá SSL nele deve ter pelo menos um certificado válido.

Outra opção, porém, se você executar apenas SSL é ter um servidor web diferente servindo 80 para garantir que o certificado seja baixado antes que o nginx tente inicializar. (Configuração irritante)

Minhas implantações de chef agora são executadas através do seguinte:

1. Instale um certificado autoassinado.
2. Inicialize o nginx (com autocertificação)
3. Executar certificado
4. Certificados de link simbólico para minha localização
5. Recarregar nginx

Enviado do meu iPhone

Em 15 de setembro de 2016, às 23:18, Brad Warren [email protected] escreveu:

--http-01-port/--tls-sni-01-port não permite que você especifique em qual porta o Let's Encrypt se conectará ao seu servidor. Ele sempre usará 80/443 respectivamente. Todos esses sinalizadores permitem que você controle quais portas o Certbot escuta para plugins como autônomos. Isso é útil se você estiver roteando todo o tráfego da porta 80 para a porta 8080, por exemplo.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

Meu servidor web escuta em apenas uma porta para conexões SSL e não é o padrão 443. Isso ocorre porque o servidor web está atrás de um serviço VPN que permite o encaminhamento de porta, mas não permite o encaminhamento de porta para a porta 80 ou 443.

Estou tentando configurar o Let's Encrypt neste servidor mas nos logs vejo que o cliente acme tenta se conectar na porta 80 (que não está acessível) e falha.

O erro que recebo é um status "Não foi possível conectar" 400.

O valor "addressesResolved" está correto, só que o valor "port" é 80 e que todas as urls estão incorretas, pois deveriam ter minha porta customizada especificada, por exemplo, subdomain.domain. tld:1234 onde 1234 é minha porta personalizada.

Existe uma maneira de fazê-lo funcionar com a minha configuração?

De @gsdevme , tive a impressão de que tenho que ter a porta 80 acessível publicamente ...

_VOCÊ PRECISA TER A PORTA 80 PUBLICAMENTE ACESSÍVEL PARA O SERVIDOR ACME VERIFICAR._

_ESTA SOLUÇÃO É SOMENTE PARA EXECUTAR INTERNAMENTE O SERVIDOR EM UMA PORTA ALTERNATIVA E PROXY DA PORTA 80 PARA A PORTA ALTERNATIVA._

_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._
_SE VOCÊ NÃO TEM PORT80 ACESSÍVEL, VOCÊ DEVE USAR A VERIFICAÇÃO DNS._

Obrigado pela resposta @jvanasco. Pena que não posso especificar portas personalizadas. A verificação de DNS não é uma opção, porque meu provedor de DNS dinâmico http://freedns.afraid.org/ não possui uma interface para alterar automaticamente os registros TXT.

@jvanasco Embora eu saiba que você está totalmente certo em sua resposta, seria bom se todos nos acalmássemos um pouco antes de responder :D

Existe alguma previsão de quando isso será configurável? Porque tenho certeza de que há muitas pessoas executando servidores da Web em portas personalizadas.

Não é configurável por escolha de design

Enviado do meu iPhone

Em 14 de fevereiro de 2017, às 16:16, nvaert1986 [email protected] escreveu:

Existe alguma previsão de quando isso será configurável? Porque tenho certeza de que há muitas pessoas executando servidores da Web em portas personalizadas.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

Mesmo problema aqui, mas para fins do docker.

Problema :
Eu não quero empacotar o comando certbot com meu comando webserver start porque ele sempre falharia em ambientes não-prod.
Então eu quero construir uma imagem específica contendo certbot que:

• pedir o certificado
• coloque o certificado dentro de um volume compartilhado com meu servidor web

Mas esta solução só funcionaria se eu parar o container do meu servidor web, que já está ligado nas portas 80 e 443.

Solução:
Ter a capacidade de alterar as portas do certbot. Isso permitiria que o certbot e o contêiner do servidor da Web fossem executados em paralelo.

Usar a validação de DNS pode resolver o caso de uso.

Enviado do meu iPhone

Em 26 de fevereiro de 2017, às 23h32, NilsRenaud [email protected] escreveu:

Mesmo problema aqui, mas para fins do docker.

Problema :
Eu não quero empacotar o comando certbot com meu comando webserver start porque ele sempre falharia em ambientes não-prod.
Então eu quero construir uma imagem específica contendo certbot que:

pedir o certificado
coloque o certificado dentro de um volume compartilhado com meu servidor web
Mas esta solução só funcionaria se eu parar o container do meu servidor web, que já está ligado nas portas 80 e 443.

Solução:
Ter a capacidade de alterar as portas do certbot. Isso permitiria que o certbot e o contêiner do servidor da Web fossem executados em paralelo.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

Isso poderia, mas esse modo de validação não é possível com o modo autônomo :/
(de: https://certbot.eff.org/docs/using.html#plugins)

Parece que um meio-termo sensato sem comprometer a segurança seria permitir a descoberta da porta por meio do registro DNS SRV. Letsencrypt poderia consultar um registro como

_letsencrypt._tcp IN SRV 0 0 8080 10.10.10.10

no domínio e encaminhar solicitações de verificação para a combinação de endereço/porta resultante. Isso tem os mesmos benefícios da verificação de DNS, mas sem a desvantagem de exigir atualizações dinâmicas.

Isso também significa que os usuários podem centralizar facilmente o gerenciamento de seus certificados, se desejarem, fazendo referência a um servidor central de certificados.

Como permitir portas alternativas compromete a segurança?

Este utilitário FOSS pode ajudá-lo a automatizar instalações diretas e indiretas de certificados ACME para hosts que tenham a porta TCP/443 ocupada ou que não tenham a porta TCP/443 encaminhada para eles:

https://www.actiu.net/sesele/

Onde está a documentação sobre como o SeSeLe funciona para permitir o uso
portas diferentes de 443?.

Em 26 de outubro de 2017, 13h21, "Narcis Garcia" [email protected] escreveu:

Este utilitário FOSS pode ajudá-lo a automatizar instalações diretas e indiretas de
Certificados ACME para hosts que tenham a porta TCP/443 ocupada ou que não tenham TCP/443
porta encaminhada para eles:

https://www.actiu.net/sesele/

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/certbot/certbot/issues/2697#issuecomment-339754606 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAOGHuxKLiYjM4-cME-0GBu9Ujoe0NB_ks5swM20gaJpZM4H1uae
.

Por favor, vá para o problema do fórum SeSeLe para permitir uma melhor coordenação da documentação. (A resposta está escrita na documentação do SeSeLe agora)

Talvez esta questão possa ser revisitada? Ainda não há solução para o problema subjacente. Sim, você pode vincular autônomo a uma porta diferente, mas isso é inútil porque a autoridade ainda se conectará a 80/443.

Se você já tem um servidor rodando em 80/443 talvez em produção, às vezes você simplesmente não pode liberar essas portas. Colocar manualmente os arquivos de desafio também pode ser problemático (servidores em execução no Docker).

A solução real aqui seria especificar um conjunto de portas mais acima (10 000+) onde a autoridade tentaria se conectar como um fallback ou algo assim. Talvez haja implicações de segurança, não um especialista.

Qual é a motivação para o LE conectar apenas às portas 80/443? Isso é um
limitação formalmente documentada?

Alguém pode me indicar os documentos corretos?

Em 30 de novembro de 2017, 6h31, "cen1" [email protected] escreveu:

Talvez esta questão possa ser revisitada? Ainda não há solução para o problema
questão subjacente. Sim, você pode vincular autônomo a uma porta diferente, mas isso
é inútil porque athority ainda se conectará a 80/443.

Se você tem um servidor já rodando em 80/443 talvez em produção, você
às vezes simplesmente não pode liberar essas portas. Colocando manualmente
arquivos de desafio também podem ser problemáticos (servidores em execução no Docker).

A solução real aqui seria especificar um conjunto de portas mais acima (10
000+) onde a autoridade tentaria se conectar como um substituto ou algo assim
Curtiu isso. Talvez haja implicações de segurança, não um especialista.

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/certbot/certbot/issues/2697#issuecomment-348162321 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAOGHqWG9XZyTVDdAbm3t5xQ-AD6Y_OQks5s7pIDgaJpZM4H1uae
.

Qual é a motivação para o LE conectar apenas às portas 80/443?
Esta é uma limitação formalmente documentada?

Alguém pode me indicar os documentos corretos?

É um requisito atual do fórum CA/B descrito aqui:
https://cabforum.org/2017/09/19/ballot-190-revised-validation-requirements/

E explicado em maior extensão aqui: https://community.letsencrypt.org/t/support-for-ports-other-than-80-and-443/3419/100

Pelo que entendi com meu inglês ruim, no CA/Browser Forum eles debateram em setembro de 2017 sobre a possível adição das portas TCP 25, 115, 22.
Parece que a proposta foi aprovada e deve entrar em vigor em novembro.

Uma nota do futuro SE alguém vier aqui do Google (como eu):

2018-08-29 13:43:33,495: WARNING:certbot.plugins.standalone: 
The standalone specific supported challenges flag is deprecated. 
Please use the --preferred-challenges flag instead.

Se você estiver usando o nginx, poderá usar o módulo nginx com certbot certonly --nginx , ele acessa o servidor nginx existente sem nenhuma configuração.

O sinalizador $ --http-01-port não é realmente intuitivo também não consegui encontrá-lo na ajuda do comando e tive que pesquisar no google pelo sinalizador --http-01-port . Seria bom ter a bandeira mencionada na ajuda.