SQL TDE and Certificate Handling Recommendations
I just have in the back of my mind, that if using one cert for all databases, that if the cert is 'compromised' then all databases that use it could be decrypted by an attacker?  


I assume that (compromised means), when "someone can steal database files .mdf and .ldf or backups and TDE Certificate along with it's Private key and could know the Password that been used to encrypt Certificate backup".  Do you think that can happen?


  My question is, should I use one certificate for all TDE use, or one certificate for each database?  


I don't think that having multiple certificate per each database can prevent it (above mentioned scenario). Because, there is possibility that someone who can steal one certificate can also steal multiple certificates.  


  Answer (in my opinion)  


However, in my opinion, database encryption alone cannot be full solution on security, you could also consider following:  


Infra level: Building strong firewall around the database servers
OS level: Avoiding multiple users as builtin\administrators in database servers etc..  


Also, the physical security (which is out of scope technical scope)

I believe, if you could implement TDE as per Standard TDE Architecture, would be fine and focus on surrounding security hiccups that may arise (as mentioned above).

...  

Edit Post:  

How strong your password (Source)?



To check the strength of your passwords and know whether they're inside the popular rainbow tables, you can convert your passwords to MD5 hashes on a MD5 hash generator, then decrypt your passwords by submitting these hashes to an online MD5 decryption service.   

For instance, your password is 0123456789A, using the brute-force method, it may take a computer almost one year to crack your password, but if you decrypt it by submitting its MD5 hash C8E7279CD035B23BB9C0F1F954DFF5B3 to a MD5 decryption website, how long will it take to crack it? You can perform the test yourself.