-
Notifications
You must be signed in to change notification settings - Fork 99
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
Comments
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. (:
The only way to do that would be to manage certs outside of mox, and restart mox when the certs have changed. |
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. |
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 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. |
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 |
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?
The text was updated successfully, but these errors were encountered: