Monday, April 22, 2019

Ask your support question thoroughly

Asking your question thoroughly can sometimes answer it for you.

I have been struggling with database encryption recently. In a nutshell, I didn't know or have access to the passwords used to create any of the keys or certificates, but needed to overwrite the non-production environments with a copy from production.

I will end up writing another blog post about what my problem was, and how I solved it (so that when I come across it again I can refer to it), but all in all, I spent 2 full weeks researching what to do. I didn't want to mess up production and was being (probably overly) cautious. I ended up getting STAGE and QA environments running, but ran into different issues with DEV.

The certificate wasn't already on DEV, so I had to add it. I found out how to do that as well, and ran the commands, but the restore still wouldn't work. I got an error: "A key required by this operation appears to be corrupted." At this point in the project, my frustrations levels were high. After google-ing like a pro, I decided to place a question on the stackoverflow forums. I started laying out all the information in an organized format. I listed what production looked like (version and edition, number of databases, how many of them were encrypted, which keys lived where, etc.), then started listing what development looked like, for comparison. I was trying to ask the question in such a way, that someone would have no problem helping me because I was being thorough and had shown prior research, etc.

By doing the comparison, I solved my own problem. I found out that when I added the certificate to DEV, it ended up in the specific database, instead of the master database.

I have had to re-write this post a bit because I remove a LOT of rambling :) With everything said and done, things worked out because I tried to give as much information as I could to the person reading the question, which, in turn showed me where my issue was.


Powered by mod LCA