Clarification on POSH-ACME Certificate PFX Storage

[ariesabdeali]

hello - I would like to understand the design and security considerations behind how POSH-ACME handles certificate storage.

We have observed that PFX files and certificate details are being stored at the endpoint user profile level. Additionally, the PFX password appears to be encoded. Upon certificate renewal, expired certificate details are retained, and new certificate details are created within the user profile.

In our setup, we are also importing certificates into the Windows Certificate Store. Given this, we would like to understand why POSH-ACME still maintains certificate data within the local user profile.

From a security and compliance perspective, we would appreciate clarification on the following:

• What is the reason for storing PFX files and certificate metadata within the user profile context?
• How is the PFX password protected, and what level of encryption is used?
• Are there any risks of unauthorized access or decryption by other users or processes on the same system?
• Is there a recommended approach to securely manage or relocate these certificates (e.g., Windows Certificate Store, HSM, or secure vault integration)?
• Can this storage behavior be configured or overridden to align with enterprise security policies?

We want to ensure that this implementation does not introduce any potential security risks or policy compliance issues in our environment.

Appreciate your guidance and best practices on this.

Thank you

[rmbolger]

Most of the answers to your questions revolve around the fact that Posh-ACME is a cross-platform application and the Windows Certificate store does not exist anywhere but Windows. While the underlying .NET libraries for cert management do have some cert store abstractions on non-Windows OSes, they ultimately just store the cert data on the filesystem in the current user's profile. To answer your specific questions.

What is the reason for storing PFX files and certificate metadata within the user profile context?

Because many users find this convenient when they are using certificates for software that doesn't utilize the Windows certificate store.

How is the PFX password protected, and what level of encryption is used?

The PFX password is obfuscated on disk. It is not encrypted.

Are there any risks of unauthorized access or decryption by other users or processes on the same system?

Anyone who has access to the user profile (such as admin or system users) where the config is stored can find the PFX password.

Is there a recommended approach to securely manage or relocate these certificates (e.g., Windows Certificate Store, HSM, or secure vault integration)?

Users may choose to self-manage the certificate private key and use Posh-ACME with a CSR file instead of having Posh-ACME manage the private key lifecycle. In this case, Posh-ACME has no access to the private key and no PFX file is generated. Keep in mind, this would also prevent Posh-ACME from being able to install the resulting certificate into the Windows cert store.

Users may also choose to simply delete the Posh-ACME config from disk after the cert has been obtained if they don't need the data available for renewals down the road or have alternative methods to re-create the config during a renewal.

Can this storage behavior be configured or overridden to align with enterprise security policies?

Users may choose to relocate the Posh-ACME config with the POSHACME_HOME environment variable. The following guide provides additional guidance.
https://poshac.me/docs/latest/Guides/Using-an-Alternate-Config-Location/

[ariesabdeali]

Hello,

Thank you for the quick response.

We are using a PowerShell script with POSH-ACME, scheduled via Windows Task Scheduler (runs twice daily), to automate certificate renewal and IIS binding. The script uses Submit-Renewal to check expiry and renew certificates when required, logs all activities in JSON format, and automatically updates IIS HTTPS bindings with the renewed certificate. Currently, POSH-ACME manages the certificate lifecycle and stores PFX and related data in the user profile. Our goal is to keep this automation while improving the security of PFX/password handling

Due to existing automation constraints, we are continuing with the PFX-based approach. From a security perspective, we would like your guidance on the following key points:

• What is the best recommended approach to securely protect the PFX password, given that it is currently only obfuscated on disk?
• Is there any supported method to integrate stronger encryption with POSH-ACME for password protection?
• Would restricting access to the POSH-ACME config location and relocating it using POSHACME_HOME be sufficient, or are additional controls recommended?
• From a practical standpoint, is it acceptable to continue using the PFX approach with enhanced security controls, or would you strongly recommend moving away from PFX for better security?

[rmbolger]

Honestly, there's no point in trying to protect the PFX password when the unencrypted private key file is sitting in the same folder right next to the PFX file. Most ACME clients that manage the private key lifecycle work this way as well. The security boundary is the filesystem permissions on the config folder. On Windows, that typically means admin-level users have access in addition to the user itself. Moving the config location and setting custom ACLs to deny admin-level users is possible as well, but it's usually possible for a determined admin-level user to override those ACLs.

If you're really concerned about the security of the cert private key and don't trust the OS-level protections in place for the filesystem location they're stored in, you should self-manage the private key using whatever protections you deem sufficient and use Posh-ACME with the -CSRPath option. I don't forsee spending much development effort trying to protect the cert private key because it's just not a very common attack vector. An attacker who is on your system and capable of reading the private key on disk, can likely just as easily request a brand new cert using the same config data that task scheduler would be using to renew the cert.

Most users are more concerned about the protection of Credentials and API Keys associated with the DNS plugins. That's where the majority of the security/encryption development effort exists. By default on Windows, sensitive plugin parameters are AES encrypted using user+machine specific keys provided by Windows' DPAPI. But you can also utilize the PowerShell SecretManagement module to integrate with a variety of external secret stores. In that case, the AES key used to encrypt the plugin parameters is stored in the external secret store. More info on that here.
https://poshac.me/docs/latest/Guides/Using-SecretManagement/

[ariesabdeali]

We are planning to run POSH-ACME using a dedicated service account with no interactive login, and restrict access to the config folder to this account only.

We understand that normal users will not have access, but administrators may still be able to access the user profile if required.

From your experience, is this level of restriction considered sufficient for securing the certificate private key in a production environment, or are there additional controls you would recommend?

[rmbolger]

That all sounds like a good plan and should be sufficient. Just be aware that the default DPAPI encryption for the plugin parameters is user specific. So if you're using a plugin that has sensitive parameters that would be encrypted, you'll need to run the initial cert request in the context of the service account so they get encrypted with the service account's key and not another admin's key.

Alternatively if you do want admins to be able to manage the config outside the context of the dedicated service account, you should have the initial admin run Set-PAAccount -UseAltPluginEncryption before letting the scheduled task take over renewals. This will switch the plugin encryption to using a non-user specific key stored with the rest of the Posh-ACME account config.

You can also ignore all of this if you're using a plugin without sensitive parameters like WebRoot or WebSelfHost because there's nothing to encrypt/decrypt. Basically, if you don't have to provide parameter as a SecureString or PSCredential value, there's nothing to worry about.

[ariesabdeali]

Hi Team,

We are using Posh-ACME in an automated IIS certificate renewal workflow and had a few security concerns identified during an audit.

We are currently using:

Submit-Renewal for automated renewals (scheduled task, runs twice daily)
Install-PACertificate to install and bind certificates to IIS

However, we observed the following:

1. PFX files are written without a password by default

   Our audit flagged this as a critical issue (unencrypted private key on disk so we need to secure password)

2. Install-PACertificate imports certificates as exportable

   Our current module version does not support -KeyStorageFlags NonExportable

3. Submit-Renewal does not accept -PfxPass, but internally uses $order.PfxPass

Questions

1. What is the recommended way to securely enforce a PFX password when using Submit-Renewal?

   Is setting $order.PfxPass before renewal the correct/supported approach?

2. Is there a supported way to prevent private keys from being exportable in older versions of Posh-ACME?

   If not, is upgrading the only option?

3. Does Submit-Renewal guarantee reuse of $order.PfxPass, or are there edge cases where it may be ignored?

4. Is there any roadmap or support for:

   Passing PfxPass directly to Submit-Renewal
   Enforcing secure defaults (non-empty password, non-exportable keys)

[rmbolger]

The -NotExportable flag was added to Install-PACertificate way back in 2019. Are you really still using a 3.x version of the module? If so, I honestly can't really speak to how that version of the module functions. It's been too long and I don't feel like perusing the code to find out. So my answers will be based on the current version.

PFX files are written without a password by default
Our audit flagged this as a critical issue (unencrypted private key on disk so we need to secure password)
What is the recommended way to securely enforce a PFX password when using Submit-Renewal?
Is setting $order.PfxPass before renewal the correct/supported approach?

Generated PFX files do have a default password. If not otherwise specified, the default password is just "poshacme". That said, it doesn't really matter what the PFX password is because the unencrypted private key resides in the same folder as the PFX file as I mentioned in one of my previous responses.

If your policies don't allow unencrypted private key files on disk, you'll need to manage the private key yourself, generate your own CSR files, and use the module with the -CSRPath parameter. This will also prevent the auto-creation of PFX files and the use of Install-PACertificate since both require a module-accessible private key to function.

Modifying an order object is not the way to set a PFX password. For existing orders, you'll want to use Set-PAOrder with the -PfxPass or -PfxPassSecure parameters (the secure version may only exist in 4.x). For new orders, those fields are also available in New-PAOrder and New-PACertificate.

Install-PACertificate imports certificates as exportable
Our current module version does not support -KeyStorageFlags NonExportable
Is there a supported way to prevent private keys from being exportable in older versions of Posh-ACME?
If not, is upgrading the only option?

Aside from using your own custom code to import the PFX files, no there's no supported way to make them non-exportable in those old versions. That's why the feature was added to the newer versions.

My suggestion would be to upgrade to the latest 4.x version which supports a -NotExportable switch flag on Install-PACertificate. Alternatively, you could upgrade to at least v3.11.0 which first introduced that feature. But there are likely bug fixes with it over time, so if you really can't go to 4.x, I'd at least suggest going to the last available 3.x which was v3.20.0.

Does Submit-Renewal guarantee reuse of $order.PfxPass, or are there edge cases where it may be ignored?

As previously mentioned, modifying a copy of $order is not guaranteed to work. PowerShell scoping rules come into play. The supported method is to use one of the functions with a -PfxPass or -PfxPassSecure parameter to set the order details.

Is there any roadmap or support for:
Passing PfxPass directly to Submit-Renewal

No. Just use Set-PAOrder before you call Submit-Renewal

Enforcing secure defaults (non-empty password, non-exportable keys)

Non-empty password has already been a default for a long time. Upgrade. Non-exportable keys by default is also unlikely to change. But even if it did, it would be a breaking change and require a major version upgrade.

[ariesabdeali]

Thank you for your quick response and earlier clarification.
We would like to confirm if our current approach using Posh-ACME is correct and secure.

Our current setup:

• During initial certificate creation, we use New-PACertificate with a custom secure PFX password (-PfxPassSecure).
• We run a scheduled PowerShell script twice daily.
• The script uses Submit-Renewal for renewal and Install-PACertificate for IIS binding.
• We do not pass the PFX password again during renewal.

Clarification on PFX password and renewal

1. Is this approach correct, where the PFX password is set only once during initial creation and reused automatically during renewal?
2. If we change the PFX password during each renewal, could this cause any issues with:

•      Windows Certificate Store updates
  

•      IIS binding updates
  

•      Certificate replacement behavior
  

3. From a best practice perspective, do you recommend:

•      Keeping the same PFX password across renewals, or
  

•      Rotating/changing the password for each renewal?
  

Security audit questions

4. Backup (.bak) files handling
   We noticed that .bak files are created under the Posh-ACME working directory, which may contain previous certificate or key data.

• Is there any built-in option to disable creation of these .bak files?
• Or should we handle cleanup of these files separately after issuance/renewal?

5. Old certificate / PFX retention
   Does the module automatically clean up older certificate files (PFX/PEM), or should we implement our own cleanup/retention policy?

Post-renewal validation
6. After Submit-Renewal, does the module perform any validation such as:

• Certificate chain validation
• Trust verification
• Expiry/validity checks
  Or should we implement our own validation logic?

7. From a best-practice perspective, do you recommend validating the following after renewal and installation:

• Certificate chain completeness
• Thumbprint update
• Successful IIS binding

8. We observed that Submit-Renewal is being called without specifying a domain or order explicitly.
   As per our understanding, this may rely on the currently active order in the profile.
   current :- $cert = Submit-Renewal

• Is there a risk of renewing the wrong certificate if multiple orders exist in the same account/profile?
• Would you recommend explicitly calling renewal like below for safer operation?

Get-PAOrder $certName | Submit-Renewal

9. We understand that the Posh-ACME profile directory stores sensitive data such as:

• PFX files

• ACME account private key (account.key)
  We would like guidance on securing this directory:

• Are there any recommended built-in methods to secure the profile directory?

• Do you recommend restricting access using PowerShell (ACL changes)?

• Is there any supported approach to enforce permissions using Group Policy (GPO)?
  We want to ensure only the service account has access to this directory.

Thank you in advance.

[rmbolger]

I gotta be honest here, @ariesabdeali. I feel like you (and your company) are exceeding the reasonable limits of my free time with all of these questions. I am not a consulting company that you're paying to provide advice on Windows security and certificate automation. Maintaining this module is a hobby for me and I don't make any money from it aside from a few generous users who sponsor me via the Github sponsors program which allows me to keep a few active accounts on various DNS providers to maintain support for key DNS plugins.

Respectfully, I'm going to stick to answering specific questions about module functionality. If you need additional help with general Windows security questions and best practices, you should hire someone to help you with that.

Is this approach correct, where the PFX password is set only once during initial creation and reused automatically during renewal?

Yes. That is the intended workflow.

If we change the PFX password during each renewal, could this cause any issues with:
Windows Certificate Store updates
IIS binding updates
Certificate replacement behavior

No. Once a cert is imported into the Windows cert store, it ceases to have any link to the PFX file on disk. PFX is just an archive format like a zip file. Changing the PFX password via module functions also re-generates the current PFX file on disk (if there is one) with the new password before you even start a renewal.

Is there any built-in option to disable creation of these .bak files?

No. But feel free to delete them whenever you like. They only exist to provide a rollback option for users.

Does the module automatically clean up older certificate files (PFX/PEM), or should we implement our own cleanup/retention policy?

Yes in as much as when the current cert files are backed up to the .bak files they overwrite the old .bak files. Nothing in the core module removes any certs from the Windows cert store. But there is a companion module, Posh-ACME.Deploy that contains cert deployment functions which include a -RemoveOldCert switch.

After Submit-Renewal, does the module perform any validation such as:
Certificate chain validation
Trust verification
Expiry/validity checks

No. The module accepts the cert and chain provided by the CA as-is.

We observed that Submit-Renewal is being called without specifying a domain or order explicitly.
As per our understanding, this may rely on the currently active order in the profile.
Is there a risk of renewing the wrong certificate if multiple orders exist in the same account/profile?

Yes, Submit-Renewal without any additional arguments will check if the currently active order has reached the suggested renewal window and renew it. It will not renew any cert that hasn't reached the suggested renewal window unless the -Force switch is used. The only risk of renewing the "wrong" certificate is if another process or user changes the active order in the config.

Would you recommend explicitly calling renewal like below for safer operation?
Get-PAOrder $certName | Submit-Renewal

That would work, but it is overly complicated when Submit-Renewal has its own -MainDomain and -Name parameters depending on what value you have in $certName.