I got my app working from a Win11 desktop, but it fails to connect to SQL Server 2012 when deployed to a Docker host

[salfter]

I've knocked together a simple web app that queries one of our older databases that runs on SQL Server 2012 (don't ask why...at least it's running on Windows Server 2019). It runs fine on my desktop, but when I tried deploying it on one of our Docker hosts, I started getting 500 errors when the query was supposed to run. Looking at the output from the container, I'm getting this:

$ docker compose up
[+] up 1/1
 ✔ Container readid Created                                                                                     0.4s
Attaching to readid
readid  | INFO:waitress:Serving on http://0.0.0.0:5000
readid  | INFO:waitress:Serving on http://[::]:5000
readid  | ERROR:app:Exception on / [POST]
readid  | Traceback (most recent call last):
readid  |   File "/usr/local/lib/python3.14/site-packages/flask/app.py", line 1511, in wsgi_app
readid  |     response = self.full_dispatch_request()
readid  |   File "/usr/local/lib/python3.14/site-packages/flask/app.py", line 919, in full_dispatch_request
readid  |     rv = self.handle_user_exception(e)
readid  |   File "/usr/local/lib/python3.14/site-packages/flask/app.py", line 917, in full_dispatch_request
readid  |     rv = self.dispatch_request()
readid  |   File "/usr/local/lib/python3.14/site-packages/flask/app.py", line 902, in dispatch_request
readid  |     return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
readid  |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
readid  |   File "/usr/local/lib/python3.14/site-packages/flask_login/utils.py", line 290, in decorated_view
readid  |     return current_app.ensure_sync(func)(*args, **kwargs)
readid  |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
readid  |   File "/app/app/routes.py", line 88, in index
readid  |     conn = connect(getenv("SQL_CONNECTION_STRING"))
readid  |   File "/usr/local/lib/python3.14/site-packages/mssql_python/db_connection.py", line 46, in connect
readid  |     conn = Connection(
readid  |         connection_str, autocommit=autocommit, attrs_before=attrs_before, timeout=timeout, **kwargs
readid  |     )
readid  |   File "/usr/local/lib/python3.14/site-packages/mssql_python/connection.py", line 319, in __init__
readid  |     self._conn = ddbc_bindings.Connection(
readid  |                  ~~~~~~~~~~~~~~~~~~~~~~~~^
readid  |         self.connection_str, self._pooling, self._attrs_before
readid  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
readid  |     )
readid  |     ^
readid  | RuntimeError: [Microsoft][ODBC Driver 18 for SQL Server]SSL Provider: [error:0A000102:SSL routines::unsupported protocol]

I suspect it's trying to use TLS 1.3, but that's not available on Windows Server 2019. My Dockerfile starts with the python:3 image, which is based on Debian trixie and is using OpenSSL 3.5.5. Most of the information I've run across about controlling what protocols OpenSSL uses were written for OpenSSL 1.1.x. Is there a way to get this working?

[github-actions]

Hi @salfter, thank you for opening this issue!

Our team will review it shortly. We aim to triage all new issues within 24-48 hours and get back to you.

If you have additional information to share, please feel free to update the issue.

Thank you for your patience!

[salfter]

In the meantime, I think I've found something that works:

https://stackoverflow.com/a/77814036/5450693

tl;dr: include RUN sed -i '/\[openssl_init\]/a ssl_conf = ssl_configuration' /etc/ssl/openssl.cnf && echo "\n[ssl_configuration]" >> /etc/ssl/openssl.cnf && echo "system_default = tls_system_default" >> /etc/ssl/openssl.cnf && echo "\n[tls_system_default]" >> /etc/ssl/openssl.cnf && echo "MinProtocol = TLSv1" >> /etc/ssl/openssl.cnf && echo "CipherString = DEFAULT@SECLEVEL=0" >> /etc/ssl/openssl.cnf in your Dockerfile.

Performance seems sluggish (multiple seconds for a query that took less than a second on my desktop), but at least it's working. I have some other apps deployed that seem a bit slower than they should be that aren't talking to SQL Server, so this issue is most likely out of scope here.