Reload-based TLS rotation vs rolling restart for OpenSSL 1.1.1 to 3.x on a single instance

Answer

For a dynamically linked application, upgrading the OpenSSL shared library from 1.1.1 to 3.x can be done with a simple process restart; no source code rebuild is needed as long as the binary does not call removed APIs. For a statically linked application, the OpenSSL version is baked into the binary, so a library upgrade requires rebuilding and redeploying the binary; certificate reload alone cannot change the library version.

Confirmed facts

• OpenSSL permits in‑process reload of SSL_CTX to update certificates and private keys; existing connections drain with old material while new connections use the updated material (available in both 1.1.1 and 3.x).
• When the application is dynamically linked to OpenSSL, upgrading libssl.so/libcrypto.so necessitates a process restart to load the new version.
• If the application is statically linked, the library version is embedded in the binary; changing to OpenSSL 3.x requires a rebuild and redeploy.
• Session resumption state (ticket keys or session IDs) lives in process memory; a restart clears it unless ticket keys are externalized, causing those clients to perform a full handshake after restart.
• Algorithms moved to the legacy provider (MD4, RC4, Blowfish, etc.) require the legacy provider to be loaded in OpenSSL 3.x.

Likely explanation

Dynamic linking isolates the OpenSSL code in a shared object, so swapping that object and restarting the process loads the new version without touching the application code. Static linking binds the OpenSSL code directly into the executable, making the library version part of the binary; therefore a version change can only be achieved by recompiling and redeploying the executable. Certificate rotation via SSL_CTX reload works independently of the library version and does not require a restart, but it cannot upgrade the OpenSSL implementation itself.

Steps for this case

1. Determine linking mode: run ldd ./your_binary or check build configuration to see if libssl/libcrypto appear as shared dependencies.
2. If dynamically linked:
   1. Place the new OpenSSL 3.x libssl.so and libcrypto.so in a directory covered by the loader’s search path (or update RPATH).
   2. Restart the process (e.g., via systemd restart).
   3. Verify the new version with ldd ./your_binary | grep libssl or runtime SSL_version(SSL_get_ssl()).
   4. Optionally reload certificates via SIGHUP or API to rotate TLS material without another restart.
3. If statically linked:
   1. Recompile the application against OpenSSL 3.x (ensure any legacy provider loading if needed).
   2. Redeploy the new binary.
   3. After deployment, you can still use certificate reload for future rotations.
4. Session resumption handling:
   1. If ticket keys are not externalized, expect a full handshake for returning clients after restart; this adds latency but does not cause downtime.
   2. To avoid latency, persist ticket keys to external storage (e.g., a file or Redis) and reload them after restart.

Missing diagnostic detail

Please confirm whether the application is dynamically or statically linked to OpenSSL, as this determines whether a restart‑only upgrade or a rebuild is required.