Challenge is invalid #33

New Issue

adam · 2025-12-29T00:22:42+01:00

adam commented

2025-12-29 00:22:42 +01:00

Originally created by @KrisZane on GitHub (Jan 17, 2016).

So I am trying out this software just for kicks and seem to be getting a very odd error, that I can't find anything about:

Processing testdoman.com with alternative names: www.testdomain.com

Signing domains...
Generating private key...
Generating signing request...
Requesting challenge for testdomain.com...
Responding to challenge for testdomain.com...
ERROR: Challenge is invalid! (returned: invalid)

I can't really seem to find the reason for this error, even by inspecting the script?

Originally created by @KrisZane on GitHub (Jan 17, 2016). So I am trying out this software just for kicks and seem to be getting a very odd error, that I can't find anything about: Processing testdoman.com with alternative names: www.testdomain.com - Signing domains... - Generating private key... - Generating signing request... - Requesting challenge for testdomain.com... - Responding to challenge for testdomain.com... ERROR: Challenge is invalid! (returned: invalid) I can't really seem to find the reason for this error, even by inspecting the script?

adam closed this issue

2025-12-29 00:22:43 +01:00

adam commented

2025-12-29 00:22:44 +01:00

@leahoswald commented on GitHub (Jan 17, 2016):

Looks like you have a problem with the challenge response system to authenticat that you are in control over the domain. Do you have created the folder and alias for the challenge-response system?
For nginx it looks like this:

...
location /.well-known/acme-challenge {
  alias /var/www/letsencrypt;
}
...

For Apache:

...
Alias /.well-known/acme-challenge /var/www/letsencrypt/
...

Also you have to define the well known directory from above in the config:
config.sh:

...
WELLKNOWN="/var/www/letsencrypt"
...

@leahoswald commented on GitHub (Jan 17, 2016): Looks like you have a problem with the challenge response system to authenticat that you are in control over the domain. Do you have created the folder and alias for the challenge-response system? For nginx it looks like this: ``` ... location /.well-known/acme-challenge { alias /var/www/letsencrypt; } ... ``` For Apache: ``` ... Alias /.well-known/acme-challenge /var/www/letsencrypt/ ... ``` Also you have to define the well known directory from above in the config: config.sh: ``` ... WELLKNOWN="/var/www/letsencrypt" ... ```

adam commented

2025-12-29 00:22:45 +01:00

@KrisZane commented on GitHub (Jan 17, 2016):

I have defined the wellknown directory and I am guessing the alias part for nginx is necessary for some sort of testing?

Is there a way to do it, without having to add and then remove an alias from the system?

@KrisZane commented on GitHub (Jan 17, 2016): I have defined the wellknown directory and I am guessing the alias part for nginx is necessary for some sort of testing? Is there a way to do it, without having to add and then remove an alias from the system?

adam commented

2025-12-29 00:22:46 +01:00

@leahoswald commented on GitHub (Jan 17, 2016):

Yes you need the alias or have to customize the config a little to match your domains webroot. It is needed to allow letsencrypt read the response to the challenge they give to you to check if you are the owner of the domain you request a certificate for.

Is there a way to do it, without having to add and then remove an alias from the system?

Well you could also use/define the well-known dir under every single domain in its webroot. Its a lot of manual overhead especially if you want to automate the certificate renewal. So the alias is a simple way to enable the automated renewal in an easy way even if you use your nginx as reverse proxy without a webroot at all. So you don't have to remove the alias after the initial certificate request because you need it again for renewal after 90 days at the latest.

@leahoswald commented on GitHub (Jan 17, 2016): Yes you need the alias or have to customize the config a little to match your domains webroot. It is needed to allow letsencrypt read the response to the challenge they give to you to check if you are the owner of the domain you request a certificate for. > Is there a way to do it, without having to add and then remove an alias from the system? Well you could also use/define the well-known dir under every single domain in its webroot. Its a lot of manual overhead especially if you want to automate the certificate renewal. So the alias is a simple way to enable the automated renewal in an easy way even if you use your nginx as reverse proxy without a webroot at all. So you don't have to remove the alias after the initial certificate request because you need it again for renewal after 90 days at the latest.

adam commented

2025-12-29 00:22:47 +01:00

@KrisZane commented on GitHub (Jan 17, 2016):

Well my problem is that nothing actually gets put in the well known dir (possibly because of the error), and I would like to manually test it out, before putting it in my central distribution software?

To clarify, if there is a way to generate the certificate from one server and then distribute it to our load balanced nginx proxies later on?

@KrisZane commented on GitHub (Jan 17, 2016): Well my problem is that nothing actually gets put in the well known dir (possibly because of the error), and I would like to manually test it out, before putting it in my central distribution software? To clarify, if there is a way to generate the certificate from one server and then distribute it to our load balanced nginx proxies later on?

adam commented

2025-12-29 00:22:47 +01:00

@leahoswald commented on GitHub (Jan 17, 2016):

ok, than the following should work. Change the config.sh to:

...
WELLKNOWN="/path/to/your/domain/webroot/"
...

@leahoswald commented on GitHub (Jan 17, 2016): ok, than the following should work. Change the config.sh to: ``` ... WELLKNOWN="/path/to/your/domain/webroot/" ... ```

adam commented

2025-12-29 00:22:48 +01:00

@KrisZane commented on GitHub (Jan 17, 2016):

Well that is what I have already done and that is what is giving me the error. :)

@KrisZane commented on GitHub (Jan 17, 2016): Well that is what I have already done and that is what is giving me the error. :)

adam commented

2025-12-29 00:22:49 +01:00

@lukas2511 commented on GitHub (Jan 17, 2016):

The alias in the nginx config should exist so that nginx can deliver the challenge responses.
If you didn't configure it properly you should at least see a 404 or something similar in your webservers access-log.

Challenge responses get cleaned up even after errors, so you will not see any files there after the script stopped.

You can use the possibility to configure hooks to upload a file over ftp or something else, but you'll have to write a function or script for that.
There is a little bit more information about how to use hooks in config.sh.example.

Since this doesn't seem to be a problem with letsencrypt.sh I'll close this issue for now.

@lukas2511 commented on GitHub (Jan 17, 2016): The alias in the nginx config should exist so that nginx can deliver the challenge responses. If you didn't configure it properly you should at least see a 404 or something similar in your webservers access-log. Challenge responses get cleaned up even after errors, so you will not see any files there after the script stopped. You can use the possibility to configure hooks to upload a file over ftp or something else, but you'll have to write a function or script for that. There is a little bit more information about how to use hooks in `config.sh.example`. Since this doesn't seem to be a problem with letsencrypt.sh I'll close this issue for now.

adam commented

2025-12-29 00:22:49 +01:00

@bittorf commented on GitHub (Feb 18, 2016):

i wonder why WELLKNOWN is unset during script-startup. if not we can just invoke like this and it works without changing anything:

root@server1:~/letsencrypt.sh# WELLKNOWN=/var/www/.well-known/acme-challenge ./letsencrypt.sh  --cron
#
# !! WARNING !! No main config file found, using default config!
#
Processing 4.v.weimarnetz.de   
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Mar  4 13:26:00 2016 GMT (Less than 30 days). Renewing!
 + Signing domains...
 + Generating signing request...
 + Requesting challenge for 4.v.weimarnetz.de...
 + Responding to challenge for 4.v.weimarnetz.de...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!
Processing 4.v.weimarnetz.de
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till May 18 07:30:00 2016 GMT (Longer than 30 days). Skipping!

@bittorf commented on GitHub (Feb 18, 2016): i wonder why WELLKNOWN is unset during script-startup. if not we can just invoke like this and it works without changing anything: ``` root@server1:~/letsencrypt.sh# WELLKNOWN=/var/www/.well-known/acme-challenge ./letsencrypt.sh --cron # # !! WARNING !! No main config file found, using default config! # Processing 4.v.weimarnetz.de + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till Mar 4 13:26:00 2016 GMT (Less than 30 days). Renewing! + Signing domains... + Generating signing request... + Requesting challenge for 4.v.weimarnetz.de... + Responding to challenge for 4.v.weimarnetz.de... + Challenge is valid! + Requesting certificate... + Checking certificate... + Done! + Creating fullchain.pem... + Done! Processing 4.v.weimarnetz.de + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till May 18 07:30:00 2016 GMT (Longer than 30 days). Skipping! ```

adam commented

2025-12-29 00:22:49 +01:00

@flittermice commented on GitHub (Mar 10, 2016):

I had the same promlem like KrisZane.
It turned out that my server didn't respond to normal HTTP requests. So I reopened port 80 and made a virtual host for HTTP:

Listen 80

<VirtualHost *:80>
ServerName xxxxxx.eu
DocumentRoot /var/www/html

=> Works great now.
Thanks for sparing me the use of the bloated official client!

@flittermice commented on GitHub (Mar 10, 2016): I had the same promlem like KrisZane. It turned out that my server didn't respond to normal HTTP requests. So I reopened port 80 and made a virtual host for HTTP: Listen 80 <VirtualHost *:80> ServerName xxxxxx.eu DocumentRoot /var/www/html </VirtualHost> => Works great now. Thanks for sparing me the use of the bloated official client!

adam commented

2025-12-29 00:22:49 +01:00

@Petelin commented on GitHub (Nov 10, 2016):

WELLKNOWN="/path/to/your/domain/webroot/" work for me. thanks.

@Petelin commented on GitHub (Nov 10, 2016): WELLKNOWN="/path/to/your/domain/webroot/" work for me. thanks.

adam commented

2025-12-29 00:22:50 +01:00

@TyrfingMjolnir commented on GitHub (Sep 12, 2017):

I have this same issue, I added a file named "1.txt" in the folder owned by www:www just for testing

$ curl http://www.domain.tld/.well-known/acme-challenge/1.txt

<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.7.4</center>
</body>
</html>

Excerpt from log:

10.0.0.104 - - [12/Sep/2017:20:36:01 +0000] "GET /.well-known/acme-challenge/1.txt HTTP/1.1" 404 168 "-" "curl/7.38.0" "-"

@TyrfingMjolnir commented on GitHub (Sep 12, 2017): I have this same issue, I added a file named "1.txt" in the folder owned by www:www just for testing ```BASh $ curl http://www.domain.tld/.well-known/acme-challenge/1.txt ``` ```HTML <html> <head><title>404 Not Found</title></head> <body bgcolor="white"> <center><h1>404 Not Found</h1></center> <hr><center>nginx/1.7.4</center> </body> </html> ``` Excerpt from log: ``` 10.0.0.104 - - [12/Sep/2017:20:36:01 +0000] "GET /.well-known/acme-challenge/1.txt HTTP/1.1" 404 168 "-" "curl/7.38.0" "-" ```

adam commented

2025-12-29 00:22:50 +01:00

@txr13 commented on GitHub (Sep 12, 2017):

@TyrfingMjolnir This is a very old issue, and has been closed for almost 21 months now. Would you like to open a new issue?

@txr13 commented on GitHub (Sep 12, 2017): @TyrfingMjolnir This is a very old issue, and has been closed for almost 21 months now. Would you like to open a new issue?

adam referenced this issue

2025-12-29 01:28:24 +01:00

[PR #33] [MERGED] Move cleaning challenge in order to clean when challenge is valid and when challenge is invalid. #673

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#33