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
Hey,
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.
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_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
dpkg-query -l openssl 'libssl*' gcc python
Desired=Unknown/Install/Remove/Purge/Hold
| 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.
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