mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-11 22:30:44 +01:00
Incorrect validation certificate for tls-alpn-01 challenge #605
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @toasterparty on GitHub (May 14, 2023).
I'm trying to get my first cert for my first domain, toasterparty.net. As I understand, tls-alpn-01 via dehydrated are the best tools for the job since my ISP blocks port 80. I'm running Debian 11 in a headless configuration on standalone hardware. This error is what's stopping me from progressing:
Script
This is how I'm using dehydrated.
Error Log
This is the log of a full run:
dehydrated -e
These are my environment vars after loading
/config/config.confLet's Debug
Here's proof my domain records are correct:
Checking for TLS 1.3
Here's proof my machine can handle TLS 1.3:
alpn-responder.py
Here's the responder I'm using. It's the same as the provided example but using port 443 and
ALPNDIRis set to match the environment variable.Thanks for any time spent looking into this!
@toasterparty commented on GitHub (May 14, 2023):
To rule out file permission issues, I've already tried:
I've also tried calling dehydrated and/or the responder with and without
sudo@lukas2511 commented on GitHub (May 14, 2023):
Let's Debug doesn't really seem to check for the required certificate so that output is kinda useless.
Just to make sure the alpn validation certs are generated correctly maybe try running
openssl x509 -noout -text -in path/to/alpn/cert(you might need to kill dehydrated before it deletes the generated cert, maybe Ctrl+c works too, can't check that right now). The option mentioned in the error message should be somewhere in there.If you can see the option in the certificate I'd guess that there is still something either running on your machine and listening on port 443, or there's something in the path between Let's Encrypt and you, maybe your provider is also running some weird firewall that actually blocks the request or something like that.
@toasterparty commented on GitHub (May 15, 2023):
I figured it out!
The problem is simple, but the error is misleading:
In my responder I had:
When I needed:
This edit to

load_certificatemade it super obvious what was happening:@toasterparty commented on GitHub (May 15, 2023):
(and for the record you can examine the certificate with a well-timed CTRL+C)