I would like to be able to offer TLS certificates for netip.cc domains, with minimal additional machinery.
Here's an idea, leveraging a custom certbot plugin:
Whenever a dns-01 challenge needs to be met, the plugin will make the following request:
$ dig IN TXT _acme.cd83f3190e4.2ee40050c4a0d666eb1b8a1.8005f02bb2128d.1d2fa335397a2fb5._.1.2.3.4.netip.cc.
The cd83f3190e4.2ee40050c4a0d666eb1b8a1.8005f02bb2128d.1d2fa335397a2fb5 contains the acme challenge token. The _ label serves to delimit the token so that it can be split into arbitrary sub-labels to get under the 63-character per-label length limits.
In response to receiving this record, the netip server will then start answering the following query:
$ dig IN TXT _acme-challenge.1.2.3.4.netip.cc
With the concatenated ACME token. Those will stay in-memory forever, until the challenge buffer (a couple of megabytes) is full, at which point older tokens stop being answered.
I've tried to figure out if this is prone to abuse, and aside from potential for buffer overflows and other normal problems for network-attached software, I can think of none. The "open" nature of the _acme.* IN A query means that someone -- anyone -- can disrupt ACME renewals. However, there is no way to abuse the upstream Let's Encrypt servers, and it does allow me to open up the usage to non-operators (i.e. people who ❤️ netip.cc)
I would like to be able to offer TLS certificates for netip.cc domains, with minimal additional machinery.
Here's an idea, leveraging a custom certbot plugin:
Whenever a dns-01 challenge needs to be met, the plugin will make the following request:
The
cd83f3190e4.2ee40050c4a0d666eb1b8a1.8005f02bb2128d.1d2fa335397a2fb5contains the acme challenge token. The_label serves to delimit the token so that it can be split into arbitrary sub-labels to get under the 63-character per-label length limits.In response to receiving this record, the netip server will then start answering the following query:
With the concatenated ACME token. Those will stay in-memory forever, until the challenge buffer (a couple of megabytes) is full, at which point older tokens stop being answered.
I've tried to figure out if this is prone to abuse, and aside from potential for buffer overflows and other normal problems for network-attached software, I can think of none. The "open" nature of the
_acme.*IN A query means that someone -- anyone -- can disrupt ACME renewals. However, there is no way to abuse the upstream Let's Encrypt servers, and it does allow me to open up the usage to non-operators (i.e. people who ❤️ netip.cc)