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

Migrating a small application from OpenSSL 1.1.1 to OpenSSL 3.x without downtime is the goal. The deployment is constrained to a small number of instances and the linking model of the application is not yet confirmed.

OpenSSL 3.x introduces the provider architecture with default, base and legacy providers, and moves algorithms such as MD4, RC4 and Blowfish to the legacy provider. Certificate rotation can be achieved via in-process reload of the TLS context without a library change, with new connections using the new certificate while existing connections drain. A library upgrade generally requires a process restart. Rolling restart is documented as low risk behind a load balancer, but it assumes at least two instances or a temporary standby.

With a single instance the trade-off is between relying on reload for certificate changes versus accepting a restart for the library upgrade. Static linking would force a rebuild and redeploy, while dynamic linking changes the restart requirements. Session resumption and TLS ticket keys do not survive restarts unless externalized.

Does dynamic linking allow a restart-only upgrade to OpenSSL 3.x without a code rebuild? If the application is statically linked, can a reload-based approach still satisfy the library upgrade goal? How does session resumption handling affect perceived downtime during a single-instance restart?