Lua-resty-auto-ssl: Certificados comodín

No soy un mantenedor de repositorios, pero debo decir que esto no es algo fácil de agregar. Los certificados LE wildcard requerirán la validación de DNS y, en este momento, lua-resty-auto-ssl usa la validación de http.

Sería bueno tener la validación de DNS, incluso sin considerar los comodines. Algunos pensamientos:

• tenemos que esperar a que deshidratado obtenga soporte ACMEv2 primero: deshidratado#420
• deshidratado ya es compatible con el desafío (ACMEv1) dns-01 . El desafío dns-01 en el borrador actual de ACMEv2 me parece idéntico o casi idéntico.
• el gancho deploy_challenge de deshidratado proporciona un dominio y un token para escribir en un registro TXT.
• Dado que no sabemos cómo los usuarios administran sus registros DNS, esta parte debe ser genérica.
  
  
  
  1. Admite las API de DNS populares. Al menos deberíamos agregar infraestructura para admitir API "estándar" como la proporcionada por PowerDNS, CloudFlare o incluso nsupdate. En este caso solo se necesita algún tipo de token de autenticación en nuestra configuración.
  
  
  2. Los usuarios deben necesitar una solución personalizada para establecer esos registros, como hablar con una API propietaria o incluso llamar a scripts de shell sucios. Deberíamos proporcionar un gancho genérico para esos 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)
  
  
• la capa de almacenamiento actualmente asume que puede usar el dominio completo como clave para obtener el certificado. Esto ya no será cierto. Mi primera idea es almacenar comodines como parentdomain.com:wildcard:latest y hacer que la capa de almacenamiento verifique esa clave si no se encuentra un certificado concreto.

Preguntas:

1. ¿Cómo sabemos si generar un certificado normal o comodín? una nueva función definida por el usuario is_wildcard_domain ? ¿Un nuevo valor de retorno para los allow_domain existentes?
2. ¿Admitimos la validación de DNS (para comodines) y HTTP (para certificados normales) al mismo tiempo, o solo DNS para ambos? Tenga en cuenta que HTTP puede ser mucho más rápido, ya que controlamos todas las partes móviles.

FYI: ahora hay un punto final de prueba ACMEv2 disponible. :)

El desafío dns-01 en el borrador actual de ACMEv2 me parece idéntico o casi idéntico.

Tienes razón :-) Nada ha cambiado en el desafío DNS-01 entre la API V1 y V2.

FYI: al menos la versión de desarrollo de deshidratado ahora admite ACMEv2, así como certificados comodín. Por si alguien quiere empezar a trabajar en esto, esta es su oportunidad ;)

Creo que resty-auto-ssl haciendo la validación de DNS está completamente fuera de alcance.
Sin embargo, debería ser posible para nosotros hacer que resty-auto-ssl recurra a un certificado comodín configurado "fuera de banda".
Por ejemplo, voy a configurar mi servicio usando bind9 y certbot para hacer un certificado comodín para un dominio. En este momento, no creo que pueda decirle a resty-auto-ssl que use ese certificado comodín en lugar de intentar generar uno.

EDIT: Bueno, no es que fuera de alcance. No sabía que deshidratado podría configurarse con scripts manuales para conectarse a una API de DNS personalizada...

¿Hay alguna manera de almacenar un certificado LE comodín generado manualmente en Redis para que resty-auto-ssl pueda usarlo?

Por lo que entiendo del código, esto no es posible. Sin embargo, podríamos agregar fácilmente las siguientes comprobaciones en la interfaz de almacenamiento, para cada sub.domain.tld :

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

De esta manera, podríamos tener un primer paso hacia los comodines, admitiendo solo certificados generados previamente por ahora. Después de hacerlo, podríamos continuar y decidir una buena manera de admitir la generación de certificados comodín, si decidimos que queremos hacerlo.

Editar: me encantaría rascar una implementación de lo anterior.

@akalipetis , ¿intentaste ver si se configuraba

ssl_options.fullchain_der
ssl_options.privkey_der

funcionaría en allow_domain?
Si es posible, puede hacer una solicitud de redis en allow_domain y configurarlos.

Para que conste, acabo de encontrarme con este problema, uso lua-resty-auto-ssl para generar certificados para páginas de estado de dominio personalizadas en mi servicio de monitoreo y la mayoría de las personas usaría mis propios dominios como xxxx.status.updown.io para lo cual es mucho más eficiente para usar un certificado comodín.

Logré esto usando allow_domain lambda para omitir la generación de certificados para *status.updown.io :

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

Y luego proporcionó el comodín como el certificado alternativo predeterminado:

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

Generé el certificado manualmente usando el desafío DNS con:

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

No estoy seguro de que valga la pena dedicar mi tiempo a automatizar esto, ya que parece complicado con el desafío del DNS. Es de baja tecnología pero funciona como se esperaba :)

Esa es una buena solución y se aplica a muchos casos de uso.
Sin embargo, tenga en cuenta que el desafío de DNS se ha hecho muy fácil con https://github.com/AnalogJ/lexicon .
Funciona bien y es compatible con muchos proveedores. Incluso agregué uno de ellos y el proceso es ridículamente fácil.

@kapouer gracias por el consejo sobre lexicon , lo tendré en cuenta si quiero automatizar;)

Para que conste, acabo de encontrarme con este problema, uso lua-resty-auto-ssl para generar certificados para páginas de estado de dominio personalizadas en mi servicio de monitoreo y la mayoría de las personas usaría mis propios dominios como xxxx.status.updown.io para lo cual es mucho más eficiente para usar un certificado comodín.

Logré esto usando allow_domain lambda para omitir la generación de certificados para *status.updown.io :

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

Y luego proporcionó el comodín como el certificado alternativo predeterminado:

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

Generé el certificado manualmente usando el desafío DNS con:

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

No estoy seguro de que valga la pena dedicar mi tiempo a automatizar esto, ya que parece complicado con el desafío del DNS. Es de baja tecnología pero funciona como se esperaba :)

También estoy haciendo el mismo tipo de verificación de dominio para nuestra aplicación. Si el host del portal del usuario contiene uno de nuestros dominios "propios", simplemente volvemos a usar certificados comodín de una CA estática. Pero me gusta su idea de seguir usando LE y generar los comodines manualmente.

Voy a probar esto.

Actualizar
Bien, esta es la solución que realmente hace lo que quiero. El complemento de cloudflare. Los documentos son bastante buenos. Lo tuve funcionando en una hora o dos.

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

@jarthod ¿ alguna otra solución para automatizar esto? Recordar renovar el comodín cada 3 meses es realmente doloroso.

@jarthod ¿ alguna otra solución para automatizar esto? Recordar renovar el comodín cada 3 meses es realmente doloroso.

No por mi parte, sigo usando esto y renovando el manual cada 3 meses. Recordar no es un problema para mí, ya que estoy usando mi servicio (updown.io) para monitorear el punto final y me alerta cuando el certificado está a punto de caducar.

Yo también soy usuario de su servicio. De todos modos, seguí adelante y obtuve SSL comodín tradicional de 1 año.

Ahora su servicio tiene trabajo para recordarme el próximo año 😄

El 3 de octubre de 2020, a las 22:30, Adrien Rey-Jarthon [email protected] escribió:

Prenda
@jarthod ¿ alguna otra solución para automatizar esto? Recordar renovar el comodín cada 3 meses es realmente doloroso.

No por mi parte, sigo usando esto y renovando el manual cada 3 meses. Recordar no es un problema para mí, ya que estoy usando mi servicio (updown.io) para monitorear el punto final y me alerta cuando el certificado está a punto de caducar.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub o cancele la suscripción.