On Rasbian Jessie, certbot gives urlopen error [Errno 101] Network is unreachable

I’m running Raspbian Jessie on a Raspberry Pi 3 with python version 2.7.9, and new python versions installed also.

I ran this command to renew my certificate:

sudo ./certbot-auto certonly --no-self-upgrade --manual -d mywebsitesname.org

It produced this output:

Creating virtual environment…
Installing Python packages…
Traceback (most recent call last):
File “/tmp/tmp.M8uKRHjCCO/pipstrap.py”, line 181, in
sys.exit(main())
File “/tmp/tmp.M8uKRHjCCO/pipstrap.py”, line 160, in main
for path, digest in PACKAGES]
File “/tmp/tmp.M8uKRHjCCO/pipstrap.py”, line 117, in hashed_download
response = opener(using_https=parsed_url.scheme == ‘https’).open(url)
File “/usr/lib/python2.7/urllib2.py”, line 437, in open
response = meth(req, response)
File “/usr/lib/python2.7/urllib2.py”, line 550, in http_response
‘http’, request, response, code, msg, hdrs)
File “/usr/lib/python2.7/urllib2.py”, line 469, in error
result = self._call_chain(*args)
File “/usr/lib/python2.7/urllib2.py”, line 409, in _call_chain
result = func(*args)
File “/usr/lib/python2.7/urllib2.py”, line 656, in http_error_302
return self.parent.open(new, timeout=req.timeout)
File “/usr/lib/python2.7/urllib2.py”, line 437, in open
response = meth(req, response)
File “/usr/lib/python2.7/urllib2.py”, line 550, in http_response
‘http’, request, response, code, msg, hdrs)
File “/usr/lib/python2.7/urllib2.py”, line 469, in error
result = self._call_chain(*args)
File “/usr/lib/python2.7/urllib2.py”, line 409, in _call_chain
result = func(*args)
File “/usr/lib/python2.7/urllib2.py”, line 656, in http_error_302
return self.parent.open(new, timeout=req.timeout)
File “/usr/lib/python2.7/urllib2.py”, line 431, in open
response = self._open(req, data)
File “/usr/lib/python2.7/urllib2.py”, line 449, in _open
‘_open’, req)
File “/usr/lib/python2.7/urllib2.py”, line 409, in _call_chain
result = func(*args)
File “/usr/lib/python2.7/urllib2.py”, line 1240, in https_open
context=self._context)
File “/usr/lib/python2.7/urllib2.py”, line 1197, in do_open
raise URLError(err)
urllib2.URLError: <urlopen error [Errno 101] Network is unreachable>

My web server is (include version):

Lighttpd version 1.4.35

The operating system my web server runs on is (include version):

Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux

Hi,

Could you please try to curl / dig the following website and see if there’s any error?

Please do curl -i -vv https://acme-v02.api.letsencrypt.org/ and `dig hdhdhttps://acme-v02.api.letsencrypt.org/

curl -i -vv https://acme-v02.api.letsencrypt.org/

gives:

  • Hostname was NOT found in DNS cache
  • Trying 104.96.151.199…
  • Connected to acme-v02.api.letsencrypt.org (104.96.151.199) port 443 (#0)
  • successfully set certificate verify locations:
  • CAfile: none
    CApath: /etc/ssl/certs
  • SSLv3, TLS handshake, Client hello (1):
  • SSLv3, TLS handshake, Server hello (2):
  • SSLv3, TLS handshake, CERT (11):
  • SSLv3, TLS handshake, Server key exchange (12):
  • SSLv3, TLS handshake, Server finished (14):
  • SSLv3, TLS handshake, Client key exchange (16):
  • SSLv3, TLS change cipher, Client hello (1):
  • SSLv3, TLS handshake, Finished (20):
  • SSLv3, TLS change cipher, Client hello (1):
  • SSLv3, TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
  • Server certificate:
  • subject: CN=acme-v02.api.letsencrypt.org
  • start date: 2019-07-19 04:46:54 GMT
  • expire date: 2019-10-17 04:46:54 GMT
  • subjectAltName: acme-v02.api.letsencrypt.org matched
  • issuer: C=US; O=Let’s Encrypt; CN=Let’s Encrypt Authority X3
  • SSL certificate verify ok.

GET / HTTP/1.1
User-Agent: curl/7.38.0
Host: acme-v02.api.letsencrypt.org
Accept: /

< HTTP/1.1 200 OK
HTTP/1.1 200 OK

  • Server nginx is not blacklisted
    < Server: nginx
    Server: nginx
    < Content-Type: text/html
    Content-Type: text/html
    < Content-Length: 2174
    Content-Length: 2174
    < Last-Modified: Fri, 02 Feb 2018 23:46:37 GMT
    Last-Modified: Fri, 02 Feb 2018 23:46:37 GMT
    < ETag: “5a74f85d-87e”
    ETag: “5a74f85d-87e”
    < X-Frame-Options: DENY
    X-Frame-Options: DENY
    < Strict-Transport-Security: max-age=604800
    Strict-Transport-Security: max-age=604800
    < Accept-Ranges: bytes
    Accept-Ranges: bytes
    < Expires: Thu, 05 Sep 2019 15:29:47 GMT
    Expires: Thu, 05 Sep 2019 15:29:47 GMT
    < Cache-Control: max-age=0, no-cache, no-store
    Cache-Control: max-age=0, no-cache, no-store
    < Pragma: no-cache
    Pragma: no-cache
    < Date: Thu, 05 Sep 2019 15:29:47 GMT
    Date: Thu, 05 Sep 2019 15:29:47 GMT
    < Connection: keep-alive
    Connection: keep-alive

<

Boulder: The Let's Encrypt CA

  <div class="col-xs-6 text-left">
    <h1>Boulder<br>
    <small>The Let's Encrypt CA</small></h1>
  </div>
</div>

<div class="row">
  <div class="col-xs-8 col-xs-offset-2 text-center">
    <h3>This is an <a href="https://github.com/letsencrypt/acme-spec/">ACME</a> Certificate Authority running <a href="https://github.com/letsencrypt/boulder">Boulder</a>.</h3>
    <p>This is a <em>programmatic</em> endpoint, an API for a computer to talk to. You should probably be using a specialized client to utilize the service, and not your web browser. See <a href="https://letsencrypt.org/"><tt>https://letsencrypt.org/</tt></a> for help.</p>
    <p>If you're trying to use this service, note that the starting point, <em>the directory</em>, is available at this URL: <a href="https://acme-v02.api.letsencrypt.org/directory"><tt>https://acme-v02.api.letsencrypt.org/directory</a></tt>.</p>
  </div>
</div>
<div class="row">
  <div class="col-xs-4 col-xs-offset-2 text-center">
    <p><a href="https://letsencrypt.status.io" title="Twitter">
      <i class="fa fa-area-chart"></i>
      Service Status (letsencrypt.status.io)
    </a></p>
  </div>
  <div class="col-xs-4 text-center">
    <p><a href="https://twitter.com/letsencrypt" title="Twitter">
      <i class="fa fa-twitter"></i>
      Check with us on Twitter
    </a></p>
  </div>
</div> <!-- row -->
* Connection #0 to host acme-v02.api.letsencrypt.org left intact

dig is not a package that can be installed on my machine.

curl -i -vv https://acme-v02.api.letsencrypt.org/

gives:

  • Hostname was NOT found in DNS cache
  • Trying 104.96.151.199…
  • Connected to acme-v02.api.letsencrypt.org (104.96.151.199) port 443 (#0)
  • successfully set certificate verify locations:
  • CAfile: none
    CApath: /etc/ssl/certs
  • SSLv3, TLS handshake, Client hello (1):
  • SSLv3, TLS handshake, Server hello (2):
  • SSLv3, TLS handshake, CERT (11):
  • SSLv3, TLS handshake, Server key exchange (12):
  • SSLv3, TLS handshake, Server finished (14):
  • SSLv3, TLS handshake, Client key exchange (16):
  • SSLv3, TLS change cipher, Client hello (1):
  • SSLv3, TLS handshake, Finished (20):
  • SSLv3, TLS change cipher, Client hello (1):
  • SSLv3, TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
  • Server certificate:
  • subject: CN=acme-v02.api.letsencrypt.org
  • start date: 2019-07-19 04:46:54 GMT
  • expire date: 2019-10-17 04:46:54 GMT
  • subjectAltName: acme-v02.api.letsencrypt.org matched
  • issuer: C=US; O=Let’s Encrypt; CN=Let’s Encrypt Authority X3
  • SSL certificate verify ok.

GET / HTTP/1.1
User-Agent: curl/7.38.0
Host: acme-v02.api.letsencrypt.org
Accept: /

< HTTP/1.1 200 OK
HTTP/1.1 200 OK

  • Server nginx is not blacklisted
    < Server: nginx
    Server: nginx
    < Content-Type: text/html
    Content-Type: text/html
    < Content-Length: 2174
    Content-Length: 2174
    < Last-Modified: Fri, 02 Feb 2018 23:46:37 GMT
    Last-Modified: Fri, 02 Feb 2018 23:46:37 GMT
    < ETag: “5a74f85d-87e”
    ETag: “5a74f85d-87e”
    < X-Frame-Options: DENY
    X-Frame-Options: DENY
    < Strict-Transport-Security: max-age=604800
    Strict-Transport-Security: max-age=604800
    < Accept-Ranges: bytes
    Accept-Ranges: bytes
    < Expires: Thu, 05 Sep 2019 15:29:47 GMT
    Expires: Thu, 05 Sep 2019 15:29:47 GMT
    < Cache-Control: max-age=0, no-cache, no-store
    Cache-Control: max-age=0, no-cache, no-store
    < Pragma: no-cache
    Pragma: no-cache
    < Date: Thu, 05 Sep 2019 15:29:47 GMT
    Date: Thu, 05 Sep 2019 15:29:47 GMT
    < Connection: keep-alive
    Connection: keep-alive

<

Boulder: The Let's Encrypt CA

  <div class="col-xs-6 text-left">
    <h1>Boulder<br>
    <small>The Let's Encrypt CA</small></h1>
  </div>
</div>

<div class="row">
  <div class="col-xs-8 col-xs-offset-2 text-center">
    <h3>This is an <a href="https://github.com/letsencrypt/acme-spec/">ACME</a> Certificate Authority running <a href="https://github.com/letsencrypt/boulder">Boulder</a>.</h3>
    <p>This is a <em>programmatic</em> endpoint, an API for a computer to talk to. You should probably be using a specialized client to utilize the service, and not your web browser. See <a href="https://letsencrypt.org/"><tt>https://letsencrypt.org/</tt></a> for help.</p>
    <p>If you're trying to use this service, note that the starting point, <em>the directory</em>, is available at this URL: <a href="https://acme-v02.api.letsencrypt.org/directory"><tt>https://acme-v02.api.letsencrypt.org/directory</a></tt>.</p>
  </div>
</div>
<div class="row">
  <div class="col-xs-4 col-xs-offset-2 text-center">
    <p><a href="https://letsencrypt.status.io" title="Twitter">
      <i class="fa fa-area-chart"></i>
      Service Status (letsencrypt.status.io)
    </a></p>
  </div>
  <div class="col-xs-4 text-center">
    <p><a href="https://twitter.com/letsencrypt" title="Twitter">
      <i class="fa fa-twitter"></i>
      Check with us on Twitter
    </a></p>
  </div>
</div> <!-- row -->
* Connection #0 to host acme-v02.api.letsencrypt.org left intact

dig isn’t available for my machine.

I gave the full reply from the curl command, but it was flagged as spam and held for review by a staff member. The first few lines of the output from:

curl -i -vv https://acme-v02.api.letsencrypt.org/

were:

  • Hostname was NOT found in DNS cache
  • Trying 104.96.151.199…
  • Connected to acme-v02.api.letsencrypt.org (104.96.151.199) port 443 (#0)
  • successfully set certificate verify locations:
  • CAfile: none
    CApath: /etc/ssl/certs
  • SSLv3, TLS handshake, Client hello (1):

So the netowkr seems to have no issue?
That’s really weird though…

Could either @schoen or @juergenauer take a look at this?

Thanks

Hi @FLg83

run your command with the -vvv option to see, which url doesn't work.

The output with the -vvv option is:

Creating virtual environment…
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in /opt/eff.org/certbot/venv/bin/python2.7
Also creating executable in /opt/eff.org/certbot/venv/bin/python
Installing setuptools, pip…done.
Installing Python packages…
Traceback (most recent call last):
File “/tmp/tmp.uUVenibClJ/pipstrap.py”, line 181, in
sys.exit(main())
File “/tmp/tmp.uUVenibClJ/pipstrap.py”, line 160, in main
for path, digest in PACKAGES]
File “/tmp/tmp.uUVenibClJ/pipstrap.py”, line 117, in hashed_download
response = opener(using_https=parsed_url.scheme == ‘https’).open(url)
File “/usr/lib/python2.7/urllib2.py”, line 431, in open
response = self._open(req, data)
File “/usr/lib/python2.7/urllib2.py”, line 449, in _open
‘_open’, req)
File “/usr/lib/python2.7/urllib2.py”, line 409, in _call_chain
result = func(*args)
File “/usr/lib/python2.7/urllib2.py”, line 1240, in https_open
context=self._context)
File “/usr/lib/python2.7/urllib2.py”, line 1197, in do_open
raise URLError(err)
urllib2.URLError: <urlopen error [Errno 101] Network is unreachable>

Perhaps your certbot-auto is too old.

certbot-auto --version

It should be newer than version 30, but the --version option is ignored. Certbot-auto --version just runs normally, as if --version is not there. The older versions of certbot-auto worked previously with Raspbian Jessie, but the newer versions don’t seem to be compatible.

I tried the exact same certbot-auto command that I tried at least 8 times before, but today it works. I’m guessing there was some archive that was off line for a couple of days. It sure would be nice if the archives that letsencrypt needs to function would be on line consistently. It would also be nice if letsencrypt certificates were valid for more than 90 days.

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