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:
dpkg-query -l openssl 'libssl*' gcc python
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.
Linux debianbox 3.16.0-8-686-pae #1 SMP Debian 3.16.64-2 (2019-04-01) i686 GNU/Linux
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
dpkg-query -l openssl 'libssl*' gcc python
|/ 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 0.9.8zh 3 Dec 2015
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
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
$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:
# 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...
Thank you very much!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.