Today I did a git pull to ensure I'm at the latest, and recieved this:
root@beaker:/usr/local/dehydrated# ./force-update.sh
#
# !! WARNING !! No main config file found, using default config!
#
! Reusing account from https://acme-v01.api.letsencrypt.org/directory
Processing muppetz.com with alternative names: beaker.muppetz.com reader.muppetz.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till May 26 20:29:32 2018 GMT (Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 3 authorizations URLs from the CA
+ Handling authorization for beaker.muppetz.com
+ Handling authorization for muppetz.com
+ Handling authorization for reader.muppetz.com
+ 3 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for beaker.muppetz.com authorization...
+ Challenge is valid!
+ Responding to challenge for muppetz.com authorization...
+ Challenge is valid!
+ Responding to challenge for reader.muppetz.com authorization...
+ Challenge is valid!
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
+ Done!
RSA certs renewed no problems.
But ECC gives me this:
#
# !! WARNING !! No main config file found, using default config!
#
Processing muppetz.com with alternative names: beaker.muppetz.com www.muppetz.com lice.muppetz.com tjharman.com www.tjharman.com old.tjharman.com gallery.tjharman.com mat
chboxdigital.co.nz www.matchboxdigital.co.nz tasks.muppetz.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till May 26 20:31:34 2018 GMT (Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 11 authorizations URLs from the CA
+ Handling authorization for beaker.muppetz.com
+ Handling authorization for old.tjharman.com
+ Handling authorization for tasks.muppetz.com
+ Handling authorization for muppetz.com
+ Handling authorization for www.tjharman.com
+ Handling authorization for www.matchboxdigital.co.nz
+ Handling authorization for tjharman.com
+ Handling authorization for www.muppetz.com
+ Handling authorization for matchboxdigital.co.nz
+ Handling authorization for gallery.tjharman.com
+ Handling authorization for lice.muppetz.com
+ 11 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for beaker.muppetz.com authorization...
ERROR: Challenge is invalid! (returned: ) (result: fq0ldiV16BvDY5h2kbgSF8aQFtrU9DJnloBtFgQ7nN8.9l54mws_vhiPTBOBS52dImBuq0Tuw5VY5jxC8qeBK1w)
I have been getting a similar problem with ECC certs on another box for other *.muppetz.com domains, the "ERROR: Challenge is invalid! (returned: ) (result: )" using the latest dehydrated, but I had assumed this was a rate-limit error on that machine and ignored it for the moment.
I have no problems accessing the /.well-known/acme-challenge/XXXX URL - this has been setup in Apache for the last ~year with no issues (and works, as you can see in the RSA request)
What does "ERROR: Challenge is invalid! (returned: ) (result: <>)" mean?
As I stated above, I thought on my other box it was a rate limit issue, but I have tried only twice to renew these ECC certs and am sure I'm not being rate limited yet.
Originally created by @tjharman on GitHub (Mar 18, 2018).
Hi,
I am not 100% sure this is a dehydrated issues, however it's just started on two different servers I control.
I can't seem to create ECC certificates anymore, only RSA ones.
I have the following script I run every couple of weeks to generate my certs:
```
# RSA Certificates
/usr/local/dehydrated/dehydrated -c -x -d muppetz.com -d beaker.muppetz.com -d reader.muppetz.com -o /etc/letsencrypt/rsa -a rsa
# ECC Certificates
/usr/local/dehydrated/dehydrated -c -x -d muppetz.com -d beaker.muppetz.com -d www.muppetz.com -d lice.muppetz.com -d tjharman.com -d www.tjharman.com -d old.tjharman.com
-d gallery.tjharman.com -d matchboxdigital.co.nz -d www.matchboxdigital.co.nz -d tasks.muppetz.com -o /etc/letsencrypt/ecc -a secp384r1
```
Today I did a git pull to ensure I'm at the latest, and recieved this:
```
root@beaker:/usr/local/dehydrated# ./force-update.sh
#
# !! WARNING !! No main config file found, using default config!
#
! Reusing account from https://acme-v01.api.letsencrypt.org/directory
Processing muppetz.com with alternative names: beaker.muppetz.com reader.muppetz.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till May 26 20:29:32 2018 GMT (Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 3 authorizations URLs from the CA
+ Handling authorization for beaker.muppetz.com
+ Handling authorization for muppetz.com
+ Handling authorization for reader.muppetz.com
+ 3 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for beaker.muppetz.com authorization...
+ Challenge is valid!
+ Responding to challenge for muppetz.com authorization...
+ Challenge is valid!
+ Responding to challenge for reader.muppetz.com authorization...
+ Challenge is valid!
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
+ Done!
```
RSA certs renewed no problems.
But ECC gives me this:
```
#
# !! WARNING !! No main config file found, using default config!
#
Processing muppetz.com with alternative names: beaker.muppetz.com www.muppetz.com lice.muppetz.com tjharman.com www.tjharman.com old.tjharman.com gallery.tjharman.com mat
chboxdigital.co.nz www.matchboxdigital.co.nz tasks.muppetz.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till May 26 20:31:34 2018 GMT (Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 11 authorizations URLs from the CA
+ Handling authorization for beaker.muppetz.com
+ Handling authorization for old.tjharman.com
+ Handling authorization for tasks.muppetz.com
+ Handling authorization for muppetz.com
+ Handling authorization for www.tjharman.com
+ Handling authorization for www.matchboxdigital.co.nz
+ Handling authorization for tjharman.com
+ Handling authorization for www.muppetz.com
+ Handling authorization for matchboxdigital.co.nz
+ Handling authorization for gallery.tjharman.com
+ Handling authorization for lice.muppetz.com
+ 11 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for beaker.muppetz.com authorization...
ERROR: Challenge is invalid! (returned: ) (result: fq0ldiV16BvDY5h2kbgSF8aQFtrU9DJnloBtFgQ7nN8.9l54mws_vhiPTBOBS52dImBuq0Tuw5VY5jxC8qeBK1w)
```
I have been getting a similar problem with ECC certs on another box for other *.muppetz.com domains, the "ERROR: Challenge is invalid! (returned: ) (result: <long string>)" using the latest dehydrated, but I had assumed this was a rate-limit error on that machine and ignored it for the moment.
I have no problems accessing the /.well-known/acme-challenge/XXXX URL - this has been setup in Apache for the last ~year with no issues (and works, as you can see in the RSA request)
What does "ERROR: Challenge is invalid! (returned: ) (result: <<string>>)" mean?
As I stated above, I thought on my other box it was a rate limit issue, but I have tried only twice to renew these ECC certs and am sure I'm not being rate limited yet.
So I thought I'd test on a third server I have, this one runs nginx.
This is now really confusing me:
root@animal:/usr/local/dehydrated# /usr/local/dehydrated/dehydrated -c -x -d animal.muppetz.com -o /etc/letsencrypt/rsa
#
# !! WARNING !! No main config file found, using default config!
#
Processing animal.muppetz.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Jun 2 16:30:49 2018 GMT Certificate will not expire
(Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 1 authorizations URLs from the CA
+ Handling authorization for animal.muppetz.com
+ 1 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for animal.muppetz.com authorization...
+ ERROR: An error occurred while sending post-request to http://animal.muppetz.com/.well-known/acme-challenge/h8jAxFPy95srhCfs7EWNlwub9MGkL9SQ5UczQP68XH8 (Status 405)
Details:
HTTP/1.1 405 Not Allowed
Server: nginx/1.10.3
Date: Sun, 18 Mar 2018 18:07:50 GMT
Content-Type: text/html
Content-Length: 173
Connection: keep-alive
<html>
<head><title>405 Not Allowed</title></head>
<body bgcolor="white">
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.10.3</center>
</body>
</html>
@tjharman commented on GitHub (Mar 18, 2018):
So I thought I'd test on a _third_ server I have, this one runs nginx.
This is now really confusing me:
```
root@animal:/usr/local/dehydrated# /usr/local/dehydrated/dehydrated -c -x -d animal.muppetz.com -o /etc/letsencrypt/rsa
#
# !! WARNING !! No main config file found, using default config!
#
Processing animal.muppetz.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Jun 2 16:30:49 2018 GMT Certificate will not expire
(Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 1 authorizations URLs from the CA
+ Handling authorization for animal.muppetz.com
+ 1 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for animal.muppetz.com authorization...
+ ERROR: An error occurred while sending post-request to http://animal.muppetz.com/.well-known/acme-challenge/h8jAxFPy95srhCfs7EWNlwub9MGkL9SQ5UczQP68XH8 (Status 405)
Details:
HTTP/1.1 405 Not Allowed
Server: nginx/1.10.3
Date: Sun, 18 Mar 2018 18:07:50 GMT
Content-Type: text/html
Content-Length: 173
Connection: keep-alive
<html>
<head><title>405 Not Allowed</title></head>
<body bgcolor="white">
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.10.3</center>
</body>
</html>
```
This is really weird... dehydrated shouldn't try to access the http://whatever/.well-known/... URL itself, especially not with a post request... The only way I see this would be possible is if challenge_uris somehow contains that url... which would be really weird... Can you please modify the code a bit and show me the result:
@lukas2511 commented on GitHub (Mar 18, 2018):
This is really weird... dehydrated shouldn't try to access the `http://whatever/.well-known/...` URL itself, especially not with a post request... The only way I see this would be possible is if challenge_uris somehow contains that url... which would be really weird... Can you please modify the code a bit and show me the result:
```bash
# Gather challenge information
echo "${challenge}" # <---- ADD THIS
challenge_names[${idx}]="${identifier}"
challenge_tokens[${idx}]="$(echo "${challenge}" | get_json_string_value token)"
if [[ ${API} -eq 2 ]]; then
challenge_uris[${idx}]="$(echo "${challenge}" | get_json_string_value url)"
else
challenge_uris[${idx}]="$(echo "${challenge}" | get_json_string_value uri)"
fi
```
And please post the output of dehydrated --version so I can get an idea about the environment you are running dehydrated in.
@lukas2511 commented on GitHub (Mar 18, 2018):
And please post the output of `dehydrated --version` so I can get an idea about the environment you are running dehydrated in.
I should note, the NGINX server is the 3rd server I'm having problems with.
The previous two that I posted where I get the ERROR: Challenge is invalid! (returned: ) (result: <>) are Apache2 servers.
Here's the (modified) output from the main one I wish to fix!
root@micro:/usr/local/dehydrated# /usr/local/dehydrated/dehydrated -c -x -d micro.muppetz.com -d radio.muppetz.com -o /etc/letsencrypt/rsa
#
# !! WARNING !! No main config file found, using default config!
#
Processing micro.muppetz.com with alternative names: radio.muppetz.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Apr 28 16:12:49 2018 GMT Certificate will not expire
(Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 2 authorizations URLs from the CA
+ Handling authorization for micro.muppetz.com
{"type": "http-01", "status": "valid", "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/6b2cKCYIAoY_RWbkrAz4gWuhBrcmPitQExSyd8wIAsM/3842916042", "token": "04l7-H7dn-ijQgoUVgxmJMy27q7mFtjIhfEENNzzj_Q", "validationRecord": [{"url": "http://micro.muppetz.com/.well-known/acme-challenge/04l7-H7dn-ijQgoUVgxmJMy27q7mFtjIhfEENNzzj_Q", "hostname": "micro.muppetz.com", "port": "80", "addressesResolved": ["202.137.243.17"], "addressUsed": "202.137.243.17"}
+ Handling authorization for radio.muppetz.com
{"type": "http-01", "status": "valid", "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/ae9-XbVpG49NcV_a4rrthu40zd2DMKD63-_X7vWbNr4/3842916045", "token": "7do2inPqAdUIi-Yi__gmL0gmJC1X5Rc30DwcJ6HuMp0", "validationRecord": [{"url": "http://radio.muppetz.com/.well-known/acme-challenge/7do2inPqAdUIi-Yi__gmL0gmJC1X5Rc30DwcJ6HuMp0", "hostname": "radio.muppetz.com", "port": "80", "addressesResolved": ["202.137.243.17"], "addressUsed": "202.137.243.17"}
+ 2 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for micro.muppetz.com authorization...
ERROR: Challenge is invalid! (returned: ) (result: 04l7-H7dn-ijQgoUVgxmJMy27q7mFtjIhfEENNzzj_Q.CVIsPnr1yFW9cY9rBQ7yPCDbeHFkCHHnemmEZTRD8T8)
root@micro:/usr/local/dehydrated# ./dehydrated --version
#
# !! WARNING !! No main config file found, using default config!
#
Dehydrated by Lukas Schauer
https://dehydrated.de
Dehydrated version: git-master-after-0.6.1
GIT-Revision: 7c40c727a0e933382d72fa689ff3bea294895326
OS: Debian GNU/Linux 9
Used software:
bash: 4.4.12(1)-release
curl: curl 7.52.1
awk: GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.5, GNU MP 6.1.2)
sed: sed (GNU sed) 4.4
mktemp: mktemp (GNU coreutils) 8.26
grep: grep (GNU grep) 2.27
diff: diff (GNU diffutils) 3.5
openssl: OpenSSL 1.1.0f 25 May 2017
@tjharman commented on GitHub (Mar 18, 2018):
I should note, the NGINX server is the 3rd server I'm having problems with.
The previous two that I posted where I get the ERROR: Challenge is invalid! (returned: ) (result: <<string>>) are Apache2 servers.
Here's the (modified) output from the main one I wish to fix!
```
root@micro:/usr/local/dehydrated# /usr/local/dehydrated/dehydrated -c -x -d micro.muppetz.com -d radio.muppetz.com -o /etc/letsencrypt/rsa
#
# !! WARNING !! No main config file found, using default config!
#
Processing micro.muppetz.com with alternative names: radio.muppetz.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Apr 28 16:12:49 2018 GMT Certificate will not expire
(Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 2 authorizations URLs from the CA
+ Handling authorization for micro.muppetz.com
{"type": "http-01", "status": "valid", "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/6b2cKCYIAoY_RWbkrAz4gWuhBrcmPitQExSyd8wIAsM/3842916042", "token": "04l7-H7dn-ijQgoUVgxmJMy27q7mFtjIhfEENNzzj_Q", "validationRecord": [{"url": "http://micro.muppetz.com/.well-known/acme-challenge/04l7-H7dn-ijQgoUVgxmJMy27q7mFtjIhfEENNzzj_Q", "hostname": "micro.muppetz.com", "port": "80", "addressesResolved": ["202.137.243.17"], "addressUsed": "202.137.243.17"}
+ Handling authorization for radio.muppetz.com
{"type": "http-01", "status": "valid", "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/ae9-XbVpG49NcV_a4rrthu40zd2DMKD63-_X7vWbNr4/3842916045", "token": "7do2inPqAdUIi-Yi__gmL0gmJC1X5Rc30DwcJ6HuMp0", "validationRecord": [{"url": "http://radio.muppetz.com/.well-known/acme-challenge/7do2inPqAdUIi-Yi__gmL0gmJC1X5Rc30DwcJ6HuMp0", "hostname": "radio.muppetz.com", "port": "80", "addressesResolved": ["202.137.243.17"], "addressUsed": "202.137.243.17"}
+ 2 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for micro.muppetz.com authorization...
ERROR: Challenge is invalid! (returned: ) (result: 04l7-H7dn-ijQgoUVgxmJMy27q7mFtjIhfEENNzzj_Q.CVIsPnr1yFW9cY9rBQ7yPCDbeHFkCHHnemmEZTRD8T8)
root@micro:/usr/local/dehydrated# ./dehydrated --version
#
# !! WARNING !! No main config file found, using default config!
#
Dehydrated by Lukas Schauer
https://dehydrated.de
Dehydrated version: git-master-after-0.6.1
GIT-Revision: 7c40c727a0e933382d72fa689ff3bea294895326
OS: Debian GNU/Linux 9
Used software:
bash: 4.4.12(1)-release
curl: curl 7.52.1
awk: GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.5, GNU MP 6.1.2)
sed: sed (GNU sed) 4.4
mktemp: mktemp (GNU coreutils) 8.26
grep: grep (GNU grep) 2.27
diff: diff (GNU diffutils) 3.5
openssl: OpenSSL 1.1.0f 25 May 2017
```
I'm going to soon replace all the JSON parsing in dehydrated with parts of JSON.sh, that should avoid issues like this in the future...
@lukas2511 commented on GitHub (Mar 18, 2018):
Aww crap I don't think i've ever seen that validationRecord before, dehydrated matches on that, that's why the url is broken...
Can you try this patch?
```diff
diff --git a/dehydrated b/dehydrated
index 473bbf1..b9a8922 100755
--- a/dehydrated
+++ b/dehydrated
@@ -735,9 +735,9 @@ sign_csr() {
challenge_names[${idx}]="${identifier}"
challenge_tokens[${idx}]="$(echo "${challenge}" | get_json_string_value token)"
if [[ ${API} -eq 2 ]]; then
- challenge_uris[${idx}]="$(echo "${challenge}" | get_json_string_value url)"
+ challenge_uris[${idx}]="$(echo "${challenge}" | _sed 's/"validationRecord": ?\[[^]]+\]//g' | get_json_string_value url)"
else
- challenge_uris[${idx}]="$(echo "${challenge}" | get_json_string_value uri)"
+ challenge_uris[${idx}]="$(echo "${challenge}" | _sed 's/"validationRecord": ?\[[^]]+\]//g' | get_json_string_value uri)"
fi
# Prepare challenge tokens and deployment parameters
```
I'm going to soon replace all the JSON parsing in dehydrated with parts of JSON.sh, that should avoid issues like this in the future...
Btw. this issue should only occur while using the --force (-x) parameter, normal operation shouldn't be affected.
@lukas2511 commented on GitHub (Mar 18, 2018):
Btw. this issue should only occur while using the `--force (-x)` parameter, normal operation shouldn't be affected.
Can confirm, your patch fixes the problem for me!
Thank you:
root@animal:/usr/local/dehydrated# /usr/local/dehydrated/dehydrated -c -x -d animal.muppetz.com -o /etc/letsencrypt/rsa
#
# !! WARNING !! No main config file found, using default config!
#
Processing animal.muppetz.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Jun 2 16:30:49 2018 GMT Certificate will not expire
(Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 1 authorizations URLs from the CA
+ Handling authorization for animal.muppetz.com
{"type": "http-01", "status": "valid", "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/umBGaJbxT4RyVXE0EHbAK5ahIB8bxYWcI_0YQvIGs0Y/3867860225", "token": "h8jAxFPy95srhCfs7EWNlwub9MGkL9SQ5UczQP68XH8", "validationRecord": [{"url": "http://animal.muppetz.com/.well-known/acme-challenge/h8jAxFPy95srhCfs7EWNlwub9MGkL9SQ5UczQP68XH8", "hostname": "animal.muppetz.com", "port": "80", "addressesResolved": ["205.233.254.38"], "addressUsed": "205.233.254.38"}
+ 1 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for animal.muppetz.com authorization...
+ Challenge is valid!
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
+ Done!
This has also fixed the problem on my two other boxes!
THANK YOU! :-)
@tjharman commented on GitHub (Mar 18, 2018):
Can confirm, your patch fixes the problem for me!
Thank you:
```
root@animal:/usr/local/dehydrated# /usr/local/dehydrated/dehydrated -c -x -d animal.muppetz.com -o /etc/letsencrypt/rsa
#
# !! WARNING !! No main config file found, using default config!
#
Processing animal.muppetz.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Jun 2 16:30:49 2018 GMT Certificate will not expire
(Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 1 authorizations URLs from the CA
+ Handling authorization for animal.muppetz.com
{"type": "http-01", "status": "valid", "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/umBGaJbxT4RyVXE0EHbAK5ahIB8bxYWcI_0YQvIGs0Y/3867860225", "token": "h8jAxFPy95srhCfs7EWNlwub9MGkL9SQ5UczQP68XH8", "validationRecord": [{"url": "http://animal.muppetz.com/.well-known/acme-challenge/h8jAxFPy95srhCfs7EWNlwub9MGkL9SQ5UczQP68XH8", "hostname": "animal.muppetz.com", "port": "80", "addressesResolved": ["205.233.254.38"], "addressUsed": "205.233.254.38"}
+ 1 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for animal.muppetz.com authorization...
+ Challenge is valid!
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
+ Done!
```
This has also fixed the problem on my two other boxes!
THANK YOU! :-)
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.
Originally created by @tjharman on GitHub (Mar 18, 2018).
Hi,
I am not 100% sure this is a dehydrated issues, however it's just started on two different servers I control.
I can't seem to create ECC certificates anymore, only RSA ones.
I have the following script I run every couple of weeks to generate my certs:
Today I did a git pull to ensure I'm at the latest, and recieved this:
RSA certs renewed no problems.
But ECC gives me this:
I have been getting a similar problem with ECC certs on another box for other *.muppetz.com domains, the "ERROR: Challenge is invalid! (returned: ) (result: )" using the latest dehydrated, but I had assumed this was a rate-limit error on that machine and ignored it for the moment.
I have no problems accessing the /.well-known/acme-challenge/XXXX URL - this has been setup in Apache for the last ~year with no issues (and works, as you can see in the RSA request)
What does "ERROR: Challenge is invalid! (returned: ) (result: <>)" mean?
As I stated above, I thought on my other box it was a rate limit issue, but I have tried only twice to renew these ECC certs and am sure I'm not being rate limited yet.
@tjharman commented on GitHub (Mar 18, 2018):
So I thought I'd test on a third server I have, this one runs nginx.
This is now really confusing me:
@lukas2511 commented on GitHub (Mar 18, 2018):
This is really weird... dehydrated shouldn't try to access the
http://whatever/.well-known/...URL itself, especially not with a post request... The only way I see this would be possible is if challenge_uris somehow contains that url... which would be really weird... Can you please modify the code a bit and show me the result:@lukas2511 commented on GitHub (Mar 18, 2018):
And please post the output of
dehydrated --versionso I can get an idea about the environment you are running dehydrated in.@tjharman commented on GitHub (Mar 18, 2018):
@tjharman commented on GitHub (Mar 18, 2018):
I should note, the NGINX server is the 3rd server I'm having problems with.
The previous two that I posted where I get the ERROR: Challenge is invalid! (returned: ) (result: <>) are Apache2 servers.
Here's the (modified) output from the main one I wish to fix!
@lukas2511 commented on GitHub (Mar 18, 2018):
Aww crap I don't think i've ever seen that validationRecord before, dehydrated matches on that, that's why the url is broken...
Can you try this patch?
I'm going to soon replace all the JSON parsing in dehydrated with parts of JSON.sh, that should avoid issues like this in the future...
@lukas2511 commented on GitHub (Mar 18, 2018):
Btw. this issue should only occur while using the
--force (-x)parameter, normal operation shouldn't be affected.@tjharman commented on GitHub (Mar 18, 2018):
Can confirm, your patch fixes the problem for me!
Thank you:
This has also fixed the problem on my two other boxes!
THANK YOU! :-)