Certbot: Como ativo o ACMEv2 e a recuperação de certificados curinga?

Você deve usar o desafio DNS-01 . O que significa que você deve ter uma maneira de modificar, publicar e atualizar a zona DNS de dentro do seu servidor.

Você poderia me dizer a bandeira para isso?

Não é apenas uma bandeira, mas tudo está disponível no documento. Eles são alguns plug-ins para vários provedores de DNS listados lá, se o seu não for, você pode abrir uma solicitação de recurso aqui para pedir suporte para ele (já existem alguns abertos para coisas como Gandi, por exemplo, então certifique-se de usar a pesquisa antes de abrir um novo).

Hum não, você precisa de certbot >= 0.22 de fato, desculpe por ter perdido isso em sua primeira postagem.

OK .... Como faço para instalar isso? Eu tenho que compilar a partir do código-fonte?

Você pode esperar que ele seja publicado no PPA , instalar via pip ou algo semelhante ou mesmo construir a partir do código-fonte.

Se eu fosse você, prefiro aguardar a atualização do pacote oficial. Isso lhe dará algum tempo para ver como configurar o desafio de DNS corretamente, que você já pode tentar sem o caractere curinga, apenas para verificar se tudo funciona, e então quando a atualização estiver disponível (o que não deve demorar muito), você estará pronto para obtenha seu cert curinga.

Sim, você pode usar o certbot de fontes

root<strong i="6">@cs12</strong>:~# git clone https://github.com/certbot/certbot
...
root<strong i="7">@cs12</strong>:~# DOMAIN=example.com
root<strong i="8">@cs12</strong>:~# cd certbot 
root<strong i="9">@cs12</strong>:~/certbot# ./certbot-auto certonly --manual -d *.$DOMAIN -d $DOMAIN --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory
...
-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.example.com with the following value:

qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

Adicionar registro TXT pressione Enter. Você obterá outro registro. Adicione também.

Em seguida, verifique na segunda janela do terminal se os registros foram implantados:

root<strong i="15">@cs12</strong>:~# host -t txt _acme-challenge.example.com
_acme-challenge.example.com descriptive text "qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI"
_acme-challenge.example.com descriptive text "oMmMa-fDLlebdUhvhMD5MinJ2EeFpdP0F9lUPTShh4w"

Se estiver tudo bem, volte e pressione Enter

Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2018-06-11. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Atualização: Confira o guia completo

Obrigado por responder tão detalhadamente a @ArchangeGabriel! Estamos trabalhando para atualizar nossos pacotes para o Ubuntu, esperançosamente eles serão lançados em breve.

@ohemorange De nada! Honestamente, eu temia que veríamos um influxo de pessoas tentando obter certificados curinga sem ter nenhuma ideia sobre o que é o desafio DNS-01, mas aparentemente isso não aconteceu (pelo menos ainda).

Boa, @talyguryn , como acompanhamento de @talyguryn

Ao criar um certificado no apex com curinga, você obterá __dois__ desafios.

Usando -d "example.com, *.example.com" _dê-me um certificado no apex e um caractere curinga no apex_

Você será desafiado _duas vezes_, uma por example.com e novamente por *.example.com

Portanto, não pense que no segundo desafio ele falhou ... e você precisa alterar o valor. basta adicionar o desafio extra ao dns. Aguarde a propagação e continue,

Possivelmente, a saída deve ser alterada para que seja mais fácil ver qual domínio está sendo desafiado?

docs: https://sinkcup.github.io/letsencrypt-wildcard-certificate

@AubreyHewes , estou tendo o mesmo problema. Não tenho certeza de como emitir um único certificado para example.com e *.example.com . Infelizmente, o certbot exige que eu modifique o registro TXT duas vezes. Isso faz com que a validação falhe para um dos domínios. Existe uma maneira de contornar isso?

@ nathan-alden Você precisa definir os dois registros TXT ao mesmo tempo. Não exclua o primeiro ao adicionar o segundo.

@ nathan-alden
Você terá dois desafios. Este _parece_ como o certbot deseja que você modifique o mesmo TXT novamente. Mas o segundo valor é para o segundo domínio, então adicione um novo registro TXT para o segundo domínio.

ie
Se estiver usando -d "example.com,*.example.com" o primeiro desafio é example.com então adicione um TXT para isso. Continue após a propagação.
O segundo desafio é para *.example.com então adicione um TXT para isso. Continue após a propagação.

Tive uma boa experiência com a versão docker. Como uma observação lateral, certifique-se de definir o TTL para a entrada TXT em algo como 1 minuto para que você não tenha que esperar uma hora para a segunda entrada se propagar.

docker run -it --name certbot \
  -v <certs>:/etc/letsencrypt \
  -v <logs>:/var/lib/letsencrypt \
  certbot/certbot certonly --manual \ 
  -d *.<domain.com> -d <domain.com> \
  --agree-tos \
  --manual-public-ip-logging-ok \ 
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory

Imaginando. Por que exigimos dns-01 . Você não pode simplesmente gerar um servidor na porta 80 (qualquer forma de desafio http ) e sondar que eu possuo o domínio curinga, gerando N subdomínios aleatórios e conectando?

@AubreyHewes , descobri que você só precisa de um desafio / registro no DNS - só precisa adivinhar o correto.

Tenho um certificado para quatro domínios e seus curingas. Cada domínio tem apenas um desafio _acme TXT. É bastante inconsistente, pois três domínios funcionam com o primeiro desafio na saída do certbot e os valores parecem ser os mesmos sempre que eu o executo.

O quarto domínio não funciona com o primeiro registro na saída, mas funciona com o segundo e este parece mudar toda vez que executo o certbot.

Eu uso este comando:

/usr/bin/certbot --renew-by-default certonly --manual --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges dns-01 -w /usr/share/nginx/letsencrypt-root/ -d *.domain1.sk -d domain1.sk -d *.domain2.sk -d domain2.sk -d *.domain3.sk -d domain3.sk -d *.domain4.sk -d domain4.sk

Fiz isso por tentativa e erro - só não sabia que você pode ter dois registros DNS iguais com valores diferentes :-) Da próxima vez, vou tentar isso.

@robertvalik Não é possível usar o mesmo valor de registro TXT para duas validações diferentes, incluindo example.com e *.example.com .

Let's Encrypt permite que uma autorização seja reutilizada por um período, atualmente 30 dias. Se sua conta validou algo recentemente, ela pode emitir mais certificados sem validar novamente. No entanto, devido às limitações do Certbot (# 5342), o Certbot pede que você defina o mesmo registro TXT novamente, embora não seja verificado novamente.

Então o que deve ter acontecido é que já havia uma autorização válida para um dos nomes, então o fato de o registro DNS necessário não existir mais não importava.

@ francoism90 Alguém pode querer um domínio curinga por vários motivos, um pode estar servindo a poucos subdomínios estáticos, outro, servindo a subdomínios potencialmente infinitos (por exemplo, software como serviço). No último caso (meu caso), já existe um curinga no arquivo DNS e, na verdade, qualquer subdomínio aleatório deve ser resolvido corretamente. Gostaria de saber se uma forma de desafio http poderia ser fornecida para esse cenário. Obrigado por todo o seu trabalho árduo!

Tive sucesso ao gerar certificado emitindo

./certbot-auto certonly --manual -d *.example.com -d example.com --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Agora estou pensando em como posso renovar os certificados

<> certbot renew
<> certbot-renew
<> certbot-auto renew

Estou confuso, tentei ./certbot-auto renew porque usei o mesmo comando ao solicitar, mas só quero ter certeza de que é o caminho correto.

Podemos automatizar a certificação curinga?

@ ufo911 Claro. Por exemplo, usando o plug -

certbot certonly \
  --dns-rfc2136 \
  --dns-rfc2136-credentials ~/.secrets/certbot/rfc2136.ini \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

Ou o gancho de autenticação manual acme-dns :

certbot certonly \
  --debug-challenges \
  --manual \
  --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

https://certbot.eff.org/docs/using.html
https://community.letsencrypt.org/t/getting-wildcard-certificates-with-certbot/56285

Se precisar de ajuda, você pode postar um tópico no fórum Let's Encrypt .

@mnordhoff
é necessário que o registro TXT do DNS esteja ativo a cada renovação?

@ ufo911 Claro, uma renovação é apenas uma solicitação de certificado reutilizando os parâmetros anteriores.

@ArchangeGabriel Stange está me dizendo para definir novos registros TXT:

#!/bin/bash
certbot certonly \
  --manual \
  --agree-tos \
  --manual-public-ip-logging-ok \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d domain.tld \
  -d "*.domain.tld"

Isso é normal? Por que novos tokens estão sendo gerados?

Desculpe se não fui claro, sim, há um novo registro TXT em cada solicitação. Porque esta é uma validação de desafio-resposta, e reutilizar o desafio seria uma ideia muito ruim.

Portanto, na verdade, você pode remover o registro TXT assim que obtiver o certificado, mas há um novo registro TXT para publicar (e remover quando for bem-sucedido) sempre que renovar.

@ArchangeGabriel Hmm, não pense que isso é uma opção para mim. A criação de novos registros TXT pode levar até 24 horas para ser concluída e, se algo der errado, você terá muito tempo de inatividade.

Em vez disso, usarei a forma geral. :)

Claro, o desafio de DNS não é o mais fácil. Mas para curinga, não há outra possibilidade, pelo menos atualmente. Não sei se, por exemplo, isso poderia ser substituído enviando o desafio para um nome de subdomínio aleatório no espaço curinga (por exemplo, se você pedir *.domain.com , ele tentaria ler a resposta do desafio em somerandomstring.domain.com para verificar se você realmente tem controle sobre todo o *.domain.com espaço). Dessa forma, ter seu redirecionamento de curinga no DNS seria o suficiente.

@ArchangeGabriel Esta seria uma boa opção, mas a verificação de DNS ainda seria necessária neste caso? Ele oferece algo necessário para uma configuração de curinga segura?

Não, minha ideia seria oferecer uma alternativa ao desafio de DNS.

Para uma configuração de curinga, você precisa provar o controle sobre todos os subdomínios. A única maneira óbvia de fazer isso é comprovar a propriedade técnica da zona DNS correspondente.

Agora estou me perguntando se poderia haver outra maneira mais parecida com os outros tipos de desafios. Pedir um subdomínio aleatório provaria que você tem controle sobre o redirecionamento de curinga. Não sei se isso seria suficiente para o IETF, acho que eles pensaram sobre isso e deve haver alguns problemas.

Por exemplo, estou me perguntando se este caso é possível:
- somespecificsub.domain.com aponta para um determinado IP;
- * .domain.com e domain.com apontam para outro IP.

Nesse caso, você poderia responder a solicitações para o domínio principal e qualquer subdomínio, exceto somespecificsub.domain.com. E eu acho que não seria certo entregar a você um certificado de * .domain.com. Portanto, se isso for possível, precisaremos de algumas configurações adicionais. Como um registro TXT permanente informando que está autorizado a fazer verificação de subdomínio aleatória para a resposta de desafio de curinga. Dessa forma, a configuração do DNS seria apenas disparar e esquecer, e você poderia validar mais facilmente um caractere curinga.

De qualquer forma, não sei com quem isso deve ser discutido e em que ponto eles consideraram essa configuração, nem quais são os critérios exatos necessários para entregar um curinga com segurança. Acho que deveria apenas ler o RFC para isso, mas não tenho tempo para isso.