Hi,
i have a domainname to renew, but all i get is status=pending.
any other domain on the server got renewd, what now ?
Could you provide some more details, i.e. which client are you using, what’s the command you’re running and the output you’re seeing, plus maybe any log files (in /var/log/letsencrypt if you’re using the official client)?
No problem:
I’m using this github.com/lukas2511/letsencrypt.sh
[root@s36 letsencrypt]# ./letsencrypt.sh -c -d webmail.heimatverein-gloinetal-magdeburgerforth.de -d www.heimatverein-gloinetal-magdeburgerforth.de -d heimatverein-gloinetal-magdeburgerforth.de -d heimatverein-gloinetal-magdeburgerforth.de
Using config file /etc/httpd/letsencrypt/config.sh
Processing webmail.heimatverein-gloinetal-magdeburgerforth.de with SAN: www.heimatverein-gloinetal-magdeburgerforth.de heimatverein-gloinetal-magdeburgerforth.de heimatverein-gloinetal-magdeburgerforth.de
- Signing domains…
- Generating private key…
- Generating signing request…
- Requesting challenge for webmail.heimatverein-gloinetal-magdeburgerforth.de…
- Responding to challenge for webmail.heimatverein-gloinetal-magdeburgerforth.de…
{“type”:“http-01”,“status”:“pending”,“uri”:“h-t-t-p-s-:-/-/-a-c-m-e—v-0-1-.-a-p-i-.-l-e-t-s-e-n-c-r-y-p-t.org/acme/challenge/7ftGAV2gxxWnohIAl_Aq60JWZOSNhuR_4rQH5bRpUEA/74809467”,“token”:“bDZxoGLIuz28jHDH0Ga5nDQ-erAKfXdUW9WWKeWLSd8”,“keyAuthorization”:“bDZxoGLIuz28jHDH0Ga5nDQ-erAKfXdUW9WWKeWLSd8.e5FZjrnwb1SZURXTovcByAXqtydN8vSfcQLBNTs0yiM”}
invalid - Challenge is invalid! (returned: invalid)
I added the extra output, usually it does not give me the json to debug stuff. and this forum software complained about “not more than 2 links for new users” ? the url is ofcourse the correct one with the “-”'s .
The same server, same client, same options for different domains, works great. This is the first issue i have since dec. 2015.
As you can see here, it tries it since April the 13th.
ls -la certs/heimatverein-gloinetal-magdeburgerforth.de/
insgesamt 124
4 -rw------- 1 root root 1793 27. Jan 13:00 cert-1453896049.csr
4 -rw------- 1 root root 2281 23. Mär 23:48 cert-1453896049.pem
4 -rw------- 1 root root 1793 13. Apr 00:00 cert-1460498437.csr
4 -rw------- 1 root root 1793 14. Apr 00:00 cert-1460584825.csr
4 -rw------- 1 root root 1793 15. Apr 00:00 cert-1460671216.csr
4 -rw------- 1 root root 1793 16. Apr 00:00 cert-1460757617.csr
4 -rw------- 1 root root 1793 17. Apr 00:00 cert-1460844019.csr
4 -rw------- 1 root root 1793 18. Apr 00:00 cert-1460930416.csr
4 -rw------- 1 root root 1793 19. Apr 00:00 cert-1461016816.csr
4 -rw------- 1 root root 1793 20. Apr 00:00 cert-1461103216.csr
4 -rw------- 1 root root 1793 21. Apr 00:00 cert-1461189617.csr
4 -rw------- 1 root root 1793 22. Apr 00:00 cert-1461276016.csr
4 -rw------- 1 root root 1793 23. Apr 00:00 cert-1461362417.csr
4 -rw------- 1 root root 1793 24. Apr 00:00 cert-1461448816.csr
4 -rw------- 1 root root 1793 25. Apr 00:00 cert-1461535215.csr
4 -rw------- 1 root root 1793 26. Apr 00:00 cert-1461621616.csr
4 -rw------- 1 root root 1793 27. Apr 00:00 cert-1461708016.csr
4 -rw------- 1 root root 1793 28. Apr 00:00 cert-1461794416.csr
4 -rw------- 1 root root 1793 29. Apr 00:00 cert-1461880815.csr
4 -rw------- 1 root root 1793 30. Apr 00:00 cert-1461967226.csr
4 -rw------- 1 root root 1793 1. Mai 00:00 cert-1462053628.csr
4 -rw------- 1 root root 1793 2. Mai 00:00 cert-1462140016.csr
4 -rw------- 1 root root 1793 3. Mai 00:00 cert-1462226418.csr
4 -rw------- 1 root root 1793 4. Mai 00:00 cert-1462312826.csr
4 -rw------- 1 root root 1793 5. Mai 00:00 cert-1462399217.csr
4 -rw------- 1 root root 1793 5. Mai 17:02 cert-1462460532.csr
4 -rw------- 1 root root 1793 5. Mai 21:55 cert-1462478158.csr
4 -rw------- 1 root root 1793 6. Mai 00:00 cert-1462485616.csr
0 lrwxrwxrwx 1 root root 19 27. Jan 13:01 cert.csr -> cert-1453896049.csr
0 lrwxrwxrwx 1 root root 19 27. Jan 13:01 cert.pem -> cert-1453896049.pem
4 -rw------- 1 root root 1676 23. Mär 23:48 chain-1453896049.pem
0 lrwxrwxrwx 1 root root 20 27. Jan 13:01 chain.pem -> chain-1453896049.pem
4 -rw------- 1 root root 3956 27. Jan 13:01 fullchain-1453896049.pem
0 lrwxrwxrwx 1 root root 24 27. Jan 13:01 fullchain.pem -> fullchain-1453896049.pem
4 -rw------- 1 root root 3242 23. Mär 23:48 privkey-1453896049.pem
0 lrwxrwxrwx 1 root root 22 27. Jan 13:01 privkey.pem -> privkey-1453896049.pem
This seems to be a serverside issue. Just delete the domain from your (job)database and it should work again.
If i’m not mistaken, LE had a dns issue around the 13th of april ?
Suggestion:
Tell the webapp to show the links it complains about.
The relevant bit of output is this one:
That "pending" JSON output is temporary (while the client is polling the server to see if the challenge succeeded/failed). In the end, its status is "invalid": https://acme-v01.api.letsencrypt.org/acme/challenge/7ftGAV2gxxWnohIAl_Aq60JWZOSNhuR_4rQH5bRpUEA/74809467
If you take a look at that link, you'll notice the following bit:
hostname":"heimatverein-gloinetal-magdeburgerforth.de.well-known"
It looks like something is causing the domain to be changed to heimatverein-gloinetal-magdeburgerforth.de.well-known. Could this be a typo somewhere in your configuration? I'm not familiar with this client, so I'm not exactly sure where you'd have to look. It might also be a client bug - I'll try to see if I can find anything if your configuration looks fine.
PS: I've increased your link limit (the forum software limits new users to 2 links per post in order to prevent spam).
Correction:
The error seems to be due to a buggy redirect (notice the Location URL):
curl -i http://webmail.heimatverein-gloinetal-magdeburgerforth.de/.well-known/acme-challenge/bDZxoGLIuz28jHDH0Ga5nDQ-erAKfXdUW9WWKeWLSd8
HTTP/1.1 301 Moved Permanently
Date: Fri, 06 May 2016 10:50:31 GMT
Server: Apache/2.4.18 (Fedora) OpenSSL/1.0.1k-fips
Location: https://heimatverein-gloinetal-magdeburgerforth.de.well-known/acme-challenge/bDZxoGLIuz28jHDH0Ga5nDQ-erAKfXdUW9WWKeWLSd8
interessting… as this domain has already a LE cert, and the policy says, that if you got a cert from le,
we accept only https:// urls , I don’t know, why the check for this renew uses still http:// .
Shouldn’t that be https:// from your side for any renew or gives the “client” the .well-known url to verify ?
What policy says this? The http-01 validation always connects to http://yourhostname/.well-known/acme-challenge, though you can of course redirect it to https (or indeed to a completely different server) if desired.
The CA server connects to your site and requests a specific file (in your case, /.well-known/acme-challenge/bDZxoGLIuz28jHDH0Ga5nDQ-erAKfXdUW9WWKeWLSd8) in order to demonstrate domain ownership.
Your client is responsible for putting that file in the correct directory and make sure that the web server serves that file.
Your web server responds with a redirect to a HTTPS site, which Let’s Encrypt is happy to follow. However, that URL is malformed - there’s a missing / at the end of your domain, so the domain looks like heimatverein-gloinetal-magdeburgerforth.de.well-known (which obviously won’t work).
so Lukas has to add a new option to use a different kind of request for renews.
And as the other domains have auto https redirecting disabled, they get renewed because the http:// request is answere without a redirect.
Ok, that was helpful. Thank you.
the only thing i don’t get is: Why does it say pending ? It’s not pending, it’s just wrong.
No, the client works fine here. The problem is in the redirect URL. You’re not redirecting to a valid URL. You’ll need to rewrite your redirection logic.