Certbot fails on any command while installing python packages

I ran this command: sudo certbot-auto --apache

It produced this output: https://gist.githubusercontent.com/tontonsb/dc36b0a0e4b1052503a552852b4f8e45/raw/a936c421cb7e83416ad7f330b9570b7acd2ea40f/certbot-debug.log

My web server is (include version): 2.4.10

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

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): the command fails with the same output


I needed to add a certificate for new domain, so I ran certbot-auto --apache. It started some self update (and partly succeeded) and now it’s broken - hangs up while installing some python packages whenever I try to run certbot-auto with whatever options (except --help, that one works). Unfourtunately, I am not able to decipher the error. Could you help with this problem?

I already tried:

  • Removing the file and wget’ing a new one, but the new one does exactly the same. So I believe the wrapper to be up to date.
  • Upgrading all the debian packages as well. Upgrade succeeded, but it doesn’t help with the issue.
  • Running certbot-auto with --no-download, --no-bootstrap directives. It seems to only affect the debian package upgrades but python still runs and fails.
  • Changing certbot file to add --no-download to virtualenv like suggested in other issues. Didn’t change the behaviour.

Some more info would help. This has some tell-tails of a package conflict:

uname -a
cat /etc/os-release
dpkg-query -l openssl 'libssl*' gcc python
openssl version
python -V

If you haven’t already tried, try fully removing /opt/eff.org/certbot as well.

Thank you for looking into my issue! I just tried removing /opt/eff.org/certbot but unfourtunately the problem remains.

Here is the information, I hope some of it is useful.

uname -a
Linux debianbox 3.16.0-8-686-pae #1 SMP Debian 3.16.64-2 (2019-04-01) i686 GNU/Linux

cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION="8 (jessie)"

dpkg-query -l openssl 'libssl*' gcc python
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                 Version                 Architecture            Description
ii  gcc                                  4:4.9.2-2               i386                    GNU C compiler
ii  libssl-dev:i386                      1.1.1c-1+0~20190710.13+ i386                    Secure Sockets Layer toolkit - development files
un  libssl-doc                           <none>                  <none>                  (no description available)
un  libssl1.0-dev                        <none>                  <none>                  (no description available)
ii  libssl1.0.0:i386                     1.0.1t-1+deb8u11        i386                    Secure Sockets Layer toolkit - shared libraries
ii  libssl1.1:i386                       1.1.1c-1+0~20190710.13+ i386                    Secure Sockets Layer toolkit - shared libraries
ii  openssl                              1.1.1c-1+0~20190710.13+ i386                    Secure Sockets Layer toolkit - cryptographic utility
ii  python                               2.7.9-1                 i386                    interactive high-level object-oriented language (default version)

openssl version
OpenSSL 0.9.8zh 3 Dec 2015

python -V
Python 2.7.9

This is a bit outdated server that I try to keep up to date, but still allow some legacy sites to work, so we actually have python 2.6, python 3.4 and OpenSSL 1.0.0 somewhere on the machine as well.


The problem is very likely to be that you have installed different OpenSSL packages globally.

When pyca cryptography builds, it looks like it is trying to build from the headers of 0.9.8 or 1.1.1, probably the former. It is doing that because the headers were installed into the global include path with something like make install.

Jessie ships with OpenSSL 1.0.1, right? You seem to have at least two other versions installed globally.

My experience with Linux is that if you build custom versions of OpenSSL, they need to stay out of the global system path/include directories, and you should keep them separate and link your legacy software to them with e.g. --with-openssl=.... Otherwise we end up in situations like these …

I don’t know if it’s possible to control pyca cryptography’s build process to choose different OpenSSL headers. At least, probably not in the context of certbot-auto’s controller. The simplest way I see out of this is to clean everything up so you’re back to only having the original OpenSSL 1.0.1 library available globally.

1 Like

I couldn’t find the include path as an environment variable and I don’t know how to debug it properly.

But I noticed that which openssl gives me /usr/local/bin/openssl and $PATH points to /usr/local/bin:/usr/bin:/bin. I tried moving the openssl from there and now (after restart) which openssl points to /usr/bin/openssl which is 1.1.1 not 0.9.8.

So I decided to go ahead and do the same with include directories hoping it works the same:

ls /usr/local/include
ls /usr/include

# both contained an openssl

sudo mv /usr/local/include/openssl /usr/local/include/openssl-0.9.8
sudo shutdown -r now

And indeed this worked. Now it goes like this:

Creating virtual environment...
Installing Python packages...
Installation succeeded.

Thank you very much!

1 Like

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