This isn’t a very good answer, but the most likely explanations are:
-
The CA was slow, didn’t perform the validations quickly, and Certbot gave up waiting, or
-
Something weird went wrong.
Does it work if you try again?
Just tried it for a fifth time today, same result.
Do you have any insight as to what might be going on here?
I don’t have any, sorry.
I’m able to successfully issue certificates using the staging environment.
For that matter, I issued a couple certificates in the production environment a few hours ago.
Does the production environment also have problems for you?
This is a production web server. Or do you mean I should try the renew without the --dry-run?
At what stage in the process is Cerbot choking? It’s not clear to me from the log where things are breaking down.
@mnordhoff means Let’s Encrypt’s production environment.
--dry-run causes Certbot to use acme-staging-v02.api.letsencrypt.org , whereas “production” is acme-v02.api.letsencrypt.org .
What other posters suspect to be happening is not that Certbot is choking, but Let’s Encrypt’s backend service is misbehaving for your ACME orders.
1 Like
Your domain’s DNS seems to be misconfigured right now. It is pointing at some AWS Route53 nameservers, but those Route53 nameservers return REFUSED when queried for your domain.
I would try fixing your nameserver situation first and then seeing what happens with another --dry-run.
There have been some instances in the past where issues like network timeouts were a little racey and caused weird errors to be spit out of Let’s Encrypt/Certbot, but they were masking underlying issues with the domain name or webserver being issued.
So hopefully fixing your DNS should either fix everything, or unmask the underlying problem.
Late Edit: I believe this thread is a report of the same issue.
So I’ll change a domain name to do this test.
I experience a similar problem when running the certbot with the --dry-run option. It worked a few days ago but since yesterday it returns an error
Any idea what this is and how to fix it?
2019-06-20 19:18:40,082:DEBUG:acme.client:Requesting fresh nonce
2019-06-20 19:18:40,083:DEBUG:acme.client:Sending HEAD request to https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce.
2019-06-20 19:18:40,261:DEBUG:urllib3.connectionpool:https://acme-staging-v02.api.letsencrypt.org:443 "HEAD /acme/new-nonce HTTP/1.1" 200 0
2019-06-20 19:18:40,262:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Link: <https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: 5-uH6dpypjIcyp2SAeFWeTCqaw-TY9DevJMtqgRlWVo
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
Content-Length: 0
Expires: Thu, 20 Jun 2019 11:18:40 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Thu, 20 Jun 2019 11:18:40 GMT
Connection: keep-alive
2019-06-20 19:18:40,263:DEBUG:acme.client:Storing nonce: 5-uH6dpypjIcyp2SAeFWeTCqaw-TY9DevJMtqgRlWVo
2019-06-20 19:18:40,264:DEBUG:acme.client:JWS payload:
b'{\n "identifiers": [\n {\n "type": "dns",\n "value": "vserver-vie01.beowulf.at"\n }\n ]\n}'
2019-06-20 19:18:40,270:DEBUG:acme.client:Sending POST request to https://acme-staging-v02.api.letsencrypt.org/acme/new-order:
{
"protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS1zdGFnaW5nLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvYWNjdC85NjIwNDIyIiwgIm5vbmNlIjogIjUtdUg2ZHB5cGpJY3lwMlNBZUZXZVRDcWF3LVRZOURldkpNdHFnUmxXVm8iLCAidXJsIjogImh0dHBzOi8vYWNtZS1zdGFnaW5nLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvbmV3LW9yZGVyIn0",
"signature": "N6bevE4kPTiVGjG-7sx1RujTLm_2OZgPkG8ChHbcJ33BDHGKrs69XxD6c3d_8x0MhBjONjMzbhVmbT0HaH1yF0QnEJbPEtWDdWqwZ-N5hSK7ZGdRzDQ8oAnK4zRDd8G4lriw8wpg59-e2hPzJGOTG7ZHqfTugJIBED5-y7QfwRJMQuD_I7HuhiieWizwY5vTlWaSpJ-RS4lXdTbKjAnyaM4MivDOqtnOHcz_W8WoTUcN9Tk8Y4-pRHoj_UeoWpmlOTzvOuLDW43fKhQfdcGolFqrPx_Z25_ecuWuHndYWcYSgM2OvWiszufVDwakAHUo84mONXZq_MIWMAwzW8Qr6w",
"payload": "ewogICJpZGVudGlmaWVycyI6IFsKICAgIHsKICAgICAgInR5cGUiOiAiZG5zIiwKICAgICAgInZhbHVlIjogInZzZXJ2ZXItdmllMDEuYmVvd3VsZi5hdCIKICAgIH0KICBdCn0"
}
2019-06-20 19:18:40,455:DEBUG:urllib3.connectionpool:https://acme-staging-v02.api.letsencrypt.org:443 "POST /acme/new-order HTTP/1.1" 500 114
2019-06-20 19:18:40,457:DEBUG:acme.client:Received response:
HTTP 500
Server: nginx
Content-Type: application/problem+json
Content-Length: 114
Boulder-Requester: 9620422
Link: <https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: WwiiaEzYVONkIlqY8tSA4eJaELRUczd7FTmUhSPQ39E
Expires: Thu, 20 Jun 2019 11:18:40 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Thu, 20 Jun 2019 11:18:40 GMT
Connection: close
{
"type": "urn:ietf:params:acme:error:serverInternal",
"detail": "Error creating new order",
"status": 500
}
2019-06-20 19:18:40,458:WARNING:certbot.renewal:Attempting to renew cert (vserver-vie01.beowulf.at) from /etc/letsencrypt/renewal/vserver-vie01.beowulf.at.conf produced an unexpected error: urn:ietf:params:acme:error:serverInternal :: The server experienced an internal error :: Error creating new order. Skipping.
2019-06-20 19:18:40,463:DEBUG:certbot.renewal:Traceback was:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 452, in handle_renewal_request
main.renew_cert(lineage_config, plugins, renewal_candidate)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1193, in renew_cert
renewed_lineage = _get_and_save_cert(le_client, config, lineage=lineage)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 116, in _get_and_save_cert
renewal.renew_cert(config, domains, le_client, lineage)
File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 310, in renew_cert
new_cert, new_chain, new_key, _ = le_client.obtain_certificate(domains, new_key)
File "/usr/lib/python3/dist-packages/certbot/client.py", line 353, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
File "/usr/lib/python3/dist-packages/certbot/client.py", line 385, in _get_order_and_authorizations
orderr = self.acme.new_order(csr_pem)
File "/usr/lib/python3/dist-packages/acme/client.py", line 870, in new_order
return self.client.new_order(csr_pem)
File "/usr/lib/python3/dist-packages/acme/client.py", line 652, in new_order
response = self._post(self.directory['newOrder'], order)
File "/usr/lib/python3/dist-packages/acme/client.py", line 95, in _post
return self.net.post(*args, **kwargs)
File "/usr/lib/python3/dist-packages/acme/client.py", line 1185, in post
return self._post_once(*args, **kwargs)
File "/usr/lib/python3/dist-packages/acme/client.py", line 1202, in _post_once
response = self._check_response(response, content_type=content_type)
File "/usr/lib/python3/dist-packages/acme/client.py", line 1054, in _check_response
raise messages.Error.from_json(jobj)
acme.messages.Error: urn:ietf:params:acme:error:serverInternal :: The server experienced an internal error :: Error creating new order
2019-06-20 19:18:40,467:ERROR:certbot.renewal:All renewal attempts failed. The following certs could not be renewed:
2019-06-20 19:18:40,470:ERROR:certbot.renewal: /etc/letsencrypt/live/vserver-vie01.beowulf.at/fullchain.pem (failure)
2019-06-20 19:18:40,472:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File "/usr/bin/certbot", line 11, in <module>
load_entry_point('certbot==0.31.0', 'console_scripts', 'certbot')()
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1365, in main
return config.func(config, plugins)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1272, in renew
renewal.handle_renewal_request(config)
File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 477, in handle_renewal_request
len(renew_failures), len(parse_failures)))
certbot.errors.Error: 1 renew failure(s), 0 parse failure(s)
Hi @beowulf222, welcome to the community forum.
This is fallout from a staging environment disruption the other day. Apologies for the disruption.
I recommend you delete your staging ACME account and recreate it, change the certificate order to add/remove a domain, or wait 7 days from the time you first created this order in staging. Any of the above should resolve your problem.
Hmmm. I just reviewed everything and don't see any DNS issues. It certainly seems to be resolving to the correct IP address. I know for a fact people have been visiting the site.
I just tried again and got a completely different error. WTF?
Attempting to renew cert (barredislands.com) from /etc/letsencrypt/renewal/barredislands.com.conf produced an unexpected error: urn:ietf:params:acme:error:serverInterna l :: The server experienced an internal error :: Error creating new order. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/barredislands.com/fullchain.pem (failure)
ubuntu@ip-172-31-14-63:~$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
I was talking about barredislands.com–but I think I see the issue now. The cert is for that domain name AND barredislands.org, even though I’m really only using the .com. And there was no DNS A record listed for .org–I just added it. For some reason I thought the cert was only for the .com domain name.
ubuntu@ip-177-77-77-77:~$ sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
Certificate Name: barredislands.com
Domains: barredislands.com barredislands.org
Expiry Date: 2019-07-03 17:37:39+00:00 (VALID: 12 days)
Certificate Path: /etc/letsencrypt/live/barredislands.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/barredislands.com/privkey.pem
Failed again, but I may just need to wait a few hours for the DNS to propagate. Will try later tonight.
Thanks a lot for your help. I’ll report back one way or another.
Where did you add the A record?
barredislands.org doesn’t resolve because it’s configured to use a group of Route 53 nameservers that return REFUSED for the domain. You need to check what the correct NS records are at the DNS host and set them at the registrar.
(One or both of them might be Route 53.)
NS and DNS are all at Route 53.
Just out of curiosity, if I wanted to could I tell certbot just to check barredislands.com and ignore .org?
Well, the nameserver settings in the Route 53 Registrar console are incorrect.
You could use something like "sudo certbot --nginx [other options you used when creating the certificate] --cert-name barredislands.com -d barredislands.com".
That would issue a new certificate that includes barredislands.com and does not include barredislands.org and save it on top of the old one.
From what I can see everything looks normal in my Route 53 admin. But I suppose something could be going on under the hood that I’m not aware of. I just created the “hosted zone” for .org and added the A record about an hour ago, so maybe I just need to wait a bit. This cert is good for 13 more days so I’ll give it another shot tomorrow. Thanks again.
Did you update the nameserver settings in the Registrar console?
I just checked that and they didn’t match. My bad–I thought when you have a domain name registered at Rte. 53 and you create a “hosted zone” for that domain name, that Route 53 automatically inserts the correct NS record. But apparently not–at least it didn’t in this case. Lesson learned.
If the AWS support forums are any indication, it’s one of the more common issues people have with Route 53. 
The console needs a bunch of warnings or something.
Glad you pointed that out. AWS can be tricky alright.
I just tried again, no dice, probably need to wait for propagation to happen? Will give it a shot tomorrow.