Sample Header Ad - 728x90

Is self signed cert the standard practice for SQL Server Always Encrypted?

3 votes
2 answers
1601 views
We're implementing SQL Server Always Encrypted in our 2019 environment. We've done several successful POC's over the last few months, but in moving the solution to Prod, I was expecting to use a Public Trusted CA for the certificates. But now, combing back over approximately 10 AE tutorials on the web, including the official Microsoft instructions, I've noticed that using a Public Trusted CA is never even mentioned...ever...at all. There's even an article on here asking if using a Trusted CA cert even adds any benefit, and it's suggested that it does not. I'm trying to satisfy all of our security initiatives that are being rolled out company wide, so I guess I'm trying to find some sort of standard answer I can point to. I've been talking about how self signed certs are subject to man-in-the-middle attacks, but I think I'm beginning to realize this is only for SQL connections being made, and any data that flows through that connection (because in the tables the data is unencrypted, and the SSL encrypts it). But with AE, the data in the database is already simply an encrypted string. So does the nature of an Always Encrypted solution, if done where the self signed certs are never made or live on the same server that holds the data, preclude any MIM attacks? Is simply using self signed certs the accepted "standard" way of doing it? Thinking it through, I believe the answer is yes, but would just like some sort of "official" answer lol.
Asked by Emo (143 rep)
Feb 13, 2024, 03:18 PM
Last activity: Feb 14, 2024, 04:42 AM