ERROR: Challenge is invalid! (returned: ) (result: <<string>>) #310

Closed
opened 2025-12-29 01:22:17 +01:00 by adam · 8 comments
Owner

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: )" 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.
adam closed this issue 2025-12-29 01:22:18 +01:00
Author
Owner

@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>
@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> ```
Author
Owner

@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:

    # 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
@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 ```
Author
Owner

@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.

@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.
Author
Owner

@tjharman commented on GitHub (Mar 18, 2018):

root@animal:/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
root@animal:/usr/local/dehydrated#
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...
  + 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:53:30 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): ``` root@animal:/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 root@animal:/usr/local/dehydrated# ``` ``` 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... + 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:53:30 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> ```
Author
Owner

@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!

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 ```
Author
Owner

@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 --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...

@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...
Author
Owner

@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.

@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.
Author
Owner

@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! :-)

@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! :-)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#310