Error 33111: Cannot Find Server Certificate When Restoring a TDE Backup

Fix it now

The instance cannot find the certificate that protected this backup, and the message names the thumbprint it is looking for. The backup file is intact; what is missing is the key material. Create a database master key on the target, create the certificate there from its exported files, and the restore then behaves like any other.

-- On the SOURCE instance
BACKUP CERTIFICATE TDECert TO FILE = N'D:\keys\TDECert.cer'
  WITH PRIVATE KEY (FILE = N'D:\keys\TDECert.pvk', ENCRYPTION BY PASSWORD = '<strong password>');

-- On the TARGET instance
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<different strong password>';

CREATE CERTIFICATE TDECert FROM FILE = N'D:\keys\TDECert.cer'
  WITH PRIVATE KEY (FILE = N'D:\keys\TDECert.pvk', DECRYPTION BY PASSWORD = '<the password used above>');

1. Find the certificate the database uses: SELECT DB_NAME(database_id) AS db, encryption_state, encryptor_thumbprint FROM sys.dm_database_encryption_keys; and match it in SELECT name, thumbprint FROM sys.certificates;
2. Copy both files to the target over a path you trust, and put them where the SQL Server service account can read them. The engine opens them, not your session.
3. Confirm the thumbprint from the error now appears on the target before restoring anything.
4. Restore the database normally. No restore option overrides a missing certificate, so there is nothing else to try.

If the certificate and its private key are lost, an encrypted backup cannot be read by anyone, including Microsoft. There is no recovery route and no support case that changes that.

If the restore completes and the database is online, you are done. If it fails on the master key or the certificate files, the next section covers each link in the chain.

Why it happens

Encryption here is a chain rather than a single key. The service master key protects the database master key in master; the database master key protects the certificate; the certificate protects the database encryption key that lives inside the user database; and that key encrypts the data and everything written out of it, including backups. A backup of an encrypted database is therefore encrypted with a key you cannot use unless you also hold the certificate above it.

That is why moving the .bak file alone never works, and why no restore option exists to override it. The target needs its own database master key in master, and the same certificate created from the exported file with its private key attached. Microsoft’s documented procedure for moving a TDE-protected database says exactly this: create a database master key on the destination instance, then recreate the server certificate from the backup files, then bring the database across.

Each neighbouring code sits at one link in that chain. 33111 is the top of it: cannot find the server certificate with the named thumbprint. 15581 is the master database saying you must create a master key, or open the one you have, before this operation can proceed. 15208 says the certificate, asymmetric key or private key file is not valid, does not exist, or you do not have permissions for it. 33101 is the most specific of the four: the object cannot be used because its private key is not present or is not protected by the database master key, and SQL Server requires the ability to open that private key automatically.

Full reference

The chain of keys, top to bottom

Every link has to be present on the target for the one below it to be usable, which is why the order in the fix section is not optional. Create the master key, then the certificate, then restore.

What each error is complaining about

Editions that can host an encrypted database

This is worth checking before you spend an afternoon on key material, because no amount of certificate handling fixes an edition that cannot host the database. Transparent Data Encryption is available in Enterprise and Standard editions in SQL Server 2019, 2022 and 2025. It is not available in Web or in Express. If the target is Express, the restore will not succeed however correct your keys are.

If you only need the data rather than the encryption, restore onto an instance that supports TDE, turn encryption off there, and take a fresh unencrypted backup to move onwards. That is a supported route and it is usually faster than arguing about the target.

Protecting yourself before the next restore

1. Back up the certificate the moment you enable encryption, with its private key, and record the password.
2. Store the certificate file and the password in different places. A file and its password in the same folder is one compromise away from useless.
3. Test the restore on another instance before you rely on it. A certificate you have never imported is an assumption.
4. Back up the certificate again whenever it is rotated or replaced.
5. Include both the file and the password in whatever process protects your disaster recovery material, and check that process knows they exist.

Confirming the whole chain works

The strongest test is not that the restore completed. It is that the restored database is genuinely encrypted and readable on the target, which you can see in one query: SELECT DB_NAME(database_id), encryption_state FROM sys.dm_database_encryption_keys; where 3 means encrypted. Follow it with a fresh backup on the target and a test restore elsewhere, and you have proved the certificate, the master key and the encryption key all travel together.

Every code this article covers

Confirm the fix worked

1. Confirm the thumbprint from the error now appears in SELECT name, thumbprint FROM sys.certificates; on the target.
2. Complete the restore and confirm the database is online: SELECT name, state_desc FROM sys.databases;
3. Check the encryption state: SELECT DB_NAME(database_id), encryption_state FROM sys.dm_database_encryption_keys; where 3 means encrypted.
4. Confirm SELECT is_master_key_encrypted_by_server FROM sys.databases WHERE name = 'master'; returns 1, so the key opens automatically after a restart.
5. Take a fresh backup on the target and test-restore it elsewhere, to prove the whole key chain is in place.

Questions people ask about this