Certbot: ¿Cómo habilito ACMEv2 y la recuperación de certificados comodín?

Debe utilizar el desafío DNS-01 . Lo que significa que debe tener una forma de modificar y publicar una zona DNS actualizada desde su servidor.

¿Podría decirme la bandera para esto?

No es solo una bandera, sino que todo está disponible en el documento. Son algunos complementos para varios proveedores de DNS enumerados allí, si el suyo no lo está, puede abrir una solicitud de función aquí para solicitar soporte (ya hay algunos abiertos para cosas como Gandi, por ejemplo, así que asegúrese de usar la búsqueda antes de abrir un uno nuevo).

Hum no, necesitas certbot >= 0.22 de hecho, lamento haberte perdido eso en tu primera publicación.

OK .... ¿Cómo hago para instalar eso? ¿Tengo que compilar desde la fuente?

Puede esperar a que se publique en el PPA , instalar a través de pip o algo similar o, de hecho, compilar desde la fuente.

¿Sería yo? Preferiría esperar a que se actualice el paquete oficial. Esto le dará algo de tiempo para ver cómo configurar correctamente el desafío de DNS, que ya puede probar sin comodines solo para verificar que todo funcione, y luego, cuando la actualización esté disponible (lo que no debería tomar mucho tiempo), estará listo para obtenga su certificado comodín.

Sí, puedes usar certbot de fuentes

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

Agregar registro TXT presione Enter. Obtendrá otro registro. Agréguelo también.

Luego, verifique en la segunda ventana de terminal si se implementaron los registros:

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"

Si todo está bien, regrese y presione Entrar

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

Actualización: consulte la guía completa

¡Gracias por responder tan a fondo @ArchangeGabriel! Estamos trabajando para actualizar nuestros paquetes para Ubuntu, ojalá salgan pronto.

@ohemorange ¡De

Buen @talyguryn , como seguimiento de @talyguryn

Al crear un certificado en ápice con comodín, obtendrá __dos__ desafíos ..

Usando -d "example.com, *.example.com" _dame un certificado en el ápice y comodín en el ápice_

Será desafiado _dos veces_, una por example.com y otra por *.example.com

Así que no crea que en el segundo desafío ha fallado ... y necesita cambiar el valor. simplemente agregue el desafío adicional al dns. Espere la propagación y continúe,

¿Posiblemente la salida debería cambiarse para que sea más fácil ver qué dominio está desafiado?

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

@AubreyHewes , tengo el mismo problema. No estoy seguro de cómo emitir un solo certificado para example.com y *.example.com . Desafortunadamente, certbot requiere que modifique el registro TXT dos veces. Esto hace que la validación falle para uno de los dominios. ¿Hay alguna forma de evitar esto?

@ nathan-alden Necesita establecer ambos registros TXT al mismo tiempo. No elimine el primero cuando agregue el segundo.

@ nathan-alden
Obtienes dos desafíos. Este _ parece_ como un certbot quiere que modifiques el mismo TXT nuevamente. Pero el segundo valor es para el segundo dominio, así que agregue un nuevo registro TXT para el segundo dominio.

es decir
Si usa -d "example.com,*.example.com" el primer desafío es para example.com así que agregue un TXT para esto. Continuar después de la propagación.
El segundo desafío es por *.example.com así que agrega un TXT para esto. Continuar después de la propagación.

Tuve una buena experiencia usando la versión Docker. Como nota al margen, asegúrese de configurar el TTL para la entrada TXT en algo así como 1 minuto para que no tenga que esperar una hora para que se propague la segunda entrada.

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

Preguntarse. ¿Por qué requerimos dns-01 . ¿No puede simplemente generar un servidor en el puerto 80 (cualquier forma de http desafío) y probar que soy dueño del dominio comodín generando N subdominios aleatorios y conectándose?

@AubreyHewes , descubrí que solo necesita un desafío / registro en DNS, solo tiene que adivinar el correcto.

Tengo un certificado para cuatro dominios y sus comodines. Cada dominio tiene un solo TXT _acme-challenge. Es bastante inconsistente ya que tres dominios funcionan con el primer desafío en la salida de certbot y los valores parecen ser los mismos cada vez que lo ejecuto.

El cuarto dominio no funciona con el primer registro en la salida, pero funciona con el segundo y este parece cambiar cada vez que ejecuto el certbot.

Yo 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

Hice esto por prueba y error, simplemente no sabía que puede tener dos registros DNS iguales con valores diferentes :-) La próxima vez lo intentaré.

@robertvalik No es posible usar el mismo valor de registro TXT para dos validaciones diferentes, incluyendo example.com y *.example.com .

Let's Encrypt permite reutilizar una autorización por un tiempo, actualmente 30 días. Si su cuenta validó algo recientemente, puede emitir más certificados sin validar nuevamente. Sin embargo, debido a las limitaciones de Certbot (# 5342), Certbot le pide que vuelva a establecer el mismo registro TXT , aunque no se volverá a comprobar.

Entonces, lo que debe haber sucedido es que ya había una autorización válida para uno de los nombres, por lo que el hecho de que el registro DNS necesario ya no existiera ya no importaba.

@ francoism90 Uno podría querer un dominio comodín por varias razones, uno podría estar sirviendo pocos subdominios estáticos, otro, sirviendo subdominios potencialmente infinitos (por ejemplo, software como servicio). En el último caso (mi caso), uno ya tiene un comodín en el archivo DNS y, en realidad, cualquier subdominio aleatorio debería resolverse correctamente. Me pregunto si se podría proporcionar una forma de desafío http para este escenario. ¡Gracias por todo su trabajo duro!

Tuve éxito al generar certificado emitiendo

./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

Ahora me pregunto cómo puedo renovar los certificados.

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

Estoy confundido, probé ./certbot-auto renew ya que usé el mismo comando al solicitar, pero solo quiero asegurarme de que sea la forma correcta.

¿Podemos automatizar la certificación comodín?

@ ufo911 Por supuesto. Por ejemplo, utilizando el complemento RFC 2136 de Certbot:

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"

O el gancho de autenticación 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

Si necesita ayuda, puede publicar un tema en el foro Let's Encrypt .

@mnordhoff
¿Es necesario que el registro TXT de DNS esté activo en cada renovación?

@ ufo911 Por supuesto, una renovación es solo una solicitud de certificado que reutiliza los parámetros anteriores.

@ArchangeGabriel Stange me dice que me dice que establezca nuevos 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"

¿Esto es normal? ¿Por qué se generan nuevos tokens?

Lo siento si no estaba claro, sí, hay un nuevo registro TXT en cada solicitud. Porque esta es una validación de desafío-respuesta, y reutilizar el desafío sería una muy mala idea.

Entonces, en realidad, puede eliminar el registro TXT tan pronto como obtenga el certificado, pero hay un nuevo registro TXT para publicar (y eliminar una vez que tenga éxito) cada vez que renueve.

@ArchangeGabriel Hmm, no creo que sea una opción para mí. La creación de nuevos registros TXT puede demorar hasta 24 horas en completarse y, si algo sale mal, terminará con mucho tiempo de inactividad.

En su lugar, usaré la forma general. :)

Claro, el desafío de DNS no es el más fácil. Pero para el comodín, no hay otra posibilidad, al menos actualmente. No sé si, por ejemplo, esto podría reemplazarse enviando el desafío a un nombre de subdominio aleatorio en el espacio comodín (por ejemplo, si solicita *.domain.com , intentaría leer la respuesta del desafío en somerandomstring.domain.com para verificar que efectivamente tiene control sobre todo el espacio *.domain.com ). De esta manera, tener su redirección de comodines en DNS sería suficiente.

@ArchangeGabriel Esta sería una buena opción, pero ¿aún sería necesaria la verificación de DNS en este caso? ¿Ofrece algo necesario para una configuración comodín segura?

No, mi idea sería ofrecer una alternativa al desafío de DNS.

Para una configuración de comodín, debe demostrar el control sobre todos los subdominios. La única forma obvia de hacerlo es demostrar la propiedad técnica de la zona DNS correspondiente.

Ahora me pregunto si podría haber otra forma más parecida a los otros tipos de desafíos. Preguntar un subdominio aleatorio demostraría que tiene control sobre una redirección comodín. No sé si eso sería suficiente para el IETF, supongo que lo han pensado y debe haber algunos problemas.

Por ejemplo, me pregunto si este caso es posible:
- somespecificsub.domain.com apunta hacia una IP determinada;
- * .domain.com y domain.com apunta hacia otra IP.

En ese caso, podría responder solicitudes para el dominio principal y cualquier subdominio excepto somespecificsub.domain.com. Y creo que no sería correcto entregarle un certificado * .domain.com. Entonces, si eso es posible, entonces necesitaríamos alguna configuración adicional. Como un registro TXT permanente que indica que está autorizado para realizar una verificación aleatoria de subdominios para la respuesta de desafío comodín. De esa manera, la configuración de DNS sería simplemente disparar y olvidar, y podría validar más fácilmente un comodín.

De todos modos, no sé con quién debería discutirse esto y en qué punto han considerado esta configuración, ni cuál es el criterio exacto requerido para entregar un comodín de forma segura. Supongo que debería leer el RFC para eso, pero no tengo tiempo para esto.