Windows Server

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, or an LDAP Connection to the domain the server belongs to. See using an LDAP connection for many servers.
For an LDAP Connection: the connection URL must use LDAPS on port 636, because a hardened domain controller rejects a plaintext simple bind on port 389 with strongerAuthRequired. A Gateway must be assigned to the LDAP Connection itself, and that Gateway must reach both the domain controller and the target server.
An Infisical Gateway that can reach the server. Windows delivery always runs through the Gateway. A post-sync command additionally needs the Gateway to be running Infisical CLI v0.43.120 or later.
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: on a Windows (WinRM) Connection it is a property of the connection, and on an LDAP Connection the sync itself carries Enable SSL.

Create a Windows Server sync

Infisical UI
API

In your Application, go to the Certificate Syncs tab and select Create Sync.
Select the Windows Server option.
Configure the Destination:
- Connection: The WinRM Connection used to reach the server, or an LDAP Connection to the server’s domain.
- 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.
Configure the Target Host. This step appears only when the connection is an LDAP Connection, because that connection reaches a whole domain rather than one machine. A Windows (WinRM) Connection carries all of these itself:
- Target Host: The machine this sync delivers to. Servers found in the directory are offered as suggestions, and you can enter a host that isn’t listed. Enter a host name or an IPv4 address. Underscores, ports and IPv6 literals aren’t accepted.
- Port: Leave empty to use 5985, or 5986 when Enable SSL is on. Set a value only if the WinRM listener is on a non-standard port.
- Enable SSL: Connect over HTTPS. When off, HTTP with NTLM message encryption is used and no server certificate is required.
- SSL Certificate: Leave empty to verify against the system trust store, or paste the listener’s certificate to verify a self-signed WinRM HTTPS listener.
- Reject Unauthorized: When on, Infisical only connects if the listener presents a valid, trusted certificate.
With Reject Unauthorized on, the Target Host must match the name on the listener’s certificate. A WinRM HTTPS listener created by winrm quickconfig -transport:https carries the machine name, so target server01.corp.example.com rather than its IP address, otherwise the connection fails on a name mismatch even when the certificate is trusted.
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.
Configure the Commands, or leave them empty:
- Health check: A PowerShell command run on the server before any certificate is written, to confirm the host is ready, for example Get-Service W3SVC | Where-Object Status -ne 'Running' | ForEach-Object { throw "W3SVC is not running" }. A failure stops the sync, so nothing is delivered. See health check.
- Post-sync 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". See post-sync command.
Configure the Details:
- Name: The name of your sync.
- Description: Optional description.
Select which certificates should be synced.
Review and click Create Sync.

To create a Windows Server Certificate Sync, make an API request to the Create Windows Server PKI Sync endpoint.destinationConfig.host is required when connectionId refers to an LDAP Connection, and optional port, sslEnabled, sslRejectUnauthorized and sslCertificate sit alongside it. All five are rejected when connectionId refers to a Windows (WinRM) Connection, because that connection carries them itself.

Sample request

Request

curl --request POST \
--url https://app.infisical.com/api/v1/cert-manager/syncs/windows-server \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data '{
    "name": "my-windows-cert-sync",
    "applicationId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
    "connectionId": "550e8400-e29b-41d4-a716-446655440000",
    "isAutoSyncEnabled": true,
    "certificateIds": ["550e8400-e29b-41d4-a716-446655440000"],
    "credentials": {
        "exportPassword": "a-strong-password"
    },
    "syncOptions": {
        "exportFormat": "pkcs12",
        "canRemoveCertificates": true,
        "certificateNameSchema": "{{commonName}}",
        "healthCheckCommand": "if (-not (Test-Path {{certificateDirectory}})) { throw \"destination folder is missing\" }",
        "postSyncCommand": "Restart-Service -Name W3SVC"
    },
    "destinationConfig": {
        "destinationPath": "C:\\certs",
        "host": "server01.corp.example.com"
    }
}'

Using an LDAP connection for many servers

A Windows (WinRM) Connection stores the target machine’s address alongside its credential, so it reaches exactly one server. Pushing one certificate to fifty servers means fifty connections holding the same credential, and fifty objects to update when that credential is rotated. An LDAP Connection removes that duplication. It’s both the credential and the directory, so one connection serves as many syncs as you have servers. Each sync names its own Target Host, and every sync shares the one credential. When you rotate the service account’s password on the connection, every sync that uses it picks up the new password on its next run with no further action. This works because an Active Directory service account is a single identity. The same username and password that performs the LDAP bind performs the WinRM logon, so no second credential is needed. Infisical derives that logon name rather than asking for it twice. It reads the domain’s NetBIOS name from the directory and signs in as NETBIOS\account, for example CORP\svc-certs. The account part comes from the connection’s bind identity: from the name before the @ when the bind is a user principal name, and read from the directory as the account’s sAMAccountName when the bind is a distinguished name. Grant WinRM rights to that account, not to the connection’s bind string. The Target Host field offers servers read from the directory. The list isn’t closed, because the name a domain controller advertises isn’t always the address you can reach, so you can enter a host that isn’t listed. The value must be a host name or an IPv4 address.

The sync authenticates to the Target Host with the connection’s credential. Application Admins can set it, so give the service account only the access it needs to deliver certificates.

Preparing the service account

The service account needs permission to open a WinRM session on each target server. Add it to the Remote Management Users group on the server:

Add-LocalGroupMember -Group "Remote Management Users" -Member "CORP\svc-certs"

On a domain controller, use Add-ADGroupMember instead. A domain controller has no local groups, and Add-LocalGroupMember reports success while doing nothing, which surfaces later as a 401 at the WinRM handshake.

Add-ADGroupMember -Identity "Remote Management Users" -Members "svc-certs"

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:

PKCS#12
  C:\certs\app.example.com.pfx

PEM (.pem extension)
  C:\certs\app.example.com.pem        certificate
  C:\certs\app.example.com.chain.pem  chain
  C:\certs\app.example.com.key        private key (when included)

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.

Commands

A sync can run two optional commands as PowerShell on the target server:

A health check runs before any certificate is written and gates the delivery, for example if ((Get-Service W3SVC).Status -ne "Running") { throw "W3SVC isn't running" }.
A post-sync command runs after the delivery has finished, so the service that uses the certificate picks up the new file, for example Restart-Service -Name W3SVC.

Set each on the sync’s Commands step. Leaving a field empty means nothing runs, so neither has a separate toggle. Both accept a whole script, so several steps can run in one go: put each on its own line. Both run with $ErrorActionPreference set to Stop, so a failing cmdlet is enough to fail the command.

Your Gateway runs both commands, never Infisical. A WinRM Connection already requires a gateway, so nothing extra is needed here.The Gateway must be running Infisical CLI v0.43.120 or later. An earlier Gateway has no PowerShell run-command endpoint and rejects the request. A command longer than 2048 characters needs v0.43.124 or later, because earlier Gateways cap it at 2048 and reject the sync even though the form accepted the command. Run infisical --version on the Gateway host to check, and see Gateway deployment for how to upgrade.

Available variables

Write a variable where you want this run’s value. Infisical substitutes it before the command is sent to the server, so a command keeps working when the name schema or export format changes.

Variable	Value
`{{certificatePath}}`	Full path of the certificate file this run writes. Single-certificate syncs only
`{{certificateDirectory}}`	The destination directory
`{{certificateFiles}}`	Every path this run writes, one per line
`{{commonName}}`	The certificate’s common name. Single-certificate syncs only
`{{pkcs12Password}}`	The PKCS#12 export password, set only when the export format is PKCS#12

The paths are the same for both commands, but a health check runs before anything is written, so they describe the files the run is about to write rather than files already on the host. Each value is inserted already quoted for the target’s shell, so write {{certificatePath}} rather than "{{certificatePath}}". A variable 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 variable 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 variables 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

Each command is limited to 8192 characters, counted as you write it, before variables are substituted. For anything longer, put the logic in a script file on the server and have the command call that script. Going past 2048 characters requires a Gateway on Infisical CLI v0.43.124 or later. See the Gateway version note above.

Least privilege

Both commands run as the account the WinRM Connection authenticates with, so constraining that account bounds what either can do. Restarting one service doesn’t 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 can’t 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 doesn’t block an administrator credential on a standard sync, so this is a recommendation you enforce with how you configure the connection. Only Application Admins can set either command, so treat that role as access to the target server.

Health check

A sync can only tell you the host wasn’t ready once it has already tried. If the destination folder was renamed or the service that owns the certificate is stopped, you find out from a failed sync, and on a renewal that is the day the certificate was going to expire anyway. A health check moves that discovery earlier. The Gateway runs it on the target server before any certificate is written. If it fails, the sync stops there: no files are delivered, no removals happen, and no post-sync command runs. The same check also runs on its own once a day, so a host that stops being ready between syncs is reported when it happens rather than at the next renewal. Write a check that answers a question rather than one that changes something. Testing that the folder exists or that a service is running is a good check. Creating the folder or starting the service is work for the post-sync command. The check runs on the target server, not on Infisical, and gates everything after it:

Open the sync's Commands step

Edit the sync and select Commands.

Write the check

Use throw "reason" when you want to say why the host isn’t ready:

if (-not (Test-Path {{certificateDirectory}})) { throw "destination folder is missing" }
if ((Get-Service W3SVC).Status -ne "Running") { throw "W3SVC is not running" }

To check every certificate the run would write instead of one, split {{certificateFiles}} on newlines and loop over it:

{{certificateFiles}} -split "`n" | ForEach-Object { if (-not (Test-Path (Split-Path $_ -Parent))) { throw "missing folder for $_" } }

Test it, then save the sync

Test check runs the check against the host straight away, so you can see the result without waiting for a sync. It resolves variables against the certificates linked to the sync, so it works once at least one is selected and tells you if none is. {{pkcs12Password}} is the exception: the export password only exists once a saved sync delivers a certificate, so a test always rejects it.Save the sync once the check passes. On a real run, a failing check fails the sync without delivering anything, and the reason appears as the sync’s last error.

Post-sync command

Delivering a .pfx to C:\certs doesn’t make IIS or a service use it. A post-sync command is that last step, run for you right after the files land. It runs once per sync run that delivers at least one file. If a sync run doesn’t 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 command runs on the target server, not on Infisical, and only after the whole delivery has finished:

Open the sync's Commands step

Edit the sync and select Commands.

Write the command

Use a variable wherever you need a value from the run. Typing {{ in the command field lists the ones available for this sync, so you can pick one instead of remembering the name:

Import-PfxCertificate -FilePath {{certificatePath}} -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString {{pkcs12Password}} -AsPlainText -Force)

Save and trigger a sync

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

Command FAQ

When exactly does each command run?

The health check runs before anything else in a sync run, in its own WinRM session, before the one Infisical would deliver with. It also runs once a day on its own, whether or not a sync is due.The post-sync command runs 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.

What happens when a command fails?

Either way the sync is marked failed and the reason appears as the sync’s last error. 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.What is left on the host differs. When the health check fails, every certificate in the run is reported as skipped with that same reason, so it is clear nothing reached the host, and files already on the server from an earlier run are left exactly as they are, because the sync never wrote or deleted anything. When the post-sync command fails, the delivered files stay in place, because they were written before the command ran.

How do I fail a command deliberately?

Use throw "reason", in either field. Avoid exit: PowerShell stops the script there before it can report its result, so the command is failed with a message saying the outcome couldn’t be read rather than with your reason.

Can I run several commands, and what happens if one of them fails?

Yes, in either field. 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:

netsh.exe http show sslcert
if ($LASTEXITCODE -ne 0) { throw "netsh failed with $LASTEXITCODE" }
Restart-Service -Name W3SVC

Is there a time limit?

Yes, and it differs by command: 15 seconds for the health check, 30 seconds for the post-sync command. Both are enforced by the Gateway, and running out of time counts as a failure.The check’s limit is deliberately much shorter, because the check gates delivery: a host that cannot answer a readiness question in fifteen seconds is itself the problem worth reporting. Keep the check to a question that is cheap to answer, and give a post-sync command that needs longer than thirty seconds a script on the server that starts the work in the background.On Windows the limit bounds how long Infisical waits, not the host. WinRM gives no way to cancel a command once it has started, so a command that hangs is reported as a timeout and the sync fails, but the command itself keeps running on the server until it finishes. This is the other reason to keep a check to a cheap question rather than real work.

Can a command run twice for the same certificate?

Yes, in some cases. If a sync run doesn’t complete, Infisical may attempt it again, and both commands run as part of that attempt. Prefer commands that are safe to run more than once. A service restart is.

Does a failed health check get retried?

Not within the run. A host that isn’t ready is usually not ready a few seconds later either, so retrying only delays the report. The next sync or the next daily check is the retry.

Where do I see the result of the daily health check?

A failing daily check records the failure and its reason against the sync’s health check, shown as Last Checked on the sync’s page, and notifies the application’s administrators. It doesn’t change the sync’s own status, which continues to report the last delivery. Either way the run is recorded in the sync’s logs with the command and the first part of its output.

Can I use the health check to prepare the host instead of just checking it?

You can, since it’s a free-text command, but prefer not to. A check that also does work runs before every sync and has fifteen seconds to finish, and if it fails halfway you have changed the host and delivered nothing. Keep preparation in the post-sync command, or in a script the check only verifies the result of.

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

Can I import certificates from a Windows server back into Infisical?

No. The Windows Server sync only delivers certificates to the server. It doesn’t 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.

Certificate management

Product reference

Reference

Prerequisites

Create a Windows Server sync

Sample request

Using an LDAP connection for many servers

Preparing the service account

Export formats

How it works

Removing certificates

Commands

Available variables

Length limit

Least privilege

Health check

Post-sync command

Command FAQ

Security

Using synced certificates with IIS centralized certificate store

FAQ

What’s next?

Linux Server

Auto-Renewal

Other Sync Destinations

​Prerequisites

​Create a Windows Server sync

​Sample request

​Using an LDAP connection for many servers

​Preparing the service account

​Export formats

​How it works

​Removing certificates

​Commands

​Available variables

​Length limit

​Least privilege

​Health check

​Post-sync command

​Command FAQ

​Security

​Using synced certificates with IIS centralized certificate store

​FAQ

​What’s next?

Linux Server

Auto-Renewal

Other Sync Destinations

Prerequisites

Create a Windows Server sync

Sample request

Using an LDAP connection for many servers

Preparing the service account

Export formats

How it works

Removing certificates

Commands

Available variables

Length limit

Least privilege

Health check

Post-sync command

Command FAQ

Security

Using synced certificates with IIS centralized certificate store

FAQ

What’s next?