As documented in the README's "Configuring wildcard SSL using DNS"
section, the necessary pieces for DNS-01 ACME challenges to work are
already baked into Traefik's recipe, though they were originally
considered for provisioning wildcard certificates. Furthermore, in
environments where the server is not exposed to the internet, the
default HTTP-01 challenge mechanism doesn't work, so, taking advantage
of this alternative method makes complete sense.
This change causes ACME validations to be done always using DNS when
LETS_ENCRYPT_DNS_CHALLENGE_ENABLED is active. Without it, for standard
certificate requests Traefik uses the HTTP-01 challenge method, which
doesn't work in servers behind a firewall.
We should amend the related section in the operators handbook
to make a not about the possibility of using DNS challenges in those
scenarios as well.
I have deployed and tested my changes
I tested this with both a server "exposed" to the internet and one behind a firewall. The first one continued to use the HTTP-01 challenge because no DNS-related settings were added to it, and the second one was successfully able to provision certificates (even though it's only reachable within the LAN).
As documented in the README's "Configuring wildcard SSL using DNS"
section, the necessary pieces for DNS-01 ACME challenges to work are
already baked into Traefik's recipe, though they were originally
considered for provisioning wildcard certificates. Furthermore, in
environments where the server is not exposed to the internet, the
default HTTP-01 challenge mechanism doesn't work, so, taking advantage
of this alternative method makes complete sense.
This change causes ACME validations to be done always using DNS when
LETS_ENCRYPT_DNS_CHALLENGE_ENABLED is active. Without it, for standard
certificate requests Traefik uses the HTTP-01 challenge method, which
doesn't work in servers behind a firewall.
We should amend the related section in the [operators handbook](https://docs.coopcloud.tech/operators/handbook/#running-an-offline-coop-cloud-server)
to make a not about the possibility of using DNS challenges in those
scenarios as well.
* [x] I have deployed and tested my changes
I tested this with both a server "exposed" to the internet and one behind a firewall. The first one continued to use the HTTP-01 challenge because no DNS-related settings were added to it, and the second one was successfully able to provision certificates (even though it's only reachable within the LAN).
* [x] I have [updated relevant versions in `abra.sh`](https://docs.coopcloud.tech/maintainers/upgrade/#updating-versions-in-the-abrash)
* [x] I have added a [release note entry](https://docs.coopcloud.tech/maintainers/upgrade/#creating-new-release-notes)
As documented in the README's "Configuring wildcard SSL using DNS"
section, the necessary pieces for DNS-01 ACME challenges to work are
already baked into Traefik's recipe, though they were originally
considered for provisioning wildcard certificates. Furthermore, in
environments where the server is not exposed to the internet, the
default HTTP-01 challenge mechanism doesn't work, so taking advantage
of this alternative method makes complete sense.
This change causes ACME validations to be done always using DNS when
LETS_ENCRYPT_DNS_CHALLENGE_ENABLED is active. Without it, for standard
certificate requests Traefik uses the HTTP-01 challenge method, which
doesn't work in servers behind a firewall.
We should amend the related section in the
[operators handbook](https://docs.coopcloud.tech/operators/handbook/#running-an-offline-coop-cloud-server)
to make a not about the possibility of using DNS challenges in those
scenarios as well.
Nice, it looks good to me. I think @fauno will have to judge it. I have no way of testing this myself. Can merge if people have confidence in it 1) working 2) not breaking other peoples shit 🙃. Thanks for the work!
Nice, it looks good to me. I think @fauno will have to judge it. I have no way of testing this myself. Can merge if people have confidence in it 1) working 2) not breaking other peoples shit 🙃. Thanks for the work!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
As documented in the README's "Configuring wildcard SSL using DNS"
section, the necessary pieces for DNS-01 ACME challenges to work are
already baked into Traefik's recipe, though they were originally
considered for provisioning wildcard certificates. Furthermore, in
environments where the server is not exposed to the internet, the
default HTTP-01 challenge mechanism doesn't work, so, taking advantage
of this alternative method makes complete sense.
This change causes ACME validations to be done always using DNS when
LETS_ENCRYPT_DNS_CHALLENGE_ENABLED is active. Without it, for standard
certificate requests Traefik uses the HTTP-01 challenge method, which
doesn't work in servers behind a firewall.
We should amend the related section in the operators handbook
to make a not about the possibility of using DNS challenges in those
scenarios as well.
I tested this with both a server "exposed" to the internet and one behind a firewall. The first one continued to use the HTTP-01 challenge because no DNS-related settings were added to it, and the second one was successfully able to provision certificates (even though it's only reachable within the LAN).
abra.shNice, it looks good to me. I think @fauno will have to judge it. I have no way of testing this myself. Can merge if people have confidence in it 1) working 2) not breaking other peoples shit 🙃. Thanks for the work!
looks good!