Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC2136 Certificate Issuing #214

Open
exander77 opened this issue Sep 14, 2024 · 4 comments
Open

RFC2136 Certificate Issuing #214

exander77 opened this issue Sep 14, 2024 · 4 comments

Comments

@exander77
Copy link

I have one more question, mox is now trying to generate certificate using tls-alpn-01 as standard timed out I assume, but my location is not public. I usually generate Let's Encrypt certificate using RFC2136. Is it supported, or can I hook a custom script to handle certificate generation outside mox?

@mjl-
Copy link
Owner

mjl- commented Sep 15, 2024

Mox currently does tls-alpn-01 as default, with http-01 as option too. dns-01 is not currently implemented.

This is an interesting topic! The issue I see with dns updates (rfc 2136) is that many people are stuck at cloud dns operators that either have only clunky web interfaces to edit dns records, or have have custom cloud api's/sdks to change records. I am planning on adding dns update support to mox also for setting up the initial dns records, and for automatically rolling over keys & policies (dkim, dane, mta-sts, etc). And we should also handle ACME verification through DNS then. I recently started using dns updates for my dns management. From what I've seen, not that many people use it (I'm still wondering why cloud dns operators aren't offering it).

Some projects that do ACME choose to add code to their applications/libraries to make dns changes for all the possible cloud operators. I don't want to add that many dependencies to mox. Only standard dns updates should be enough. I'm still looking for a dns-update proxy that offers a dns updates front, and makes the requested changes through one of the many cloud api's/sdk's, as configured by the user. Hopefully I don't have to write it myself. (:

can I hook a custom script to handle certificate generation outside mox?

The only way to do that would be to manage certs outside of mox, and restart mox when the certs have changed.

@exander77
Copy link
Author

It would be very convenient for managing all DNS records that mox needs, I have RFC2136 setup, so I can test anything. I have been using it for years (I have knot dns server that I manage myself). I personally wonder myself why it is not more widely used.

Where are certs stored and what is then naming convention there, I can definitely do it outside mox for the time being.

@mjl-
Copy link
Owner

mjl- commented Sep 15, 2024

To use existing certificates, you would change the Listeners section in mox.conf. Remove/Comment out "ACME" (https://www.xmox.nl/config/#cfg-mox-conf-Listeners-x-TLS-ACME), and set one or (likely) multiple KeyCerts, see https://www.xmox.nl/config/#cfg-mox-conf-Listeners-x-TLS-KeyCerts-dash-CertFile. The syntax may be a bit strange at first: The dash indicates an entry (of the KeyCerts array) and go on a line of their own, and the CertFile and KeyFile fields/values make up the contents (indented). It's not yaml.

Mox opens the KeyCerts early during startup, as root. So it can be any file, no special permissions required. If you're using something like certbot, it will store keys/certs in some place, and you can just point mox to those files.

You will typically need multiple certificates: At least one for your MX host name. And for each domain: an autoconfig.<domain> and an mta-sts.<domain>, assuming you want account autoconfiguration and mta-sts.

If you're using DANE, you can configure the keys at https://www.xmox.nl/config/#cfg-mox-conf-Listeners-x-TLS-HostPrivateKeyFiles, but they would only be used to print DANE TLSA DNS records. And they are opened by the mox user, not root, so would probably require setting permissions.

@RobSlgm
Copy link

RobSlgm commented Sep 19, 2024

Just a small caution if you are also using DNSSEC.

Most ACME tools, such as clients mentioned at Let's Encrypt, typically rotate the private key used for certificate generation with each new certificate issuance. This enhances security but requires updating your DNSSEC records with the new key information simultaneously.

While this has benefits for security, it would require to rotate the DNS entries related to DNSSEC at the same time.

A simpler alternative, used in my understanding by mox internally, involves retaining the same private key for certificate generation. This eliminates the need to constantly update your DNSSEC records, simplifying the process.

As example for lego use the --reuse-key option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants