ReadTimeout: HTTPSConnectionPool(host='', port=443): Read timed out. (read timeout=45)

We getting the below error message while creating a certificate. This is occurring regularly. We are unable to provide certificates to customers. please look into it ASAP

root@84d448e12737:/# certbot certonly -n -d -d san1-d1.xxxxxx, --apache --agree-tos -m --noninteractive --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
http-01 challenge for
Enabled Apache rewrite module
Waiting for verification...
Cleaning up challenges
An unexpected error occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/", line 421, in _make_request
six.raise_from(e, None)
File "", line 3, in raise_from
File "/usr/lib/python3/dist-packages/urllib3/", line 416, in _make_request
httplib_response = conn.getresponse()
File "/usr/lib/python3.8/http/", line 1347, in getresponse
File "/usr/lib/python3.8/http/", line 307, in begin
version, status, reason = self._read_status()
File "/usr/lib/python3.8/http/", line 268, in _read_status
line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
File "/usr/lib/python3.8/", line 669, in readinto
return self._sock.recv_into(b)
File "/usr/lib/python3/dist-packages/urllib3/contrib/", line 326, in recv_into
raise timeout("The read operation timed out")
socket.timeout: The read operation timed out
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/requests/", line 439, in send
resp = conn.urlopen(
File "/usr/lib/python3/dist-packages/urllib3/", line 719, in urlopen
retries = retries.increment(
File "/usr/lib/python3/dist-packages/urllib3/util/", line 400, in increment
raise six.reraise(type(error), error, _stacktrace)
File "/usr/lib/python3/dist-packages/", line 703, in reraise
raise value
File "/usr/lib/python3/dist-packages/urllib3/", line 665, in urlopen
httplib_response = self._make_request(
File "/usr/lib/python3/dist-packages/urllib3/", line 423, in _make_request
self._raise_timeout(err=e, url=url, timeout_value=read_timeout)
File "/usr/lib/python3/dist-packages/urllib3/", line 330, in _raise_timeout
raise ReadTimeoutError(
urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='', port=443): Read timed out. (read timeout=45)
During handling of the above exception, another exception occurred:
requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='', port=443): Read timed out. (read timeout=45)
Please see the logfiles in /var/log/letsencrypt for more details.
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.


Hello :slightly_smiling_face:

We've been seeing these errors somewhat frequently lately. Some have suggested that they can be related to a nameserver problem. I'm going to ask someone for their specific input though because I want a definitive answer.


I elevated this to the LE staff once I had confirmed it was an LE server issue and nothing specifically certbot. This topic says it all.


Sorry for pinging you all, but it has now reached outbreak level. Here are several other recent occurrences.

2 Likes is not showing any maintainance in any case.

I'm getting timeouts too :slight_smile:


That confirms it then. It's not just some random nameserver issue. :confused:


It's very flaky, it's working now again. 7200 IN CNAME 300 IN     CNAME

I didn't realise the Let's Encrypt servers are behind CloudFlare? I thought LE was using a different CDN.

Perhaps not the best choice of action :grin:


That's... interesting. :face_with_monocle:


we noticed the timeouts as well, starting this past friday, but they disappeared by friday night. reappeared this morning, though


Let's Encrypt is aware of this issue and has started investigating. We opened a status page incident and will update when possible. The errors are intermittent and we still see lots of successful requests.


Isn't v2 staging the most affected? I see v1 and v2 production and v1 staging marked as degraded, but not v2 staging.



Thanks for catching that- looks like a simple forgotten checkbox when quickly making the status. The affected components on the status page is updated to include Staging V2.


Still showing the same down lower.

Back in business with a watchful eye. :eye:


Thanks for your patience. The Let's Encrypt team has implemented a fix and is monitoring. The status page reflects this current state.


Well done, staff! :clap: :clap: :clap:

Again, sorry for pinging you guys on a Sunday. Given that it was the staging environment that was flaking, I really didn't think this would get attention until tomorrow. Regardless, my hat's off to you! :tophat:


Ooo! A testimonial! :smiley:

1 Like

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