If you have ever wondered what is the difference between certificates and asymmetric keys in SQL Server 2005, then this post is hopefully going to answer this question.

First, let me make one important point clear: both certificates and asymmetric keys are encapsulating RSA keys, hence they are both containers for asymmetric key encryption keys. Hence, there is no difference between these as far as the cryptographic algorithm is concerned, and no difference in strength either, given the same key length.

So, why do we have both? Historically, support for certificates was introduced first, to allow the import of cryptographic keys from X.509 certificate files and the export of keys to such files. Asymmetric keys were introduced later to support the import of cryptographic keys from strong name files or assemblies. The syntax was kept separate because some of the existing creation options for certificates had no meaning for strong names (expiry date, for example). Thus, asymmetric keys were born next to certificates, as a more generic key container and having a more generic name as well.

So, which of these should we use? Currently, I prefer certificates, because of the option of exporting the keys to .CER files. Functionally, however, there is no significant difference between what you can do with a certificate and what you can do with an asymmetric key. The main factor that can force a decision here is if the keys are generated outside the server in either certificate format or strong name format; in this case, you would probably want to use the entity that allows the easier key import.

Finally, I would like to mention the existence of tools for creating certificates (makecert) and strong name files (sn); these tools offer a richer amount of flexibility in the key generation process than the SQL Server syntax. You can use such tools, for example, to create RSA keys with more exotic key lengths, then import them into SQL Server.