If your anything like the rest of the DEV teams in the world you know doubt have had some exposure to dealing with TLS 1.2 support for the many dependencies and applications you integrate with. There is a strong likelihood that your HTTP dependencies “just kind of worked” and you never looked into it or realized that perhaps it wasn’t even connecting on TLS 1.2.
TLS 1.2 was released over a decade ago (August 2008), and it feels painful to still deal with backwards and forwards compatibility of dependencies that may or may not support it. But, there are many legacy applications out there making millions of dollars for organizations that don’t get a lot of love sometimes.
There are many reasons your application may not be running requests over TLS 1.2 that I have run into many around older code or infrastructure that needed some updates. .NET Framework did not by default support TLS 1.2 until .NET Framework 4.6.1. Or even the OS your using itself may require specific patches that you need to do (or if it is not supported at all on that OS version you probably should be far off of it 🙂 ).
In this example specifically, you may have created a .NET Core 2.1 application API that you intended to abstract access over an older database running on SQL Server 2008. In your app and your runtime container, it works just fine.
You make the upgrade of .NET Core 2.1 to 3.1 which is pretty simple. In the process the container image gets updated as well:
Your application is now failing to connect to your SQL Server when inside the container only (works on your machine). What happened?
In this case, there are a couple of things at play. First, the difference in the containers between 2.1 and 3.1 is that support for TLS 1.0, 1.1 was dropped. Subsequently, it can only communicate on TLS 1.2 now. This is good and gives you confidence that EVERYTHING in your app is running with TLS 1.2. Unfortunately, it confirms your concern that the SQL Server 2008 install is not updated or patched properly and your previous communication was being downgraded and negotiated at a different lower version.
The conversation should, of course, be started to get that SQL Server 2008 upgraded in general to a new version, if not at least to SP3 (https://support.microsoft.com/en-ca/help/3135244/tls-1-2-support-for-microsoft-sql-server). However, that is always easier said than done, and in the short term, you need a workaround.
I’m not sure how I feel about this, and it definitely is super dirty. But sometimes you gotta do what you gotta do. Don’t tell anyone you found it on this blog 🙂 (Note: Mileage varies with this snippet depending on your container distro).
# downgrade TLS for SQL Server 2008 to connect (pre SP3) RUN sed -i 's/MinProtocol = TLSv1.2/MinProtocol = TLSv1/' /etc/ssl/openssl.cnf \ && sed -i 's/CipherString = DEFAULT@SECLEVEL=2/CipherString = DEFAULT@SECLEVEL=1/' /etc/ssl/openssl.cnf
Good luck – and be sure to update ASAP! Remember this is affecting the communication of all dependencies in the container by default…
RUN sed -i ‘s/MinProtocol = TLSv1.2/MinProtocol = TLSv1/’ /etc/ssl/openssl.cnf \
&& sed -i ‘s/CipherString = DEFAULT@SECLEVEL=2/CipherString = DEFAULT@SECLEVEL=1/’ /etc/ssl/openssl.cnf
Worked like a charm. Thank you. You saved my day.
Thx! Saved my day :3