Skip to main content
Deploy certificates from Infisical to a directory on a Windows server over WinRM. Files are written atomically so a reader never sees a partially written certificate or key.
Certificate Syncs are configured per Application. First select which certificates to sync, then configure the Windows Server destination.

Prerequisites

  • A Windows (WinRM) Connection with access to the target server
  • An Infisical Gateway that can reach the server. Windows delivery always runs through the Gateway.
  • The connection user must be able to write to the destination directory
Windows delivery runs on the Gateway, which reaches the host inside your network and runs the WinRM session on Infisical’s behalf. By default it uses HTTP with NTLM message encryption, which lets a certificate travel confidentially over the default WinRM listener without a server certificate. This is the same zero-configuration posture most Windows hosts already ship with. HTTPS is also supported.

Create a Windows Server Sync

  1. In your Application, go to the Certificate Syncs tab and click Create Sync.
  2. Select the Windows Server option.
  3. Configure the Destination:
    • Windows (WinRM) Connection: The WinRM Connection used to reach the server.
    • Destination Directory: The absolute Windows drive path where certificate files are written, for example C:\certs. It is created if it does not exist. The path cannot contain .. segments or consecutive separators.
  4. Configure the Sync Options:
    • Export Format: Choose PKCS#12 to write a single password-protected .pfx bundle, or PEM to write separate certificate, chain, and key files.
    • Certificate File Extension: For PEM, choose .pem (default) or .crt for the certificate and chain files. Both hold the same PEM-encoded content, so pick the one the consuming service expects.
    • Combine Certificate and Chain: For PEM, write the leaf certificate followed by the chain in a single file (a full-chain file) and skip the separate chain file.
    • File Permissions: Optionally grant Windows users or groups (for example a service account) Read, Modify, or Full Control on the delivered files, so you can restrict who reads the private key. Rules are added on top of the destination folder’s inherited permissions.
    • PKCS#12 Password: Required when the export format is PKCS#12. It protects the delivered bundle.
    • Include Private Key: For PEM, controls whether the private key is written alongside the certificate. The sync fails for a certificate whose key is not available, for example one issued from an external CSR.
    • Include Root CA in Certificate Chain: Include the root CA in the delivered chain. Leave it off when the consuming service only needs the intermediates.
    • Enable Removal of Certificates: Delete the delivered files from the server when a certificate is removed from the sync, revoked, or expired.
    • Certificate Name Schema: The base file name, using placeholders such as {{commonName}}, {{certificateId}}, or {{shortCertificateId}}. The export format adds the extension. A schema with no placeholder can be linked to only one certificate.
    • Auto-Sync Enabled: Automatically sync certificates when changes occur.
  5. Configure the Post-Sync Command, or leave it empty:
    • Command: A PowerShell command run on the server after the sync delivers a certificate, so the service that uses it picks up the new file, for example Restart-Service -Name "W3SVC". Post-Sync Commands covers the available placeholders and what happens when the command fails.
  6. Configure the Details:
    • Name: The name of your sync.
    • Description: Optional description.
  7. Select which certificates should be synced.
  8. Review and click Create Sync.

Export Formats

The file extension is set by the export format, not by the name schema. The name schema only provides the base file name. PKCS#12 writes a single password-protected .pfx bundle that contains the certificate, chain, and private key. PEM writes the certificate, chain, and private key (when included) as separate files. The certificate and chain files use the extension you select, either .pem (default) or .crt. For a certificate whose common name is app.example.com, synced to C:\certs with the default {{commonName}} name schema, the delivered files are:

How It Works

When syncing certificates, Infisical asks the Gateway to open a WinRM session to the server and, for each certificate, packages it in the chosen export format and writes the resulting files to the destination directory. Files are written atomically so a reader never sees a partially written certificate or key.

Removing Certificates

When certificate removal is enabled and a certificate is removed from the sync, revoked, or expired, Infisical deletes exactly the files it delivered for that certificate.

Post-Sync Commands

Delivering a .pfx to C:\certs does not make IIS or a service use it. A post-sync command is that last step, run for you right after the files land. Set one command on the sync. The Gateway runs it as PowerShell on the target server, once per sync run that delivers at least one file. Leaving the field empty means nothing runs, so there is no separate toggle. If a sync run does not complete, Infisical may attempt it again and the command runs with it, so prefer a command that is safe to run more than once. The field accepts a whole script, so several steps can run in one go: put each on its own line. Your Gateway runs the command, never Infisical. A WinRM Connection already requires a gateway, so nothing extra is needed here. The command runs on the target server, not on Infisical, and only after the whole delivery has finished:

Setting a Command

1

Open the sync's Post-Sync Command step

Edit the sync and select Post-Sync Command.
2

Write the command

Use a placeholder wherever you need a value from the run:
3

Save and trigger a sync

Save the sync, then trigger it. If the command fails, the reason appears as the sync’s last error.

Available Placeholders

Write a placeholder where you want this run’s value. Infisical replaces it before the command is sent to the server, so the command keeps working when the name schema or export format changes. Each value is inserted already quoted for the target’s shell, so write {{certificatePath}} rather than "{{certificatePath}}". A placeholder that has no value for the run becomes an empty string. Only the names in this table are substituted. Anything else in double braces is left in the command exactly as you wrote it, so a command that calls a tool with its own braces (helm, jq, a Go template) keeps working, and a misspelled placeholder reaches the server as literal text rather than silently turning into nothing.
{{certificatePath}} and {{commonName}} name one specific certificate, so a command that uses either can only be saved on a sync with a single certificate linked. Linking a second certificate to such a sync is rejected, as is adding one of these placeholders to a sync that already has several. To act on every certificate in the run, use {{certificateFiles}}, which lists one path per line:

Length Limit

A command is limited to 2048 characters. Windows caps a command line at 8191 characters and the command is sent to PowerShell encoded, which expands it, so the substituted values count against the same budget. If a long command combined with a sync that delivers many certificates does not fit, the sync reports it clearly. Move the logic into a script file on the server and call that script instead.

Post-Sync Command FAQ

After every file in the run has been delivered and after any removals, so the server is in its final state before the service restarts. A run that delivers nothing runs nothing. Renewals, adding a certificate, and a manual trigger all deliver files, so all three run the command. Removing a certificate from the sync does not.
The sync is marked failed and the reason appears as the sync’s last error. The delivered files stay in place, because they were written before the command ran. A silent failure is reported as a failure: the script stops on the first error, and a native command’s own non-zero exit code is passed through. A command that fails is reported, not repeated.To fail the sync deliberately, use throw "reason". Avoid exit: PowerShell stops the script there before it can report its result, so the sync is failed with a message saying the outcome could not be read rather than with your reason.
Yes, write one per line.A failing cmdlet (Copy-Item, Restart-Service, and so on) stops the script and fails the sync wherever it appears, because the script runs with $ErrorActionPreference set to Stop. A failing external executable is different: only the last statement decides the outcome, so an earlier .exe that fails is not noticed. That is deliberate, because a non-zero exit is routine for some tools (findstr returns 1 when nothing matched, robocopy returns 1 when it copied files) and those should not fail a sync. Check the ones you care about yourself:
Yes, in some cases. If a sync run does not complete, Infisical may attempt it again, and the command runs as part of that attempt. Prefer a command that is safe to run more than once. A service restart is.
Yes, 30 seconds, enforced by the Gateway. A command that needs longer should start the work in the background or live in a script on the server.

Least Privilege

The command runs as the account the WinRM Connection authenticates with, so constraining that account bounds what any command can do. Restarting one service does not need an administrator. Grant the connection account start and stop rights on that single service instead of making it a local administrator. Binding a certificate to an HTTPS port in IIS is the exception: HTTP.sys requires a local administrator and the right cannot be delegated. Because a local administrator can do anything on the host, handle that case with a dedicated, clearly labeled sync rather than raising the privileges of a sync that only needs to deliver files and restart a service. Infisical does not block an administrator credential on a standard sync, so this is a recommendation you enforce with how you configure the connection. Anyone who can edit the sync can change the command, so treat edit access to these syncs as access to the target server.

Security

Delivery runs over the Gateway inside your network, so traffic never crosses the public internet, and the certificate stays encrypted in transit in both connection modes:
  • HTTP mode (default) encrypts the certificate on the wire with NTLM message sealing and needs no server certificate to manage. This is the zero-configuration posture most Windows hosts already ship with.
  • HTTPS mode adds TLS, so the Gateway also verifies the host’s identity and encrypts the full session. Keep certificate verification enabled so it only connects to a host presenting a valid, trusted certificate.

Using Synced Certificates with IIS Centralized Certificate Store

IIS can serve a synced PKCS#12 certificate directly from a local folder through the Centralized Certificate Store (CCS). To wire this up, set the sync to deliver into the CCS folder and make the two sides agree:
  • Export format: PKCS#12. CCS reads .pfx files only.
  • Destination Directory: the folder IIS CCS is configured to read.
  • Certificate Name Schema: use {{commonName}} so each file is named <hostname>.pfx. CCS matches the incoming request hostname to the file name.
  • PKCS#12 Password: must match the private key password configured on the IIS Centralized Certificate Store. IIS uses that one password to open every .pfx in the folder.
These are IIS requirements, configured once on the Windows host (the CCS feature, its store folder, and the store account). Infisical only delivers the .pfx. IIS is responsible for loading and serving it.

FAQ

No. The Windows Server sync only delivers certificates to the server. It does not read certificates back into Infisical.

What’s Next?

Linux Server

Deploy certificates to Linux servers over SSH.

Auto-Renewal

Enable automatic certificate renewal and syncing.

Other Sync Destinations

View all supported sync destinations.