Installing OpenSSL 3 is not the supported fix for this Aspose package: Aspose.Words for Python via .NET identifies libssl1.1 as its Linux dependency, so the next action is to have Aspose provide or identify a build compatible with the Azure App Service built-in Python image—or move the Aspose operation to hosting where its native runtime can be controlled.^1^^2^

What the current evidence means

Your conclusion that Aspose 26.2.0 necessarily requires OpenSSL 3 is not established. The publisher’s documented dependency points in the opposite direction—toward OpenSSL 1.1—and Aspose has a matching report for this exact error.^3^

Because Bullseye already exposes libssl.so.1.1, the error can mean more than “the SONAME is absent.” The embedded runtime may be:

• loading a different native library than expected;
• finding libssl.so.1.1 but failing to resolve one of its dependencies or symbols;
• shipping a native component built for a different ABI;
• rejecting the loaded OpenSSL implementation during initialization.

Consequently, extracting Bookworm’s libssl.so.3 into Bullseye does not resolve the documented Aspose dependency. Mixing shared libraries from different Debian releases can also leave unresolved transitive dependencies even when the .so files exist.

Capture the precise loader failure for Aspose

Run this from the app’s SSH session before Gunicorn starts, replacing the package path only if necessary:

ASPOSE_DIR="$(python -c 'import aspose,os; print(os.path.dirname(aspose.__file__))')"

find "$ASPOSE_DIR" -type f -name '*.so' -print \
  -exec sh -c 'echo "== $1"; ldd "$1" | grep -E "ssl|crypto|not found"' _ {} \;

ldconfig -p | grep -E 'libssl|libcrypto'
readelf -d /usr/lib/x86_64-linux-gnu/libssl.so.1.1 | grep SONAME

Then reproduce the smallest failing call under the dynamic loader’s diagnostics:

LD_DEBUG=libs,versions \
python -c '
import aspose.words as aw
lic = aw.License()
lic.set_license("/home/site/wwwroot/license.lic")
' 2>/home/LogFiles/aspose-loader.log

The log should distinguish:

• libssl.so.1.1 => not found: library search/visibility problem.
• version 'OPENSSL_…' not found or undefined symbol: binary or symbol-version incompatibility.
• The correct library loads, followed by the same Aspose abort: escalate to Aspose with the loader log and package version.

.NET native loading uses platform library-name variations and the operating system’s native-library search behavior.^4^

Do not repeat the OpenSSL 3 extraction or copy Bookworm libraries into /usr/lib; it does not match Aspose’s stated dependency and is not a durable deployment model.

Supported paths under your constraints

Azure controls the OS and application stack of built-in App Service images. Applications that require control over native OS components must use a custom image or another hosting model.^5^

Since a custom container is prohibited, the practical options are:

1. Open an Aspose support case with:
   • aspose-words==26.2.0;
   • Python 3.11.15;
   • Debian 11 and x86-64;
   • output from ldd, ldconfig, and aspose-loader.log;
   • the minimal License.set_license() reproduction.
   Ask specifically which OpenSSL SONAME/ABI 26.2.0 targets and whether a compatible wheel or corrected build is available for this App Service image.
2. Use an Aspose version explicitly confirmed by Aspose to support this exact image. Do not downgrade speculatively; verify the version and security/support implications with the publisher first.
3. Move only document processing to a separately hosted service whose OS dependencies you can control, while leaving FastAPI on the existing code-deployed App Service.

Changing Python 3.11 to 3.12 is not expected to solve an embedded native-runtime ABI conflict when both selected built-in images remain Bullseye. App Service’s documented route for an unsupported runtime or OS requirement is a custom container.^6^

Also, CLR_OPENSSL_VERSION_OVERRIDE does not install or convert OpenSSL libraries; it only selects a preferred version. It was renamed to DOTNET_OPENSSL_VERSION_OVERRIDE starting with .NET 10, so changing the variable name is relevant only if Aspose confirms its embedded runtime is .NET 10.^7^

References

1. System Requirements|Aspose.Words for Python via .NET
2. Dependency of libssl1.1 for Aspose.words for Python via .Net
3. Python error: No usable version of libssl was found
4. Native library loading
5. Azure App Service OS and runtime patching
6. Configure a Linux Python app for Azure App Service
7. Environment variable renamed to DOTNET_OPENSSL_VERSION_OVERRIDE