OK, In case anyone wants to know, I got to the bottom of this.
The chain is pretty easy to work out:
Create Service Master Key (automatically done upon install)
Create Database Master Key (user creates their own key)
SymetricEncrypt(Service Key,Database Master Key) -> Store Encrypted Master Key into Master DB
Create Certificate
SymetricEncrypt(Database Master Key, Certificate Private Key) -> Store Encrypted private key in Master DB
Create Database Encryption Key (system creates a random key, but must be manually added to database)
ASymetricEncrypt(Certificate, Database Encryption Key) -> Store Encrypted DEK into database.
So, to decrypt the database data, you'll need to:
Use the SMK to decrypt the DMK
Use the DMK to decrypt the cert private key
Use the certificate to decrypt the DEK
Use the DEK to decrypt the database
The starting point is the Service Master Key... how is this stored (if you encrypt it, you can't retrieve data, and if left in plaintext your system is exposed).
The answer is, the SMK is encrypted with Data Protection API, which is a service built into windows.
Basically, data is encrypted with "secrets" from your user profile. So the same user profile must be used to decrypt the SMK.
Now that I know this, I can use DPAPI in my applications to encrypt my encryption keys :)
Since Mirroring operates by shipping over a live transaction log to the secondary servers, you'll need to start a new mirroring session.
Your secondary database has been out of sync for a week and unless you've managed to maintain a transaction log on the primary that spans that entire time (hint: you haven't), you'll need to start with a fresh backup on the secondary to establish a mirror session again.
This is also faster than theoretically letting a week's worth of logs get re-applied to the secondary anyways.
As for the primary database's availability, yes it will be available during any sync (whether resuming after a pause or setting up a new mirror), because it's always sending transaction logs to the secondary but that does not interfere with it's own availability.
Best Answer
Referencing the information in Updating an expired SQL Server TDE certificate, the post explains that it is easy to create a new certificate with an updated expiration date for use in TDE.
After executing the above commands, your database now uses the new certificate with regards to TDE.
However - the post makes it very clear that you still need to keep the old certificate in case you want to restore the database from a backup created when the old certificate was being used.
From that post (highlighting mine):
Additonally (from that post),
Additional information can be found in Replacing an expiring SQL Server encryption key. (Highlighting mine).