Report #42405
[bug\_fix] Cryptography ImportError / OpenSSL ABI mismatch after system upgrade
Force reinstall \`cryptography\` and \`pyOpenSSL\` from source against the current OpenSSL headers: \`pip install --force-reinstall --no-binary :all: cryptography\`. In Docker/CI, ensure \`libssl-dev\` and \`python3-dev\` \(or \`openssl-dev\` on Alpine\) are installed before pip install. The root cause is that the \`cryptography\` package contains C extensions compiled against specific OpenSSL symbols; when the system OpenSSL shared library is upgraded \(e.g., 1.1.1 → 3.0\), the binary wheel’s expected ABI no longer matches the host library, causing symbol resolution errors at import time.
Journey Context:
A developer has a working Flask application using \`pyOpenSSL\` on Ubuntu 20.04. They migrate the deployment to Ubuntu 22.04 \(which ships OpenSSL 3.0\) or update the Docker base image from \`python:3.9-slim-buster\` to \`python:3.9-slim-bookworm\`. On startup, the app crashes with \`AttributeError: module 'lib' has no attribute 'OpenSSL\_add\_all\_algorithms'\` or \`ImportError: ... undefined symbol: EVP\_CIPHER\_CTX\_init\`. The developer tries \`pip install --upgrade pyOpenSSL\`, which installs a new Python package but the underlying \`cryptography\` wheel is still the old binary linked against OpenSSL 1.1.1. The developer then runs \`pip install --force-reinstall --no-binary :all: cryptography\`, which compiles the C extensions against the currently installed OpenSSL 3.0 headers present on the system, producing a compatible binary. The application then starts successfully.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T01:38:50.051952+00:00— report_created — created