Hi folks.
The 0.14.0 to 0.14.1 uprade has broken letsencrypt on a patched to current CentOS 6.9 install. The ultimate error of the stack trace is
“site-packages/cryptography/hazmat/bindings/_openssl.so: undefined symbol: OPENSSL_sk_num”
Can you do anything about this please??
if you did an OS update then openssl version is the most likely issue
You can either fallback to a previous certbot version of fix openssl
Andrei
Well, I regularly update the OS !
I’m sort of expecting letsencrypt to handle OS updates like this. Alternatively is there a way to link it to the correct version… I can always install what you need.
As the user you normally run certbot-auto as, if you delete the directory:
${XDG_DATA_HOME:-~/.local/share}/letsencrypt
and run certbot-auto again does it solve the problem?
No, have tried this many times, as well as flirting with python 2.7
I’ve now built 0.14.1 against python 2.6 and 2.6 on a standard CentOS 6.9 install, and all are failing with the same error ( and I’ve tried every logical suggestion on how to build in many threads )
Error:
ImportError: /root/.local/share/letsencrypt/lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so: undefined symbol: OPENSSL_sk_num
Background info
CentOS release 6.9 (Final)
openssl-1.0.1e-57.el6.x86_64
openssl-1.0.1e-57.el6.i686
linux-vdso.so.1 => (0x00007ffc39af3000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f3a483b4000)
libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f3a47fce000)
libpython2.7.so.1.0 => /opt/rh/python27/root/usr/lib64/libpython2.7.so.1.0 (0x00007f3a47c0a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3a479ed000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3a47658000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f3a47414000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f3a4712d000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f3a46f28000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f3a46cfc000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f3a46af8000)
libz.so.1 => /lib64/libz.so.1 (0x00007f3a468e1000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f3a466de000)
libm.so.6 => /lib64/libm.so.6 (0x00007f3a4645a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3a48917000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f3a4624e000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f3a4604b000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f3a45e31000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f3a45c11000)
lrwxrwxrwx 1 root root 19 May 17 12:06 /usr/lib64/libcrypto.so -> libcrypto.so.1.0.1e
lrwxrwxrwx 1 root root 19 May 1 06:05 /usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.1e
-rwxr-xr-x 1 root root 1971488 Mar 23 08:46 /usr/lib64/libcrypto.so.1.0.1e
-rwxr-xr-x 1 root root 311736 Apr 21 02:41 /usr/lib64/libssl3.so
lrwxrwxrwx 1 root root 16 May 17 12:06 /usr/lib64/libssl.so -> libssl.so.1.0.1e
lrwxrwxrwx 1 root root 16 May 1 06:05 /usr/lib64/libssl.so.10 -> libssl.so.1.0.1e
-rwxr-xr-x 1 root root 443416 Mar 23 08:46 /usr/lib64/libssl.so.1.0.1e
0000000000000000 DF UND 0000000000000000 libcrypto.so.10 sk_num
00000000000e5d00 g DF .text 000000000000000e libcrypto.so.10 sk_num
I have also summed these libraries against other CentOS 6 releases and they match. So, as far as I can tell, the code will not run against openssl version 1.0.1e.
Where to from now?
Not the best test in the world, but I spun up a quick Centos 6.9 VM (x86_64) and ran a quick test to get a test certificate. I didn’t run into the error. I’d advise trying a clean certbot-auto setup if possible. It’s very likely that the python cryptography library installed by the tool (in the ~/.local/share/letsencrypt structure) was partly broken and may have since been fixed.
Now, I didn’t get far enough to actually gain the cert. The challange failed since I requested from my personal system, which wouldn’t be able to validate the challenge. However, I got past the account creation process and far enough to get to the verification. If the error occurs past that, I can try a different way.
did you do a yum update first?
In my case, I did do so. I also made sure the yum cache was fully cleared so I’d get the most up-to-date file lists.
As you're probably aware at this point, the problem is occurring in our cryptography dependency. This is what the cryptography maintainer said before here when someone else hit this problem:
OPENSSL_sk_num is a symbol used under the covers for manipulating stack structures. It was added in 1.1.0 and did not exist prior to that, so the problem here is likely that it's looking at the 1.1.0 include headers during compile but then loading an older OpenSSL.
I really cannot emphasize enough that it is extremely difficult to install your own custom OpenSSL and expect it to work reliably. The way the compiler does include and linker paths can be extremely counterintuitive.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.