How to automate PFX certificate renewal, password included
Many systems still want a password-protected .pfx file, and with shorter certificate lifetimes exporting them by hand no longer works. This guide shows how to produce, name and protect PFX files automatically on every renewal.
Who still needs PFX files
A PFX (PKCS#12) file bundles the certificate, its chain and the private key in one password-protected file. Plenty of software wants exactly that: IIS’s Centralized Certificate Store, Windows services you import by hand, Java and Tomcat keystores, .NET applications, Azure App Service uploads, load balancers, VPN and network appliances, and any vendor whose instructions start with “upload your .pfx”.
With certificates now lasting at most 200 days, and soon 100 and then 47, exporting and copying PFX files by hand stops being a once-a-year chore and becomes a constant one. The hard parts are always the same: where the password lives, how the file gets to the right place, and how anyone knows which file is which.
Doing it by hand, for reference
With OpenSSL, turning a renewed certificate into a PFX looks like this:
openssl pkcs12 -export -out example.com.pfx -inkey privkey.pem -in cert.pem -certfile chain.pemIt works, but someone has to run it after every renewal, choose and store a password, and copy the file to every place that needs it.
Automating it with EverTLS
An EverTLS agent writes the PFX for you on every renewal, into a folder on the server or a network share. Under the certificate’s Install automatically, choose Files and tick Also save a password-protected PFX.
Clear file names
Each PFX is named after its certificate: example.com_standard.pfx, or example.com_wildcard.pfx for *.example.com. Folders can use {name}, for example D:\Certs\{name}, so every certificate gets its own folder. For IIS’s Centralized Certificate Store, EverTLS uses the names IIS looks for instead (www.example.com.pfx, _.example.com.pfx).
The password, without spreadsheets
- Generated per certificate on the server and saved as
password.txtnext to the PFX, handy when the folder is handed to someone else; - generated and kept in the agent’s encrypted store, which you can read on that server with
evertls-agent pfx-password listandshow NAME; - your own password stored on the server, one per certificate or a shared one (
evertls-agent pfx-password set NAME), which EverTLS never sees; - or a password typed in the dashboard, stored encrypted and sent to the agent with each renewal.
Old systems
Windows Server 2016 and older, and older Java versions, can’t open modern AES-encrypted PFX files. Choose Legacy encryption (3DES), or keep AES and also write a -legacy.pfx copy for the old systems.
Many certificates at once
With New certificate → Many at once you paste a list of domains, and every certificate gets its own key generated on the server, its own folder and PFX and its own password, renewed and re-exported automatically.
Pipelines and scripts
Prefer to pull the file? For certificates whose key EverTLS holds (not agent-generated keys), the REST API returns a PFX with the password you choose:
curl -s -X POST https://app.evertls.com/api/v1/certificates/CERT_ID/download \
-H "Authorization: Bearer $EVERTLS_TOKEN" -H "Content-Type: application/json" \
-d '{"format":"pfx","password":"choose-a-long-password"}' -o example.com.pfxKeep the private key where it belongs
If you let the agent generate the key, it’s created on your server and only the certificate request travels to EverTLS. The PFX is assembled there, on your server, which is the safest way to produce one.