There’s 3 main ACME challenges. HTTP, TLS-ALPN, and DNS. Each have different situations where they make sense.
By default, Caddy enables the HTTP and TLS-ALPN challenges, because they require nothing extra from the user to work.
The HTTP challenge involves having an ACME CA make a request to your server on port 80 (the HTTP port) at a specific path, to prove that you own the domain (by serving a special file that only you could serve, proved by cryptographic operations). This usually works for the majority of users.
The TLS-ALPN challenge is similar, but works on port 443 (the HTTPS port). It’s a bit more complicated, but instead of serving a file, that value in the file is returned during the TLS handshake (the part where the client and server agree on a secret key to encrypt the connection) via some clever little extensions to the handshake. This is useful is you can’t expose port 80 for whatever reason (say, some other service is using that port).
And finally the DNS challenge, it doesn’t use any port. How it works is Caddy (if compiled with the relevant DNS plugin, and configured with credentials to connect to your DNS provider), will use the DNS provider’s API to set a special DNS record (a TXT record, whereas usually you’ve probably played with A or CNAME records, TXT is just another kind that just records a key-value pair of text) which contains that special value that the ACME CA expects, so then the ACME CA can do a DNS query to find that value on your DNS zone, to confirm that you indeed control that domain.
The main advantage to the DNS challenge is that your server doesn’t need to be publicly accessible on ports 80 or 443 (useful for some service you’re only exposing in your LAN, but want HTTPS for it), or if you need a wildcard certificate like *.example.com.
Only the DNS challenge can be used to give you a wildcard cert. The reason for this is that the HTTP and TLS-ALPN challenge only proves that you own exactly that domain, i.e. only subdomain.example.com, and only one subdomain at a time. Those two challenges can’t be used to prove that you can control the whole DNS zone. (This is important cause you don’t want to allow some bad actor to issue certificates for domains they don’t control, cause then they could impersonate that server, etc.) The DNS challenge though, since you’re editing a record on the DNS zone, is enough to show that you have control over the whole DNS zone. So this proves that you control all the infinite possible subdomains matching *.example.com.
This is explained in somewhat less detail here:
