SQL Server Self-Signed Certificate “Vulnerabilities”– FFS Get Off My Lawn

Refresher

It may be news (or not) to you that SQL Server can utilize the latest transport security standards when talking to clients and servers. Normally you’d need to create your own certificate for use with said standard protocols, but SQL Server is super nice and will create one for you, self-signed, and use that if one isn’t configured by the powers that be.

This happens at startup and is completely transparent to both end users and administrators alike, apparently not so much to your security team utilizing the latest and greatest security tools available (yes, that’s sarcasm). One day you may get a notice that “SQL Server is using a self-signed certificate (issue #1) and that the key length/algorithm isn’t what our internal security team allows (issue #2). You must fix asap or be out of compliance!” Oh no, the dreaded compliance threat.

Breakdown – Issue #1 – “Self-Signed”

This is basically a non-issue.

Yes, it’s self-signed and it doesn’t fit into your (or lack thereof) enterprise public key infrastructure and there is no way to know if it should truly be trusted. It’s also perturbing the security gods and they are wrath and vengeful spirits… However, there is a super simple fix to this, use your own certificate 😀 ! Microsoft gives you, the administrator, the ability to use your own certificate and set up the certificate (mostly) how you’d like where the offering of it appeases the security gods scanning tool. No, this isn’t a “product defect” or “bug”, it’s a “you didn’t configure one so a default one was generated so everything wasn’t in plain text if you didn’t want it to be” which is awful nice of SQL Server. Put in that request for a certificate, wait 2 weeks for your request to get approved and another two weeks for it to be sent to you… probably should build in some time for requests that weren’t executed to the spec required, thus causing it to be done again because no one read the requirements needed for the certificate on the Microsoft side.

Breakdown – Issue #2 – “Cipher/KeyLength”

Just like the first, this is a non-issue.

The default values, at the time the original binaries were released, we chosen based on the current standards. This means I’m looking at you with extreme disdain while a “security expert” tells me that a SQL Server 2008 instance using the self-signed certificate isn’t using “secure enough” ciphers or key lengths, meanwhile it’s now 2020 (12 years in the future). Sure, I bet it isn’t, because it’s been 12 years.

The fix?! Simple, use your own certificate! (See the fix for Issue #1, because it’s the same) It’s amazing how often this comes up, often enough that I had to blog about it in hopes that some poor soul who is being railed by their security stumbles upon this post and can fire back with an immediate action which would be (say it with me!) to use your own certificate!

Why Do I Say It’s A Non-Issue?

You might be thinking (or yelling), “Well, Sean, you dolt, you make it sound like it isn’t a problem when clearly there are security checks for these types of things! This must be an issue or it wouldn’t be flagged by our wondrous software.” To which my response is a question… What are you using the self-signed certificate to do? Are you using SQL Server transport layer security (TLS) and have the clients configured to ask for encryption? Are you forcing encryption on the server to the clients? I might go as far to even ask if you’re using SQL Auth… but honestly that’s not a good justification and given that you can use Kerberos realms on Linux for Windows Auth so I’m not buying what you’re selling. I’m going to go ahead and say you’re probably not doing the aforementioned items, which means you’re not using that self-signed certificate, which means it being there isn’t an issue.

It’s an easy fix to a problem that doesn’t exist, get yourself a certificate you feel you can trust (or at least security tells you to trust) and have a mimosa for a job well done.