I already use certbot with my DNS provider, so it should generally be supported. And indeed, O found the docs, where all supported providers are listed.
The DNS provider needs to provide an API, but not an ACME server.
Your server contacts Lets Encrypt and wants a certificate - say for homeserver.example.com. It tells Let’s Encrypt to use DNS based authentication. Let’s encrypt answers with a challenge code, that you now publish as a txt record with a defined name via your providers API for this (sub)domain. Let’s encrypt then checks the TXT record and if it finds the challenge there, it sends you the certificate.
You use an ACME client (either explicitly with e.g. certbot or a webserver that has a client Iintegrated like Traefik, Caddy,…) to communicate with an ACME server (the CA, e.g. Let’s encrypt). Your ACME client asks for a certificate with a DNS challenge. It gets a code that you/the client needs to publish as a DNS record. Only then the client talks to your DNS provider and tells them to put a specific TXT record on your domain (or onanual mode: the client prints out the value and you need to put it there manually). After your DNS provider published it, your client tells the server to check the challenge and hand you your certificate.
Your DNS provider in this diagram is just that one small rectangle in the lower left.
Note: There’s nothing stopping your DNS provider to just do all of this, generate a certificate for you and providing you with a button in your account where you can download a certificate with a single click. Also if you are at a webhoster and only host a simple page there, they will probably also provide your with a TLS cert with the click of a single button.
I already use certbot with my DNS provider, so it should generally be supported. And indeed, O found the docs, where all supported providers are listed.
https://doc.traefik.io/traefik/https/acme/#providers
Yeah. For wildcard DNS from letsencrypt, you can’t do HTTP validation, only DNS, which involves creating a TXT record.
Your DNS provider needs to run an ACME server, which runs an API that’ll add the required TXT records on request.
As I understand it.
The DNS provider needs to provide an API, but not an ACME server.
Your server contacts Lets Encrypt and wants a certificate - say for homeserver.example.com. It tells Let’s Encrypt to use DNS based authentication. Let’s encrypt answers with a challenge code, that you now publish as a txt record with a defined name via your providers API for this (sub)domain. Let’s encrypt then checks the TXT record and if it finds the challenge there, it sends you the certificate.
Wouldn’t the authentication API provided by your DNS host be the ACME server?
No, see also this diagram: https://www.digitalberry.fr/wp-content/uploads/2023/02/DNS-challenge-process.png
You use an ACME client (either explicitly with e.g. certbot or a webserver that has a client Iintegrated like Traefik, Caddy,…) to communicate with an ACME server (the CA, e.g. Let’s encrypt). Your ACME client asks for a certificate with a DNS challenge. It gets a code that you/the client needs to publish as a DNS record. Only then the client talks to your DNS provider and tells them to put a specific TXT record on your domain (or onanual mode: the client prints out the value and you need to put it there manually). After your DNS provider published it, your client tells the server to check the challenge and hand you your certificate.
Your DNS provider in this diagram is just that one small rectangle in the lower left.
Note: There’s nothing stopping your DNS provider to just do all of this, generate a certificate for you and providing you with a button in your account where you can download a certificate with a single click. Also if you are at a webhoster and only host a simple page there, they will probably also provide your with a TLS cert with the click of a single button.