Data Protection and Shortened Certificate lifetimes

[MCFHTAGENTS]

So I use Data Protection in my MVC Core App and have a config section like this:

"DataProtection": {
  "ProtectCertificateThumbprint": "xxx",
  "UnprotectCertificateThumbprint": [
    "xxx",
    "xxx",
    "xxx",
  ]
},

So far so good.
However as we adopt shorter certificate lifecycles this is becoming unmanageable. I can setup a client for say letsencrypt and pull in certificates and store them but it would be much cleaner if my app could handle the whole thing and manage the list of historic and current certificates.

I am not aware of a component that can do this.

[SumiyaE]

You probably don't need to follow the TLS rotation here at all. The certificate Data Protection uses is only an RSA key that wraps the key ring XML at rest. It's never presented to a client, so it doesn't need to come from a public CA. The shorter lifetimes you're adopting apply to publicly trusted TLS certificates.

So the simplest fix is a dedicated, long-lived, self-signed certificate used only for Data Protection, kept separate from your Let's Encrypt certificates. For example:

openssl req -x509 -newkey rsa:3072 -nodes -days 3650 -subj "/CN=MyApp DataProtection" -keyout dp.key -out dp.crt
openssl pkcs12 -export -inkey dp.key -in dp.crt -out dp.pfx

One thing to watch: pass it as an X509Certificate2, not as a thumbprint.

var cert = X509CertificateLoader.LoadPkcs12FromFile("dp.pfx", password); // .NET 9+; on older versions: new X509Certificate2("dp.pfx", password)
builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(keyRingPath)) // or whatever you use today
    .ProtectKeysWithCertificate(cert);

The two overloads behave differently:

• ProtectKeysWithCertificate(string thumbprint) resolves the certificate through CertificateResolver, which searches the store with validOnly: true (CertificateResolver.cs#L35-L45). A self-signed certificate that isn't trusted, or one that has expired, won't be found, and startup throws (DataProtectionBuilderExtensions.cs#L240-L249).
• ProtectKeysWithCertificate(X509Certificate2) uses the instance as-is, with no validity check, and also registers it for decryption (DataProtectionBuilderExtensions.cs#L215-L232).

If you ever do rotate it, the mechanism is the one you already have. Encrypt with the new certificate, and keep the old ones in UnprotectKeysWithAnyCertificate(old1, old2, ...) (L274-L290). Decryption matches the certificate recorded in each key's XML by thumbprint (EncryptedXmlDecryptor.cs#L101-L127). With a 10-year certificate, though, that list stays short.

(I verified this against the aspnetcore source but didn't run it.)

[MCFHTAGENTS]

So conceptually this makes sense (and thank you for the very obscure difference with the methods).

However I now run into a problem of where to persist the PFX file. I have tried in C:\ and given the DefaultAppPool identity read access to it but all I get is file not found. Also in the directory where the rest of my app is installed to in my cloud provider.
It works fine in my development box with elevated permissions.
It makes sense to me that this should be very locked down so an ideas?

[SumiyaE]

"File not found" can mean two different things here, and the fix depends on which one you're seeing.

1. System.IO.FileNotFoundException: the path itself is wrong.
Under IIS the current directory is not your app folder, so a relative path like "dp.pfx" won't resolve. Use an absolute path, or build one from builder.Environment.ContentRootPath.

2. CryptographicException: The system cannot find the file specified: the classic IIS one, and the likely case given "works on my dev box".
The PFX is read fine, but by default (DefaultKeySet, which is usually the user key set) Windows imports the private key into the current user's key store (X509KeyStorageFlags). An app pool identity often has no loaded user profile, so there's nowhere to put the key, and you get that misleading "file not found". Tell .NET not to use the user store:

var cert = X509CertificateLoader.LoadPkcs12FromFile(
    pfxPath, password,
    X509KeyStorageFlags.EphemeralKeySet); // key stays in memory, nothing written to disk
// older .NET: new X509Certificate2(pfxPath, password, X509KeyStorageFlags.EphemeralKeySet)

X509KeyStorageFlags.MachineKeySet also works; it puts the key in the machine store instead. Alternatively, set Load User Profile = True on the app pool (Advanced Settings). Load the certificate once at startup and reuse the instance.

On "where to persist it" so it's locked down: I'd skip the PFX file and password on disk entirely, and use the machine certificate store.

1. Import the PFX once into Local Computer → Personal (certlm.msc, or Import-PfxCertificate -CertStoreLocation Cert:\LocalMachine\My).
2. Right-click the certificate → All Tasks → Manage Private Keys… → add IIS AppPool\DefaultAppPool (or your pool's identity) with Read only.
3. Load it from the store yourself and pass the instance. As mentioned earlier, the thumbprint overload uses validOnly: true and would reject a self-signed certificate.

using var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadOnly);
var cert = store.Certificates
    .Find(X509FindType.FindByThumbprint, thumbprint, validOnly: false)
    .Single();

builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(keyRingPath))
    .ProtectKeysWithCertificate(cert);

This way there is no PFX file or password lying around, and only the pool identity can use the private key.

(I haven't reproduced this on an IIS box. This is based on the documented key-storage behaviour above and on the same Data Protection overloads as before. If it's still failing, the exact exception type and message would narrow it down.)