Lua-resty-auto-ssl: Certificados curinga

Eu não sou um mantenedor de repositórios, mas devo dizer que isso não é algo fácil de adicionar. Os certificados curinga LE exigirão validação de DNS, e agora lua-resty-auto-ssl usa validação http.

Seria bom ter validação de DNS, mesmo sem considerar curingas. Alguns pensamentos:

• precisamos aguardar o desidratado para obter suporte ao ACMEv2 primeiro: desidratado#420
• desidratado já suporta o desafio (ACMEv1) dns-01 . O desafio dns-01 no rascunho atual do ACMEv2 parece idêntico ou quase idêntico a mim.
• o gancho deploy_challenge do desidratado fornece um domínio e um token a ser gravado em um registro TXT.
• como não sabemos como os usuários estão gerenciando seus registros DNS, essa parte precisa ser genérica.
  
  
  
  1. suporta APIs DNS populares. Devemos pelo menos adicionar infraestrutura para suportar APIs "padrão" como a fornecida pelo PowerDNS, CloudFlare ou mesmo nsupdate. Nesse caso, apenas algum tipo de token de autenticação é necessário em nossas configurações.
  
  
  2. Os usuários devem precisar de uma solução personalizada para definir esses registros, como conversar com uma API proprietária ou até mesmo chamar scripts de shell sujos. Devemos fornecer um gancho genérico para esses casos:
     
     -- Define a function to store the validation tokens for DNS verification -- by let's encrypt in your DNS setup. auto_ssl:set("deploy_dns_challenge", function(domain, token) -- talk to your DNS-API to create a new TXT record _acme-challenge.$domain with value $token end)
  
  
• a camada de armazenamento atualmente assume que pode usar o domínio completo como chave para obter o certificado. Isso não será mais verdade. Minha primeira idéia é armazenar curingas como parentdomain.com:wildcard:latest e fazer com que a camada de armazenamento verifique essa chave se um certificado concreto não for encontrado.

Perguntas:

1. como sabemos se devemos gerar um certificado normal ou curinga? uma nova função definida pelo usuário is_wildcard_domain ? Um novo valor de retorno para o allow_domain existente?
2. suportamos validação de DNS (para curingas) e HTTP (para certificados normais) ao mesmo tempo, ou apenas DNS para ambos? Observe que o HTTP pode ser muito mais rápido, pois controlamos todas as partes móveis.

FYI: agora há um ponto de extremidade de preparo ACMEv2 disponível. :)

O desafio dns-01 no rascunho atual do ACMEv2 parece idêntico ou quase idêntico a mim.

Você está certo :-) Nada mudou no desafio DNS-01 entre a API V1 e V2.

FYI: pelo menos a versão de desenvolvimento de desidratado agora suporta ACMEv2, bem como certificados curinga. Caso alguém queira começar a trabalhar nisso, agora é sua chance ;)

Acho que resty-auto-ssl fazer validação de DNS está completamente fora do escopo.
No entanto, deve ser possível fazer com que resty-auto-ssl retorne a um certificado curinga configurado "fora de banda".
Por exemplo, vou configurar meu serviço usando bind9 e certbot para fazer um certificado curinga para um domínio. No momento, acho que não posso dizer ao resty-auto-ssl para usar esse certificado curinga em vez de tentar gerar um.

EDIT: bem, não é tão fora do escopo. Eu não sabia que desidratado poderia ser configurado com scripts manuais para se conectar a uma API DNS personalizada ...

Existe uma maneira de armazenar um certificado LE curinga gerado manualmente no Redis para que o resty-auto-ssl possa usá-lo?

Pelo que entendi do código, isso não é possível. Poderíamos facilmente adicionar as seguintes verificações na interface de armazenamento, para cada sub.domain.tld :

• sub.domain.tld:latest — atual
• *.domain.tld:latest
• *.sub.domain.tld:latest

Dessa forma, poderíamos dar um primeiro passo em direção aos curingas, suportando apenas certificados gerados anteriormente por enquanto. Depois de fazer isso, podemos seguir em frente e decidir sobre uma boa maneira de oferecer suporte à geração de certificados curinga, se decidirmos que queremos fazê-lo.

Edit: eu ficaria feliz em arranhar uma implementação do acima.

@akalipettis você tentou ver se configurando

ssl_options.fullchain_der
ssl_options.privkey_der

funcionaria em allow_domain ?
Se for possível, você pode fazer uma solicitação redis em allow_domain e defini-los.

Para o registro, acabei de encontrar esse problema, uso lua-resty-auto-ssl para gerar certificados para páginas de status de domínio personalizado no meu serviço de monitoramento e a maioria das pessoas usaria meus próprios domínios como xxxx.status.updown.io para o qual é muito mais eficiente para usar um certificado curinga.

Consegui isso usando allow_domain lambda para pular a geração de certificados para *status.updown.io :

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

E, em seguida, forneceu o curinga como o certificado de fallback padrão:

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

Eu gerei o certificado manualmente usando o desafio DNS com:

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

Não tenho certeza se vale a pena gastar meu tempo automatizando isso, pois parece complicado com o desafio do DNS. É de baixa tecnologia, mas funciona como esperado :)

Essa é uma boa solução alternativa e que se aplica a muitos casos de uso.
No entanto, lembre-se de que o desafio do DNS foi muito fácil com https://github.com/AnalogJ/lexicon !
Funciona bem e suporta muitos provedores. Eu até adicionei um deles e o processo é ridiculamente fácil.

@kapouer obrigado pela dica sobre lexicon , vou manter isso em mente se eu quiser automatizar ;)

Para o registro, acabei de encontrar esse problema, uso lua-resty-auto-ssl para gerar certificados para páginas de status de domínio personalizado no meu serviço de monitoramento e a maioria das pessoas usaria meus próprios domínios como xxxx.status.updown.io para o qual é muito mais eficiente para usar um certificado curinga.

Consegui isso usando allow_domain lambda para pular a geração de certificados para *status.updown.io :

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

E, em seguida, forneceu o curinga como o certificado de fallback padrão:

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

Eu gerei o certificado manualmente usando o desafio DNS com:

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

Não tenho certeza se vale a pena gastar meu tempo automatizando isso, pois parece complicado com o desafio do DNS. É de baixa tecnologia, mas funciona como esperado :)

Também estou fazendo o mesmo tipo de verificação de domínio para nosso aplicativo. Se o host do portal do usuário contiver um de nossos domínios "próprios", apenas voltaremos a usar certificados curinga de uma CA estática. Mas eu gosto da sua ideia de ainda usar o LE e gerar os curingas manualmente.

Eu vou testar isso.

Atualizar
Ok, esta é a solução que realmente faz o que eu quero. O plug-in cloudflare. Os docs são muito bons. Eu tinha que trabalhar dentro de uma hora ou duas.

https://certbot-dns-cloudflare.readthedocs.io/en/stable/

@jarthod alguma outra solução alternativa para automatizar isso? Lembrar de renovar o curinga a cada 3 meses é uma dor na verdade.

@jarthod alguma outra solução alternativa para automatizar isso? Lembrar de renovar o curinga a cada 3 meses é uma dor na verdade.

Não do meu lado, ainda estou usando isso e fazendo a renovação manual a cada 3 meses. Lembrar não é um problema para mim, pois estou usando meu serviço (updown.io) para monitorar o endpoint e ele me alerta quando o certificado está prestes a expirar.

Eu também sou usuário de seu serviço. De qualquer forma, fui em frente e obtive o SSL curinga tradicional de 1 ano.

Agora seu serviço tem trabalho para me lembrar ano que vem 😄

Em 03-out-2020, às 22h30, Adrien Rey-Jarthon [email protected] escreveu:

Em
@jarthod alguma outra solução alternativa para automatizar isso? Lembrar de renovar o curinga a cada 3 meses é uma dor na verdade.

Não do meu lado, ainda estou usando isso e fazendo a renovação manual a cada 3 meses. Lembrar não é um problema para mim, pois estou usando meu serviço (updown.io) para monitorar o endpoint e ele me alerta quando o certificado está prestes a expirar.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou cancele a inscrição.