Renew hangs while Creating CSR


#1

I’m trying to renew my certificate which is expiring soon. I was a beta tester, and has previously renewed about 3-4 times. This is the first time it hangs. I’m running on Ubuntu 15.04 with apache 2.4.

I got the latest certbot, but the letsencrypt git hub also hangs. Output:

$ ./certbot-auto renew --dry-run
Requesting root privileges to run certbot…
/home/xxxxxxx/.local/share/letsencrypt/bin/letsencrypt renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/xxxxxxxxxxxx.conf

Cert is due for renewal, auto-renewing…
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for xxxxxxxxxxxxxxxxx
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0043_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0043_csr-certbot.pem

The last log entry is at this point:
2016-10-08 15:00:12,249:DEBUG:root:Sending POST request to https://acme-staging.api.letsencrypt.org/acme/new-cert. args: (), kwargs: {‘headers’: {‘Accept’: ‘application/pkix-cert’}, ‘data’: '{“header”: …

Any ideas why it would hang on that stage?


#2

Could you post the full log?

There’s an issue on systems with broken IPv6 connectivity. If you’re affected by this, you would typically have log entries that are 4-5 minutes apart (that’s the timeout the client uses - the request switches over to IPv4 afterwards).

Here’s a similar thread with a log like the one I described, and some steps to troubleshoot this:


#3

Thank you, really appreciate it!

My ipv6 is already disabled:
$ ping6 acme-v01.api.letsencrypt.org
connect: Network is unreachable

I’m trying to run something like this (although I’ve tried all sorts of variations, e.g. renew --dry-run, etc.)
$ ./letsencrypt-auto --apache -d …

Logs are:
2016-10-08 21:28:49,387:DEBUG:certbot.reverter:Creating backup of /etc/apache2/apache2.conf
2016-10-08 21:28:52,553:INFO:certbot.auth_handler:Waiting for verification…
2016-10-08 21:28:52,570:DEBUG:acme.client:Serialized JSON: {“keyAuthorization”: "aTkNsb7OKIRlNhwIOE5ATJS7ke8jzA8Oh0s9L-O
2016-10-08 21:28:52,571:DEBUG:acme.jose.json_util:Omitted empty fields: x5c=(), crit=(), typ=None, jwk=None, x5u=None, k
2016-10-08 21:28:52,583:DEBUG:acme.jose.json_util:Omitted empty fields: x5c=(), crit=(), nonce=None, typ=None, x5u=None,
2016-10-08 21:28:52,584:DEBUG:root:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/challenge/s47X-6x4g
2016-10-08 21:28:52,870:DEBUG:requests.packages.urllib3.connectionpool:“POST /acme/challenge/s47X-6x4gqKGAOUhqwBdzCFWjxA
2016-10-08 21:28:52,872:DEBUG:root:Received <Response [202]>. Headers: {‘Content-Length’: ‘225’, ‘Boulder-Request-Id’: '
2016-10-08 21:28:52,873:DEBUG:acme.client:Storing nonce: '\x8e\x1c\x0c\x1e\xfe\x9a\xc1\xf3\xdb\xe2\x19\x13\xe5\x95\xa0\x
2016-10-08 21:28:52,873:DEBUG:acme.client:Received response <Response [202]> (headers: {‘Content-Length’: ‘225’, ‘Boulde
2016-10-08 21:28:55,877:DEBUG:root:Sending GET request to https://acme-v01.api.letsencrypt.org/acme/authz/s47X-6x4gqKGAO
2016-10-08 21:28:56,165:DEBUG:requests.packages.urllib3.connectionpool:"GET /acme/authz/s47X-6x4gqKGAOUhqwBdzCFWjxAq3-5t
2016-10-08 21:28:56,166:DEBUG:root:Received <Response [200]>. Headers: {‘Content-Length’: ‘1454’, ‘Expires’: ‘Sat, 08 Oc
2016-10-08 21:28:56,167:DEBUG:acme.client:Received response <Response [200]> (headers: {‘Content-Length’: ‘1454’, ‘Expir
2016-10-08 21:28:56,169:INFO:certbot.auth_handler:Cleaning up challenges
2016-10-08 21:28:56,876:INFO:certbot.crypto_util:Generating key (2048 bits): /etc/letsencrypt/keys/0047_key-certbot.pem
2016-10-08 21:28:56,900:INFO:certbot.crypto_util:Creating CSR: /etc/letsencrypt/csr/0047_csr-certbot.pem
2016-10-08 21:28:56,910:DEBUG:certbot.client:CSR: CSR(file=’/etc/letsencrypt/csr/0047_csr-certbot.pem’, data=‘0\x82\x02
2016-10-08 21:28:56,911:DEBUG:acme.client:Requesting issuance…
2016-10-08 21:28:56,911:DEBUG:acme.client:Serialized JSON: {“resource”: “new-cert”, “csr”: “MIICjDCCAXQCAQIwGjEYMBYGA1UE
2016-10-08 21:28:56,913:DEBUG:acme.jose.json_util:Omitted empty fields: x5c=(), crit=(), typ=None, jwk=None, x5u=None, k
2016-10-08 21:28:56,925:DEBUG:acme.jose.json_util:Omitted empty fields: x5c=(), crit=(), nonce=None, typ=None, x5u=None,
2016-10-08 21:28:56,926:DEBUG:root:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/new-cert. args: (),
2016-10-08 21:33:56,444:DEBUG:certbot.main:Exiting abnormally:
Traceback (most recent call last):
File “/home/xxxxx/.local/share/letsencrypt/bin/letsencrypt”, line 11, in
sys.exit(main())
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py”, line 776, in main
return config.func(config, plugins)
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py”, line 511, in run
action, lineage = _auth_from_domains(le_client, config, domains)
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py”, line 96, in _auth_fro
renewal.renew_cert(config, domains, le_client, lineage)
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/renewal.py”, line 238, in renew
new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains)
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/client.py”, line 263, in obtain
return (self.obtain_certificate_from_csr(domains, csr, authzr=authzr)
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/client.py”, line 234, in obtain
authzr)
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/acme/client.py”, line 312, in request_i
headers={‘Accept’: content_type})
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/acme/client.py”, line 647, in post
response = self._send_request(‘POST’, url, data=data, **kwargs)
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/acme/client.py”, line 606, in _send_req
response = self.session.request(method, url, *args, **kwargs)
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/requests/sessions.py”, line 468, in req
resp = self.send(prep, **send_kwargs)
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/requests/sessions.py”, line 576, in sen
r = adapter.send(request, **kwargs)
File “/home/xxxxx/.local/share/letsencrypt/local/lib/python2.7/site-packages/requests/adapters.py”, line 426, in sen
raise ConnectionError(err, request=request)
ConnectionError: (‘Connection aborted.’, BadStatusLine(”’’”,))


#4

Huh, that’s odd. The other requests are succeeding, so it doesn’t look like it’s a general connectivity issue.

Would you mind sharing your /etc/letsencrypt/csr/0047_csr-certbot.pem file? I’m curious if the error can be reproduced with the same CSR.


#5

Sure, here’s a couple of request files, I’ve got a few of them hanging around :slight_smile:

-----BEGIN CERTIFICATE REQUEST-----
MIICjDCCAXQCAQIwGjEYMBYGA1UEAwwPdGVzdC5hdG9wb24uY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyqG18J/6ZRkTUePrcumMWWZkr444ikuu
OxWQaGEkBHKHgkJ3XPdXZkg9usZ1HkTv6qYB62idtVPQYsODVPioYrw9nPETdCny
GyfyorTVn6XSHrBvsiRsC1FHEu/cTkUs9d0CHsu28H0MWULqqEmHCyVPY9vamxGJ
sknt7Qfg7Shdi1M1FRuIgjcRMerkBzQUIu57R9AcG/mZEZE94ddY9CcfS+k+6x/d
rtojnNPd/4vOE6um1dp0l5G1P18gYViLlmKDfeJ3zj/0IUU0H3YlQPJ5XbrhiO2l
PeAkhrTaaETxsTula4Uz6Pi7wNbN8umLDuN48FOg6ERHoto1MWPl/wIDAQABoC0w
KwYJKoZIhvcNAQkOMR4wHDAaBgNVHREEEzARgg90ZXN0LmF0b3Bvbi5jb20wDQYJ
KoZIhvcNAQELBQADggEBACR3seG8j6p74AGKWyGqtgo8WG8BX8LG3gvbkhQG6F5i
i9kDuJ3pR058qSnQv00PVDYE67w4mcv7z2Ig+QH/mpkqxCF6UTBDgvn/egy5fpQS
iDyEnIiU8WrN9cUZXSmtGW/FFri8m6c+hNqwzfJHeRoVwc6mJzR6H4SezB0w4qZk
oYb2aAWlz6jGY04zHFb6VsCM8YVJL1SPwvHnNGKkF7HU8VIcI5Av2a6yK4wo+YjU
5IgWgWyfe0/u85RILGq1qIkzd/hXoWVjz/76DNh0vWVuPQDUK6IPOVIQbVCzfyCp
2OXS3TEbO+BTGqt5MH/PBVp/Ly1Uw1QzuniW71NZM0g=
-----END CERTIFICATE REQUEST-----

-----BEGIN CERTIFICATE REQUEST-----
MIICjDCCAXQCAQIwGjEYMBYGA1UEAwwPdGVzdC5hdG9wb24uY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy8Tb2zVcZnBQt6rQKXC7k2AV8qPYMzEp
qqnlh7qKQ+/u4ewB/PFGNL9DraXh922Y9NUHwK73YLhKHPdTwQcI2GbdUHkt60/F
sltUswJ7oqMD6xbcJoP1HtXTuCrpXs2whVeZm0fBUopnqRd3oD18010/uv06824X
V1Ld63LxjIrrVUOeheVI1cAu5h+fLjhyc0Nr7U87b6Iaf8FD5udGgk4XGTdDPZgk
QU6pY++mot5J+MuZOj8twLgvoMGT8ZoTi9ytFu2riQkx0e1WXsF8R+Col00vg2Jx
EqECKE6u1SNjq0mDuZxrSkw0mfeTdhjCErxKCn5Bgk1fSiEzq4zd6QIDAQABoC0w
KwYJKoZIhvcNAQkOMR4wHDAaBgNVHREEEzARgg90ZXN0LmF0b3Bvbi5jb20wDQYJ
KoZIhvcNAQELBQADggEBADC8YdlNbaVB6j9pQ9yPY00G7oZb/mrk+fL7QfEIhm9S
l2ZKEHMJfgbhzEffIrHNatELnTBYmZkyisOyRW7PQM8qdDqSIqEe6WTvFEybOF6K
bJ4k/ByqsJXJpnfc4NCOf1Yfc6lkh1KqcmpkwRXqpA5lDn8mktBiYQ7ft31B6c8J
+/Vgru56SJGabDfxZGa8udkd+CWwsP9Ae8Rx/qq8n1zovohHuRpYbzfWj1iZIlN2
5a/UoUNDZIoXderrC4d+/a4BhMgBEXKMEL+1949rbcnWTWA9G2Nz8zXHQ2FezMWP
gkUnUFtQgsiMauDXcH6jw82Yk3U5fqiWp9NDGBed3eE=
-----END CERTIFICATE REQUEST-----


#6

One other question, if I were to delete my previous letsencrypt history and start afresh, what’s the best way to do that? Thanks!


#7

Thanks! I’ll try to get some testing done with your CSRs later today.

All configuration, certificate and key files are stored in /etc/letsencrypt, so getting rid of that directory would give you a clean start.


#8

I successfully obtained a certificate using the first CSR while testing against a local copy of the CA software behind Let’s Encrypt, so it doesn’t look like it’s the CSR that’s triggering some bug.

@cpu Any ideas on what could cause those new-cert requests to fail, while the rest seems to be working?


#9

@pfg Hmmm. This is a strange one.

@ksymeon It looks like the log snippit you shared is cut off. In particular it would be helpful if I could see the Boulder-Request-Id value in some of the server responses. Can you share the log again using pastebin or surrounded in backticks?

One odd I thing I noticed from the staging logs is that the client is sending GET requests to /acme/new-cert and getting back a ["405 :: urn:acme:error:malformed :: Method not allowed"] response (which makes sense, this is a POST endpoint). I don’t know what would be causing that, especially since the log snippit shared does seem to say “Sending POST request to https://acme-v01.api.letsencrypt.org/acme/new-cert

@bmw - do you have any thoughts on this one?


#10

Not sure if it’s relevant here but I have seen dumb “transparent” proxies re-write a POST as a GET and then let the client eat the resulting error. I work for a large corporation and their famous-brand HTTPS MITM proxy will occasionally interrupt a POST to try to do HTTP authentication of the user (to determine if they should be allowed to reach certain sites) and then get muddled and re-commence the operation as a GET, which fails.

I have seen some very confused remote servers from this behaviour. I gave up moaning about the MITM proxy once it was fixed to merely be inconvenient and encourage bad behaviours, rather than being directly and unavoidably insecure due to failure to read the vendor’s manual properly.


#11

That’s an interesting theory @tialaramex - thanks for sharing! The logs also show some of the same sort of 405 errors being returned when the client sends a HEAD request to an endpoint that doesn’t support the operation (e.g. new-reg). Sending HEADs before the normal ACME requests may be another indicator there is a caching proxy or something mucking with things.

@ksymeon Are you aware of any proxy or network middleware between the machine running Certbot and the Let’s Encrypt servers?


#12

This is a “home” setup, but basically the server is plugged in to a Gigabit switch, which then goes off to my router and a DSL modem in bridge mode. The ah-ha moment here is that very recently due to a lightning strike my previous modem died and this is a replacement. Before the event I have successfully renewed 2-3 times. Hmmm.

FWIW, I tried removing /etc/letsencrypt and my SSL sites-enabled entry and the same thing happened. I’m going to relocate my web-sites to a brand new server that I set up and try with that one. It’s on the same LAN.

If the new server fails too, then it must be the new network middleware. :frowning:


#13

Here’s an excerpt of my latest attempt around the 405:

2016-10-13 21:19:15,679:INFO:certbot.main:Renewing an existing certificate
2016-10-13 21:19:15,680:DEBUG:root:Requesting fresh nonce
2016-10-13 21:19:15,680:DEBUG:root:Sending HEAD request to https://acme-staging.api.letsencrypt.org/acme/new-authz. args: (), kwargs: {}
2016-10-13 21:19:15,898:DEBUG:requests.packages.urllib3.connectionpool:"HEAD /acme/new-authz HTTP/1.1" 405 0
2016-10-13 21:19:15,899:DEBUG:root:Received <Response [405]>. Headers: {'Content-Length': '91', 'Pragma': 'no-cache', 'Boulder-Request-Id': 'SVUEW8IIr_bxW0_HemAb0QZcEsks7mphfK15lkRkZpY', 'Expires': 'Thu, 13 Oct 2016 21:19:15 GMT', 'Server': 'nginx', 'Connection': 'keep-alive', 'Allow': 'POST', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Thu, 13 Oct 2016 21:19:15 GMT', 'Content-Type': 'application/problem+json', 'Replay-Nonce': 'UMFxx95QJH0VZDjta5UvbXC2YeOqrwwPj_S4P8_soxY'}. Content: ''
2016-10-13 21:19:15,900:DEBUG:acme.client:Storing nonce: 'P\xc1q\xc7\xdeP$}\x15d8\xedk\x95/mp\xb6a\xe3\xaa\xaf\x0c\x0f\x8f\xf4\xb8?\xcf\xec\xa3\x16'
2016-10-13 21:19:15,902:DEBUG:acme.jose.json_util:Omitted empty fields: expires=None, challenges=None, status=None, combinations=None
2016-10-13 21:19:15,902:DEBUG:acme.client:Serialized JSON: {"identifier": {"type": "dns", "value": "test.atopon.com"}, "resource": "new-authz"}
2016-10-13 21:19:15,908:DEBUG:acme.jose.json_util:Omitted empty fields: x5c=(), crit=(), typ=None, jwk=None, x5u=None, kid=None, alg=None, cty=None, x5tS256=None, jku=None, x5t=None
2016-10-13 21:19:15,917:DEBUG:acme.jose.json_util:Omitted empty fields: x5c=(), crit=(), nonce=None, typ=None, x5u=None, kid=None, cty=None, x5tS256=None, jku=None, x5t=None

#14

An update. I tried to create a certificate in manual mode, from a VM that I was testing the beta more than a year ago. I tried twice. The first time I got a 500, the next time I got a “Certificate issuance limit reached”.

The first time I’d forgotten to remove my /etc/letsencrypt/ dir so I’m sure that the old credentials there just blew the whole thing up, I’m not surprised by the 500. The second time though, at least this failure is somewhat helpful. The VM runs inside my desktop which is connected straight to the router. My proper server connects to the router via a Netgear ProSafe switch, h/w wise that’s the only diff.

I can’t tell what the rate limit is, can I? And it seems that all my failed attempts count against that issuance limit?

Logs from the last 2 manual attempts:

2016-10-13 21:46:54,030:DEBUG:root:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/new-cert. args: (), kwargs: {'headers': {'Accept': 'application/pkix-cert'}, 'data': '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "yBmbhkNZ_u0nctKc6L4XcpEZ36V8v2nRTH6YrFz9l1rHpvZOI5774uNRPZ4ZPIXNcIAzeqjEiyGZ90VPAsQVQLitur8CiCXXfumeeWdkMqyKUlzHEIt1GJZMQ0i2HkLTPzxKLGQOqPgCE0aR3KKpEOCOLdM2C5u_Zv_G2QEsMEd9d9kNdfZPzfKNSutMvgFvvaRWW-rbj37J9skuWte7_349Rk2O35C6XvznSiXlfx4AytvHkiRL_egoxsDtqJQKgcliwryove_SnIbs85t9lBLphsg2Hv3VcGAFJgL3xo2b70Z_Loed6LUOYWqxFgKnWwLNYzo3nfhPXc1M_j-gOQ"}}, "protected": "eyJub25jZSI6ICJYc0REcnFQSllTTElyc3EtTVMzNFlDS21reFV3ZUdrTzN6blE4UWlVSGd3In0", "payload": "eyJyZXNvdXJjZSI6ICJuZXctY2VydCIsICJjc3IiOiAiTUlJQ2pEQ0NBWFFDQVFJd0dqRVlNQllHQTFVRUF3d1BkR1Z6ZEM1aGRHOXdiMjR1WTI5dE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBcGNEdG8xX25OeEdfTWhydUpsSGVhRUJMTEJWdWxQQXB1YTh0MnpRUUx5QjRxN3Q5X1JrZXRmeUJFMVdUelNjeWktcGFXMEZvbXZpV3ZwSTdFTjNYNUtQaGo1VWMtUEFBeWM3NmhmQzlXRnJ2U2I0MmRCOE1EZk5kV0piWUItQmhyV2ZCTXQ1SG9oamZLaUlWMFlTQ3RRWDdUY1lCNFBIaTJ3SVlncmxrS0wwYjAxdkdhUU1aaTc1TjhXMGtwWGdFQURmb1ZjT0xvY1BpbW5lbUp4aUlsUVg0QnQzaUJINlliMWFsQmJ0WDdsUS1vcU9GbjZwcWRXUDlYRzQ1cHVqRUlYVmRIZndUWGRESVNnZlNPX3Y5bU1UTzJfQnVGNGU4em5wQzMtVWFZTThLNnpIbi1JaWpTVmRwU3hXOU8yQXhzTXp2MGNlQXoxb3UxUkxmMFVfNWt3SURBUUFCb0Mwd0t3WUpLb1pJaHZjTkFRa09NUjR3SERBYUJnTlZIUkVFRXpBUmdnOTBaWE4wTG1GMGIzQnZiaTVqYjIwd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFCUHJOUHlKbHZOV0hnQUJxdXpDS2FuMDdYMm1jaUZLbTVnTnh3cGR1WS1fQTVPSW9KaEd4LWlJT1NpSTlfRURteXZGdkxiNGRHYTNTcTZ3VWdrdlF2SXpYbEFvNU0ydFFacVhyRUxrSldUc3VOam80WGhPYU85Q3FNWElOWlBQSFlGT3FzRk5UeFJWaExTZURHeW9acFlvRnBQZjdCdXhMejlXeUdHYVN2ek5mdUpYYll0d0Z5NU1PTWgySHV4SC1keDRGQjBJaFhvQzFKSDlaNGRObjdBMnNqSlRLNU9oQ3o5UFFIWWtnLVBpcDJOOXBhWTFWa1YyVlZtckZJczBCcTI4UXNnRDZtOVAxTWRobmdiTUtfTHhvdHFvRG1hR21HOXhaRVFJYVA5UGpoTENTSVd0MTdYY1h6blJCQ0pBa0dJRExtMWtodzlOTXpsZTZlSmRPWEUifQ", "signature": "KQMHNRNgbvyFX1wnoQSvD0-gYUos0B5ZZzn9FTGXfJCbiPmi9TMs4dZvzwNX-PpVmzD3s2JI-Zb45lvSrImc24OLGuBKBtUQ0xEbzdCKq2nzddrACVUtnvjBXiBiyPwYNr2KDBuA-tQuu3vFTg4dqEREhqfHCqPXM558vHVHOTq2DwCd0Kj_Mt-eYU52Oujq9VvdYnOleWTfp-pbzWrGNkM7OkMd71_x6rR9zqAuN_bloulhhMuBdmhI_kwNmEHDnz0NLxL5NiC0Ujj2zWb1OXnsvhGL6B5JebstO-En9toBrSxm9zuvU8DSHk--H4yhBwpRLgZunka11xU4BP1UTw"}'}
2016-10-13 21:47:00,850:DEBUG:requests.packages.urllib3.connectionpool:"POST /acme/new-cert HTTP/1.1" 500 101
2016-10-13 21:47:00,856:DEBUG:root:Received <Response [500]>. Headers: {'Content-Length': '101', 'Boulder-Request-Id': 'WrNH6XJhvNgVAHJGpdTEhw_eXiLIG8SSgm39DgiYcvE', 'Expires': 'Thu, 13 Oct 2016 21:47:00 GMT', 'Server': 'nginx', 'Connection': 'close', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Pragma': 'no-cache', 'Boulder-Requester': '2982', 'Date': 'Thu, 13 Oct 2016 21:47:00 GMT', 'Content-Type': 'application/problem+json', 'Replay-Nonce': 'e_FkehKKbLPOlzmMJ8guBzrakRnzvJKsrhFyyRBgJ1s'}. Content: '{\n  "type": "urn:acme:error:serverInternal",\n  "detail": "Error creating new cert",\n  "status": 500\n}'
2016-10-13 21:47:00,858:DEBUG:acme.client:Storing nonce: "{\xf1dz\x12\x8al\xb3\xce\x979\x8c'\xc8.\x07:\xda\x91\x19\xf3\xbc\x92\xac\xae\x11r\xc9\x10`'["
2016-10-13 21:51:36,598:DEBUG:root:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/new-cert. args: (), kwargs: {'headers': {'Accept': 'application/pkix-cert'}, 'data': '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "yxWypbA_u66-ehD_B8INcqgV3Iodyn5b_8Be164NomD0KpY0NoeYuRI-IXYdxvuzYZS1fineFN8EXIO-RjYLKla-WJYhG9YwoxBX3DKstzINDhpV512e7_zi3Vd7R_7IoIIG_SmF8uqKjK4XPh_SYFcQK_VLPdJYyBxd19jKVEQXwJEILXQsvW7S6eV_q77Ht80iAmuz6f5YCzF3W9rRg53sjwXWrk6TJY6Fg4nSjlHeB6sGZtZQC8-NVlYop798yOr_a1uaBAfTBBmDP1Z-_Qd9LzLiNWeApMU-mBqQvkRIM_eJ-0iXOKuKsYSI6Kh5CVdL1bkboXmj8vg1qeGZOQ"}}, "protected": "eyJub25jZSI6ICIzRHZwclJ3WHA3OGpfcEJmdXpkemh2UkNtOWxKVTRvNVRKdkN6MmxDRVdNIn0", "payload": "eyJyZXNvdXJjZSI6ICJuZXctY2VydCIsICJjc3IiOiAiTUlJQ2pEQ0NBWFFDQVFJd0dqRVlNQllHQTFVRUF3d1BkR1Z6ZEM1aGRHOXdiMjR1WTI5dE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBeGNTX2luLXdsb3g2RGxXSXVIVFY4bDRKSjZhcUFuVTU3dnNfMndETzR2ZDZMSVhGNi1Pa0ZpZkhxM0szRUF0ZmEzRUc0QXY4Y1N3d19pVWJRMGp4Z2hhYmd5WEU1LW5lUm81d0JrT3FsRmFESEFMZTJCcm5PRkVOMVpET0NLQjRzRW5OVjI4aE53Z1lXV1hWeFJvWkxkOWlKS3NtaXFJZDNFVTZjUWVEMDIzc2RGMDNQb0hhT1JPNFpNc29ONTM4eG5FeEJVQlo5V3h0WEVWNUVHbzRNSENIa2laU202VnJ2WTRneFJoemlJcmhPd3Jpcm1BVW1lRVl3dzZXRWpzQ0diTXdqVU1qUFFCanlHa1YzQnB5LTMyQkRvYkx3YUlpVDVrY21Tako4MnNiOTBlZDB3a3R6V1MyTEc2dTczZmF0Tlc3Y1dYclVQelM5SDVENmRlTG9RSURBUUFCb0Mwd0t3WUpLb1pJaHZjTkFRa09NUjR3SERBYUJnTlZIUkVFRXpBUmdnOTBaWE4wTG1GMGIzQnZiaTVqYjIwd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFMcHJFdkFLOExGa21fdTJYcXNRaXJtNEw3eVVGZ2wyYlE1LUF4dkx0N08wQ3ZFUjNXOWJZaXBsMGd3bmNkTHhxSkUyWjBHMWs0SlhxUGJHVFlRLWZPRTM4SjZYeWxaNFFtandPU2VfUHl2dW4tWGN1NnhobzQxT0tYcHAzZVk1SnpEX19VOGhiSFBtd1RiRnVkOGI2Tm0wU3dyY0NYUVVUUy1BaTRVSEJBU29HeXlIeEFXbVM5di0tdGQ5SEdJZVhsam9fMDM5clJ3QV9BOUt6d3JQT1BERVZuVldSbzJrMHdsbXhaUDlLVFd0UUxEUGYybmFkdEdrUzNJWWN4bktJVVVJdEZOU2x6N3VDcExOVDFlamlSSWFnY3h1ZjhGWTJEZGlBcG1nVXRaRW5TUi04LUdVS0t2VWdzdWZkaWxZR2ZDdkN0OEtRVzFWLVBZNThnaXE0ODQifQ", "signature": "WXuFBzYchHyzIs7J7bjnXqJ5PpjFgUFa4anLQN4klQsCJg0UFKbVJQ8XAvGcFw0Qf3xyzF_TLHqrFlv4JAnY6v52_OyfpDx8uTsHC19fJznngyYNI7xmVTTou_FTjp6oyVYSM7Bj9e4vpKvN4ll9hbMPBUVhjBbQafHlROmP4lweRQalqWewbvn3q8kZ7Rhau1OietrqTnwoM5TCEwyoIXffSuC9nJk_YEaENMe8zZfpBHKV_0q5GCuHwL7viN2DjSfH2oRmQId5mpvSI2-8X7zB4F6qm1TKSkmhTovth1Bpn7fbOIHgEhagnZ0eZxOlBFGBH5veNIScLArudcpBzg"}'}
2016-10-13 21:51:45,786:DEBUG:requests.packages.urllib3.connectionpool:"POST /acme/new-cert HTTP/1.1" 429 136
2016-10-13 21:51:45,791:DEBUG:root:Received <Response [429]>. Headers: {'Content-Length': '136', 'Boulder-Request-Id': '7Z-inENgHpCtZx1Wz0M3UMbLBCDZ3ZNC27ejUkB7_UE', 'Expires': 'Thu, 13 Oct 2016 21:51:45 GMT', 'Server': 'nginx', 'Connection': 'close', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Pragma': 'no-cache', 'Boulder-Requester': '5168774', 'Date': 'Thu, 13 Oct 2016 21:51:45 GMT', 'Content-Type': 'application/problem+json', 'Replay-Nonce': 'pPC0J-cQmsb2qayyWqg9WieVLAsXDVEHPjXUv0Y0j2g'}. Content: '{\n  "type": "urn:acme:error:rateLimited",\n  "detail": "Error creating new cert :: Certificate issuance limit reached",\n  "status": 429\n}'
2016-10-13 21:51:45,793:DEBUG:acme.client:Storing nonce: "\xa4\xf0\xb4'\xe7\x10\x9a\xc6\xf6\xa9\xac\xb2Z\xa8=Z'\x95,\x0b\x17\rQ\x07>5\xd4\xbfF4\x8fh"

#15

All the limits are listed here: https://letsencrypt.org/docs/rate-limits/

The two limits you’re most likely to be affected by are “Certificates per Registered Domain” and “Duplicate Certificate”

In both cases a certificate was successfully signed, but of course just because Let’s Encrypt signed it doesn’t mean your software successfully downloaded, saved and used it. You may want to check a CT log monitor, such as https://crt.sh/ to see if there are in fact certificates for the names you requested, issued by Let’s Encrypt, or not

Of course it’s possible there’s a bug somewhere in Boulder (the Let’s Encrypt CA software) causing it to track your failed attempts as if they were successful, but it’s more likely the problem is at your end.


#16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.