ACME DNS-01 challenge support

[duracell]

Summary

Hello, it would be great if the ACME container would support DNS-01 challenges.

Motivation

It's really sad that there is only support for web challenges. There are some good reasons why a person don't want or don't be able to use challenges via port 80 and mailcow wants to make the life easier and not harder with building complex certificate pipelines. And nearly all acme tools are supporting DNS-01 already.

As example: My private communication is splitted in multiple servers and while my mailserver only has mailserver ports open to the internet and only mailserver requests are handled there, the webserver is a complete different machine. For creating the certificates with mailcow I need to copy files around while the are created or need to do a pain of reverse shells from my internal net to be able to do a nginx reverse tunnel. And even "just" reverse-proxy on an easier setup is not that easy of the webserver itself uses acme via http. All of this seems a lot of struggle and possible security risks.

I use DNS-01 on all of my hosts and it's working perfect.

Another benefit could be the possiblity to use wildcard certificates. Then it's not necessary to create a new certificate with every new domain. Also the (sub)domains don't pop-up in the certificate log (which results in more brute-force and spam).

Also DNS-01 is a lot more secure, especially if it's used together with DNSSEC. HTTP can be manipulated with different attacks and someone could get a spoofed certificate this way. With DNS-01 it's a lot harder, with DNSSEC you would need to infiltrate the complete DNSSEC chain. That's also the reason for validationmethods parameter in the CAA record (defined in RFC8657), where you can define that's only (e.g.) DNS-01 is allowed for the given CA.

Additional context

(I already found #3836, but it's 2 years old, in german and closed.)

[MAGICCC]

Yes I know DNS-01 would be awesome but would require a lot of work in backend + frontend, since acme-tiny does not support DNS-01 at all

[duracell]

I switched to acme-dns-tiny years ago which works perfectly fine like acme-tiny. But yeah, testing and implementing the dns stuff in the frontend is still work to do.

(And there are also other Alternatives like acme-hooked and more, which I didn't tested.)

[DerLinkman]

Feel always free to contribute your work to the project. It would be a nice addition but i don't see any chance that we are implementing this by ourself in the near future i'm afraid.

[wildy]

In light of a recent attack on jabber.ru, using dns-01 (and a relevant CAA restriction; see this article) becomes more important.

[iljur]

Possible workaround: Use a reverse proxy like Caddy with DNS provider module.

[duracell]

Possible workaround: Use a reverse proxy like Caddy with DNS provider module.

Can you explain how this is a workaround in the described scenario (splitted Webserver/Mailserver) where the A record points to the webserver.

[iljur]

Ah, you don't want to use the WebUI anyway?! Sorry, in this case my suggestion is of course not what you want.

Message ID: @.***>

[duracell]

Ah, okay. Yeah, for the WebUI there are solutions/workarounds, but that doesn't fix the certificate for the mailserver software itself (SMTP/IMAP/POP3). (There are also workarounds possible with copying files and/or tunneling traffic, building complex forwarding rules, etc. But that could break with every release.)

[iljur]

But if you don't need/want the WebUI at all, why not just close ports 80/443 by FW? And nevertheless run Caddy (or any other tool) and let it get certs via DNS and copy those certs with a little script into the respective mailcow folders like shown in the Wiki?

The risk of running a script, copying 2 files and restarting some containers seems to be reasonable.

[gpz1100]

@duracell I've been using the script in the link below. You will need to disable the built in acme renewal as it's no longer needed. Cloudflare api key is scope limited to my domain and my ip only.

https://gist.github.com/greenmoss/8ee9d4acd3a21df699cde2225a78399e

I had some issues with broken cert chains. Replacing lines 40 and 41 with the those below appears to have resolved those issues.

ln -sfv live/$your_domain/privkey.pem key.pem
ln -sfv live/$your_domain/fullchain.pem cert.pem

# cert path for dovecot to work, else imap/pop tls fails
cp live/$your_domain/privkey.pem   $your_domain/key.pem
cp live/$your_domain/fullchain.pem $your_domain/cert.pem

[cerw]

Yes please