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

feat: DNS-01 challenge support #1137

Merged
merged 13 commits into from
Jul 29, 2024
Merged

feat: DNS-01 challenge support #1137

merged 13 commits into from
Jul 29, 2024

Conversation

buchdag
Copy link
Member

@buchdag buchdag commented Jul 15, 2024

This PR pick up the work done by @daweedm in #1022 ( thanks 👍 )

I tested it with Gandi Live DNS, seems to work without issue.

@pini-gh I know you worked on a DNS-01 fork too, so a review would be welcome.

Ideally I'd also like this to include wildcard certificate compatibility before merge.

@buchdag buchdag added the type/feat PR for a new feature label Jul 15, 2024
@buchdag buchdag self-assigned this Jul 15, 2024
Co-authored-by: Nicolas Duchon <nicolas.duchon@gmail.com>
Co-authored-by: Gilles Filippini <pini@debian.org>
@buchdag
Copy link
Member Author

buchdag commented Jul 16, 2024

Added support for wildcard certificates.

@buchdag buchdag linked an issue Jul 16, 2024 that may be closed by this pull request
@buchdag
Copy link
Member Author

buchdag commented Jul 16, 2024

This is available as nginxproxy/acme-companion:dns01 on Dockerhub for anyone who want to try it.

@pini-gh
Copy link
Contributor

pini-gh commented Jul 16, 2024

LGTM.

@pgassmann
Copy link

Can you support configuring the ACMESH_DNS_API_CONFIG on the acme-companion container instead of the proxied application?
Usually one DNS API config per proxy should be enough and in that way, the api token is not available to the proxied application.
You coud add a DEFAULT_ACMESH_DNS_API_CONFIG, like the DEFAULT_EMAIL

@buchdag
Copy link
Member Author

buchdag commented Jul 16, 2024

@pgassmann done, updated the nginxproxy/acme-companion:dns01 image, will update docs later.

The environment variable name on the acme-companion container is ACMESH_DNS_API_CONFIG, same as the proxied containers. By convention same name variables on the companion and proxied containers are meant to be default when set on the companion container.

@buchdag
Copy link
Member Author

buchdag commented Jul 17, 2024

I don't think this can be tested in CI without obtaining a certificate from a real CA (let's say from Let's Encrypt staging environment) for a real domain whose DNS can be manipulated by acme.sh DNS API. I have a few ideas how to do this but I think it'll need some changes to the test system setup itself before, so this feature will probably ship without CI tests at first.

app/start.sh Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
@buchdag buchdag marked this pull request as ready for review July 19, 2024 10:09
@buchdag
Copy link
Member Author

buchdag commented Jul 26, 2024

If there isn't any further comment or review on this, I'll think I'll merge it on Sunday or Monday.

@cxhamilton
Copy link

I tested this feature branch on a real host.domain.tld on Namecheap and the DNS challenge worked perfectly.

Then, I changed LETSENCRYPT_HOST in my container's YAML from host.domain.tld to *.domain.tld. It also worked, but I'm getting an SSL error when I try to access https://host.domain.tld.

Is there something I'm doing wrong from a wildcard domain perspective?

@pini-gh
Copy link
Contributor

pini-gh commented Jul 28, 2024

I'm getting an SSL error

Would you mind giving a few more details?

@cxhamilton
Copy link

I was trying to provide detailed documentation, going step-by-step to reproduce the problem, but I can no longer do so.

I've also added a second service using the same wildcard value for LETSENCRYPT_HOST and it works as expected.

For reference, here is a relevant sample from a docker compose file:

services:
    heimdall:
        container_name: heimdall
        image: lscr.io/linuxserver/heimdall:latest
        environment:
            - PUID=${PUID}
            - PGID=${PGID}
            - TZ=${TZ}
            - VIRTUAL_HOST=heimdall.mydomain.com
            - LETSENCRYPT_HOST=*.mydomain.com

The certs that are being installed by acme-companion:

[Sun Jul 28 14:04:24 UTC 2024] Installing cert to: /etc/nginx/certs/wildcard_mydomain.com/cert.pem
[Sun Jul 28 14:04:24 UTC 2024] Installing CA to: /etc/nginx/certs/wildcard_mydomain.com/chain.pem
[Sun Jul 28 14:04:24 UTC 2024] Installing key to: /etc/nginx/certs/wildcard_mydomain.com/key.pem
[Sun Jul 28 14:04:24 UTC 2024] Installing full chain to: /etc/nginx/certs/wildcard_mydomain.com/fullchain.pem

At this point, I assume that it was a mistake that I made in the configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/feat PR for a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support wildcard certificates with ACMEv2
4 participants