acme-companion: Still issues with auto-renew - 503?
Hi,
I fixed my previous issues with renewal, however I am still having issues. I have all of my addresses on the one SAN certificate (great feature). Creating the cert was no problem, however the renewal doesn’t seem to work. Checking the logs it seems that the validation (via the .well-known/acme-challenge thing) doesn’t work.
The debug logs show:
2016-04-25 06:18:39,767:DEBUG:acme.challenges:263: Verifying http-01 at http://couch.nine-hells.net/.well-known/acme-challenge/zk0acTDR1rJ4seBosynJA5niKsJU0nKqD_STKwBtkD0…
2016-04-25 06:18:39,768:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): couch.nine-hells.net
2016-04-25 06:18:39,922:DEBUG:requests.packages.urllib3.connectionpool:387: “GET /.well-known/acme-challenge/zk0acTDR1rJ4seBosynJA5niKsJU0nKqD_STKwBtkD0 HTTP/1.1” 503 213
2016-04-25 06:18:39,922:DEBUG:acme.challenges:270: Received <Response [503]>: <html>
<head><title>503 Service Temporarily Unavailable</title></head> <body bgcolor="white"> <center>503 Service Temporarily Unavailable
</center>
<center>nginx/1.9.14</center> </body> </html> . Headers: {'Date': 'Mon, 25 Apr 2016 06:18:39 GMT', 'Content-Length': '213', 'Content-Type': 'text/html', 'Connection': 'keep-alive', 'Server': 'nginx/1.9.14'}2016-04-25 06:18:39,922:DEBUG:acme.challenges:276: Key authorization from response (u’zk0acTDR1rJ4seBosynJA5niKsJU0nKqD_STKwBtkD0.yCerLuhuTaQrEdvYLhNIzp_RW3EKJ1A8FXwQUyl8oqw’) doesn’t match HTTP response (u’<html>\r\n<head><title>503 Service Temporarily Unavailable</title></head>\r\n<body bgcolor="white">\r\n<center>
503 Service Temporarily Unavailable
</center>\r\n
<center>nginx/1.9.14</center>\r\n</body>\r\n</html>')2016-04-25 06:18:39,923:WARNING:simp_le:1292: couch.nine-hells.net was not successfully self-verified. CA is likely to fail as well!
And the access log for the nginx container shows:
couch.nine-hells.net 60.240.175.196 - - [25/Apr/2016:06:18:39 +0000] "GET /.well-known/acme-challenge/zk0acTDR1rJ4seBosynJA5niKsJU0nKqD_STKwBtkD0 HTTP/1.1" 503 213 "-" "python-requests/2.8.1" couch.nine-hells.net 66.133.109.36 - - [25/Apr/2016:06:18:40 +0000] "GET /.well-known/acme-challenge/zk0acTDR1rJ4seBosynJA5niKsJU0nKqD_STKwBtkD0 HTTP/1.1" 503 213 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
However, I just stopped the companion container, deleted all the old cert data and restarted the companion. New certificate is generated without any issues (none of the other containers were stopped, started or otherwise touched) and the nginx access logs show:
couch.nine-hells.net 60.240.175.196 - - [25/Apr/2016:06:22:20 +0000] "GET /.well-known/acme-challenge/XihsBP2JxaZHA0j_n8Jl4S_EiEH2k8mCETC0dQ09v6U HTTP/1.1" 200 87 "-" "python-requests/2.8.1" couch.nine-hells.net 66.133.109.36 - - [25/Apr/2016:06:22:21 +0000] "GET /.well-known/acme-challenge/XihsBP2JxaZHA0j_n8Jl4S_EiEH2k8mCETC0dQ09v6U HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
It doesn’t make sense? Surely they use the same verification method? Why would creation work without any issues, but the same setup fails to verify for renewal? What is different about the two scenarios?
I can schedule a script to stop the app, delete the certs and restart the app every coulple of months to workaround this - but I would obviously rather have this working as intended.
Any ideas?
Mike
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 24
Okay… An update. There is a known issue for the docker-gen container, whereby the newest nginx.tmpl file causes the “no server line in upstream stanza” issue I referred to above. There is a workaround, however.
When you run the docker-gen container, expose some arbitrary port (doesn’t have to be published) and then the nginx default.conf will be generated correctly.
So it’s now “all good”, provided that the LE renewal process accepts starting a HTTP connection and being 301’d up to HTTPS.
(Sorry for all the posts today!)