Step 5 of 8 · Windows

Windows servers

The service agent is a Windows service. It fetches certificates from the appliance and installs them on the server. You connect the server with one line, copied from the appliance.

Before you start

You need:

A server running Windows Server 2016 or later.
An administrator login on the server.
The server can reach the appliance directly over HTTPS, or reach sslbrain.com and cloud.sslbrain.com on port 443. If it is somewhere other than the appliance, see Servers outside your network.
If App Control (WDAC), AppLocker, antivirus or EDR restricts software on the server, prepare agent and script approval with your security administrator before installation.

Connect the server

Open Servers in sslbrain and click Install service agent. The button is at the top of the page, and below the list while the appliance is the only server.

Click Copy under Windows (recommended). It is the first line on the page and looks like this:

msiexec /i https://<appliance>/agent.msi /qb INSTALLCODE=<code> DESTINATIONS="https://<appliance>,cloud"

Open a command prompt or PowerShell as administrator on the server, paste the line and press Enter.

The server fetches the newest agent from the appliance, installs it and connects directly to the appliance with the code. /qb shows the installer’s progress window, and if something goes wrong, the error is on the screen. After a minute or two the server is listed under Servers.

The code and the appliance’s address are already in the line. If you open the page from Servers and no install code is open, the appliance creates one without a last day and records it in the audit log. The same code works on as many servers as you like, until you close it under Install codes further down the page. That is also where you create more codes and give a code a last day. If you close the last open code, the page shows no command until you click Make a new code and show the command.

The line has sslbrain Cloud after the appliance as fail-over while Allow agent communication through Cloud is on under Settings › Security and the appliance is connected to sslbrain Cloud. Otherwise only the appliance’s address is there:

msiexec /i https://<appliance>/agent.msi /qb INSTALLCODE=<code> DESTINATIONS=https://<appliance>

Keep the quotation marks around the list with cloud, so the list reaches msiexec as one value from both the command prompt and PowerShell. Without cloud in the list the agent does not use sslbrain Cloud. To give it Cloud later, click Turn Cloud on again for this agent on the server’s page under Servers.

If the appliance uses its own self-signed certificate, Windows does not trust it, and the line fetches the agent from sslbrain.com instead. The agent then connects directly to the appliance, and DESTINATIONS follows the same rule as above:

msiexec /i https://sslbrain.com/agent.msi /qb INSTALLCODE=<code> DESTINATIONS="https://<appliance>,cloud"

The server then needs to reach sslbrain.com on port 443. Give the appliance a real certificate, and the agent is fetched from the appliance itself (Free name).

Connect through sslbrain Cloud

If the server cannot reach the appliance directly, open The server cannot reach the appliance directly on the page and use the line there:

msiexec /i https://sslbrain.com/agent.msi /qb INSTALLCODE=<code>

The agent finds the appliance through sslbrain Cloud with the code. Cloud can neither read nor change what the appliance and the agent send each other (Servers outside your network).

The section is there only while Allow agent communication through Cloud is on under Settings › Security.
Every licence can connect through Cloud. If the licence does not cover a Cloud connection, the server is listed as Blocked under Servers and gets no work until it is switched to a direct connection or the licence is upgraded (Servers outside your network).

Several servers at once

The first line works on each server on its own, also from a script or a software deployment tool. If the servers should not fetch the agent themselves, or have no internet access, open Several servers, GPO or no internet, click Download MSI, hand out sslbrain-agent.msi, and run the line with the local file in the folder that holds it. The line has the same DESTINATIONS as the first line. It has /qn and shows no windows, because a startup script or a deployment tool runs it with nobody watching the screen:

msiexec /i sslbrain-agent.msi /qn INSTALLCODE=<code> DESTINATIONS="https://<appliance>,cloud"

With a GPO: Roll out the service agent to many Windows servers.

The agent for Windows on ARM64 is under Other editions as sslbrain.com/agent-arm64.zip.

The server appears

A server that connects with the code is approved and listed under Servers. sslbrain finds the services on the server that use certificates and lists them under Services.

A server that looks like a reinstall of one already connected waits under Servers waiting for approval on the Install service agent page instead.

Compare Agent key with the key the agent wrote to its log on the server (Log files).
Click Approve.

The Type column under Servers shows whether the server is connected Local or Through Cloud.

Next step

Prove that the domain is yours, so sslbrain can get certificates for it: Prove the domain is yours.

If it fails

The line seems to do nothing: in PowerShell the prompt returns at once while the installation carries on in its own window. Wait a few minutes and check the service with Get-Service sslbrainagent. Add /l*v C:\Windows\Temp\sslbrain-agent.log to the line for a log of the installation.
The installation stops with SSLBrain Agent needs its appliance or Angiv CODE eller SERVER. Specify CODE or SERVER: the line lacks the code. Copy it again from Install service agent.
msiexec cannot open the address: the server cannot reach the address in the line, the appliance or sslbrain.com. Use Download MSI and the local line under Several servers, GPO or no internet, or the line under The server cannot reach the appliance directly.
The server is listed as Blocked: it is connected through sslbrain Cloud, and the licence does not cover it. Open the server and click Switch to direct (Servers outside your network).
The code is listed as Closed or Expired: open Install service agent from Servers. The page shows an open code or creates a new one. If it says No install code is open, click Make a new code and show the command.
The server does not appear: The agent does not check in.
The certificate is not installed: The installation fails.

Log files

What	Where
The agent’s log, one file per day	`C:\ProgramData\sslbrain\logs\agent-<date>.log`
Updates of the agent	`C:\ProgramData\sslbrain\logs\update-msiexec-<version>-<time>.log`

The service is called sslbrainagent, and “sslbrain agent” in the list of services. Status and the last lines of the log:

Get-Service sslbrainagent
Get-Content "C:\ProgramData\sslbrain\logs\agent-$(Get-Date -Format yyyy-MM-dd).log" -Tail 50

A server that had the agent before version 1.4.0 keeps the folder and the registry key with the capital letters they had then. Windows reads them as the same names.

The registry

The agent’s settings are in HKLM\SOFTWARE\sslbrain. Values under HKLM\SOFTWARE\Policies\sslbrain take precedence, so they can be set with a GPO. Restart the service after a change with Restart-Service sslbrainagent.

All the values are listed under Settings in the registry.

Approve the agent in Windows security policies

App Control for Business is the current name for Windows Defender Application Control (WDAC). These are the same technology. AppLocker is a separate control; antivirus and EDR can make additional decisions about files, scripts and behaviour.

This section lets your security administrator prepare narrowly scoped rules. You need authority to manage the relevant policies, the actual downloaded MSI and installed files, a reference server with the same Windows edition/build and security settings, and Windows policy tools (ConfigCI or AppLocker). Keep your existing Windows baseline, a policy backup and a recovery procedure. Feature availability varies by OS version. The examples below generate local candidate XML and inspect files; they do not apply a policy. Test candidates through your organisation’s normal audit/pilot and enforcement process before wider use. Audit mode alone does not prove scripts will work in enforcement mode.

Identify the actual files

On 9-10-2026 we inspected the public x64 agent.msi, version 1.4.2. Its MSI tables install C:\Program Files\sslbrain\sslbrainagent.exe as sslbrainagent, display name “sslbrain agent”, running as LocalSystem. Check PathName and StartName on your server; an older installation or a different drive may differ.

Both the MSI and its extracted EXE contain an Authenticode signature whose leaf certificate has CN=FairSSL A/S, O=FairSSL A/S, C=DK, organisation registration number 33075782, and issuer DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1. The leaf certificate’s SHA-256 fingerprint is 8854997a1e37006307ed8f985df5142021f9edfd58422d455078dd5b7ad45dab. This is an observed identity, not a policy string to copy. Linux osslsigncode verified both signatures, chains and timestamps; Windows Get-AuthenticodeSignature status was not verified. Verify your own files on Windows, including certificate trust and revocation access. Do not approve a file whose signature is missing or invalid without investigating it.

Save the downloaded installer as sslbrain-agent.msi in your current directory, then inspect it and the installed EXE:

$exe = 'C:\Program Files\sslbrain\sslbrainagent.exe'
Get-CimInstance Win32_Service -Filter "Name='sslbrainagent'" |
    Select-Object Name, StartName, PathName
$files = @('.\sslbrain-agent.msi', $exe)
foreach ($file in $files) {
    $s = Get-AuthenticodeSignature -LiteralPath $file
    [pscustomobject]@{
        File = $file; Status = $s.Status; Detail = $s.StatusMessage
        Subject = $s.SignerCertificate.Subject
        Issuer = $s.SignerCertificate.Issuer
        Thumbprint = $s.SignerCertificate.Thumbprint
    }
}
(Get-Item -LiteralPath $exe).VersionInfo |
    Select-Object ProductName, OriginalFilename, FileVersion
Get-FileHash -LiteralPath $exe -Algorithm SHA256

The inspected EXE reports product sslbrain agent, OriginalFilename=SslBrainAgent.dll and file version 1.4.2.0. The original filename is a signed resource attribute, despite the file on disk ending in .exe. The SHA-256 of the complete EXE is ccee898b41b98af4a1382426edb013f0be4bc8e084a84dfdb0d7bcb2698b131c; use it only to identify this inspected build. App Control hash rules use Authenticode/PE image hashes, which differ from Get-FileHash; let the policy tools calculate them. The certificate fingerprint above is SHA-256, whereas the displayed certificate Thumbprint is normally SHA-1. The inspected leaf’s SHA-1 thumbprint is C487B12B87298E601D5CEEEB7239829AC795008A.

The MSI carries a single EXE, not separate application DLLs. Its bundle contains managed assemblies including SslBrainAgent.dll and System.Management.Automation.dll, and five native DLLs: getfilesiginforedist.dll, microsoft.management.infrastructure.native.unmanaged.dll, PowerShell.Core.Instrumentation.dll, pwrshplugin.dll and sni.dll. Those native files contain Microsoft signatures; their Windows trust status and which files load during a particular task were not verified. Linux verification could not build their issuer chains. Check the actual loaded/extracted DLLs individually rather than treating them as FairSSL-signed files. Policies using .NET Dynamic Code Security also need separate validation of managed assemblies.

Purpose	Default location in the inspected implementation
Downloaded task and extracted files	`C:\ProgramData\sslbrain\work\<task-id>\package.tar` and `extracted\` below the same task directory
Verified copy for executable stages and PowerShell fallback	`.verified-<random>.ps1` or `.exe` beside the original file in the task extraction directory
Tool path defined in source, not invoked in 1.4.2	`C:\ProgramData\sslbrain\tools\<tool-name>\`
Hook path defined in source, not invoked in 1.4.2	`C:\ProgramData\sslbrain\hooks\`
Update download and application	`C:\ProgramData\sslbrain\update\staging\`, then `apply\`; copied updater EXE: `apply\SslBrainAgent.exe`
Update MSI files and rollback copies	`update\apply\target\`, `update\apply\previous\` and `update\installed\<version>\` below the data directory
Agent and update logs	`C:\ProgramData\sslbrain\logs\` (Log files)

DataPath can change the task/update data locations. ToolsPath configures the tool path defined in source; that tool-download code and the hook assembler are not called in 1.4.2. The .NET single-file host extracts native libraries below DOTNET_BUNDLE_EXTRACT_BASE_DIR if configured, otherwise below the service process’s %TEMP%\.net. The final directory depends on the service environment and bundle; it was not observed on Windows. Find it from your process/module inventory or a block event. These paths identify files to investigate; they are not recommendations to allow or exclude whole writable directories.

App Control and AppLocker rules

Inspect signatures and file metadata above. Copy only the verified reference EXE and any separately verified dependency files into reference-agent in your working directory. Keep unrelated downloads out of it.
For App Control, generate FilePublisher candidates from those real files:
Terminal window
```
New-CIPolicy -ScanPath '.\reference-agent' -FilePath '.\agent-candidate.xml' `
    -Level FilePublisher -Fallback Hash -UserPEs
```
Review the XML signer, file attribute and minimum version for each rule. For this EXE the default file attribute is SslBrainAgent.dll, not its disk name. Keep the publisher and the individual file identity and an appropriate minimum version; this can follow newer signed versions while that identity and issuing chain remain the same. A certificate/chain or file-identity change needs review. Inspect every Hash fallback and renew those rules for each changed binary. Do not replace missing file metadata with a CA-only or all-FairSSL rule. Integrate approved rules with your existing baseline using your policy tooling; this scan is not a complete deployment policy. Preserve your baseline’s script enforcement and review the generated policy options; do not deploy the scan XML directly. Handle the MSI separately in the policy tool’s installer rules, from the actual signed MSI. Never grant blanket trust to DigiCert or another CA.
For AppLocker, use Create New Rule → Publisher → Browse in the relevant EXE, MSI and, if enabled, DLL collection. Select the real reference file. Retain publisher, product and binary name, then choose the tested minimum version and later versions. Review any wildcard fields generated by tools. Use the service’s actual account for EXE/DLL rules and the installer deployment account for MSI rules. Automatic updates run the copied updater and msiexec.exe as SYSTEM, so MSI rules must also cover S-1-5-18 when updates are used. Check that the existing Windows baseline allows the required system msiexec.exe and schtasks.exe. Confirm whether your AppLocker configuration enforces rules for services, that Application Identity is running, and which collections are enforced. For the default LocalSystem EXE, the following generates a candidate and evaluates that file:
Terminal window
```
Get-AppLockerFileInformation -Path $exe |
    New-AppLockerPolicy -RuleType Publisher -User 'S-1-5-18' -Xml |
    Set-Content '.\agent-applocker-candidate.xml'
Test-AppLockerPolicy -XmlPolicy '.\agent-applocker-candidate.xml' `
    -Path $exe -User 'S-1-5-18'
```
Test-AppLockerPolicy checks file-rule matching; it does not test PowerShell behaviour, effective GPO merging or service execution. Inspect the effective policy and test the real service and required tasks on the reference server. When the copied updater exists, also evaluate C:\ProgramData\sslbrain\update\apply\SslBrainAgent.exe with Test-AppLockerPolicy for S-1-5-18; a rule based only on the install path will not cover it. If a dependency lacks a usable publisher identity, use a reviewed per-file hash candidate and update it with the file. Do not allow all of ProgramData, Temp, the work directory or all of powershell.exe as a way to approve deployment scripts.

Deployment scripts are a separate approval

An executable task stage runs as a separate process from its .verified-<random>.exe copy in the task extraction directory. It needs its own narrow publisher/FilePublisher or per-file hash rule generated from that actual verified executable and its dependencies. The service EXE rule and sslbrain package signature do not approve it in Windows. Use file identity rather than allowing that writable directory or random path.

In the inspected 1.4.2 implementation, the embedded PowerShell SDK creates a runspace and calls AddScript(scriptContent) on script text. It does not run an Authenticode-approved .ps1 file by path in that route. A FilePublisher rule for the service EXE, a package signature or an Authenticode signature on the original script therefore does not demonstrate that this in-memory script receives FullLanguage approval under App Control.

If the embedded host is unavailable or fails to initialise, the fallback launches powershell.exe with -ExecutionPolicy Bypass and an encoded bootstrap. It passes input through stdin and invokes a temporary verified script file by path. Bypass is a process execution-policy choice; it cannot override a Group Policy execution policy and does not grant App Control or AppLocker permission. The bootstrap’s .NET calls and the scripts can encounter language restrictions. The fallback is not an approval workaround. A script runtime error, including a language-restriction error after execution begins, does not automatically trigger fallback.

A GPO setting Allow only signed scripts means AllSigned for script files. Execution policy is a safety feature, not an application-control security boundary: MachinePolicy/UserPolicy take precedence over process settings, but AllSigned alone does not prove the AddScript text was checked as a signed file. Under App Control, PowerShell behaviour depends on the OS/API and PowerShell version: unapproved code can be constrained or blocked. The embedded SDK is PowerShell 7.4.7; the fallback is Windows PowerShell. Review both PowerShell Core and Windows PowerShell GPO settings: they are managed separately, with a documented Use Windows PowerShell Policy setting option for Core. Under an effective GPO AllSigned, the fallback script file needs its own valid Authenticode signature and publisher trust; a detached package signature does not supply those. Do not assume that results in an administrator’s interactive shell describe the service’s runspace.

sslbrain’s detached package signatures and ScriptPolicy govern package integrity and authorisation inside sslbrain. They are separate from Windows Authenticode and Windows policy. Keep package/download/update signature checks enabled: version 1.4.2 verifies its update catalogue and release manifest against compiled production anchors and checks the MSI against signed sizes/hashes. This is not a claim that the updater performs Windows Authenticode validation.

You can prepare binary/installer rules now. There is no verified recipe here for giving the current in-memory deployment route FullLanguage approval under a restrictive script policy. Validate the actual module’s discovery, deployment and verification under your policy before relying on it; a running service or successful check-in is insufficient. If your rules require every deployment to run as a policy-approved signed script file, this route needs an implementation change. Keep that requirement and the failing operation for support; do not weaken application control, disable script enforcement or change execution policy to make it pass.

Antivirus and EDR

Keep scanning, AMSI and behavioural monitoring enabled. Review the actual vendor alert, file hash, signature, process tree and blocked operation. Prefer a scoped approval for the identified file and affected device group, with a review/expiry date, following your vendor’s product documentation. Reassess on update. An executable approval does not automatically approve child processes, scripts, certificate-store changes or service restarts. There is no guarantee of compatibility with every antivirus/EDR policy.

For example, Microsoft Defender for Endpoint supports file-hash Allow indicators and certificate indicators. A certificate indicator covers more than one file, so a per-file indicator is narrower when sufficient. These features need the documented licence, permissions, Defender configuration and device scope; use the vendor instructions linked below. Defender Antivirus scanning exclusions are not equivalent to EDR approval. Do not exclude the entire agent, work, update or .NET extraction directories, or create broad process exclusions. Other vendors need their own documented approval procedure.

Network approval is separate: allow the configured appliance’s HTTPS host/port (normally 443), name resolution and, when Cloud is used, cloud.sslbrain.com:443; installation from the public download needs sslbrain.com:443. Updates in the inspected source download from the configured appliance over HTTPS. For an agent whose saved destination list contains only Cloud entries, release 1.4.2 refuses update staging because that Cloud update source is not implemented; do not assume Cloud communication also provides this update path. Signature trust/revocation checks may need access to the certificate authorities’ services under your network policy. No inbound agent port is needed. See How the agent reaches the appliance for your connection mode.

Diagnose a block and record what was tested

Compare the same timestamp and file/process across the agent log, MSI log and these Windows channels:

Event Viewer channel	What to check
`Microsoft-Windows-CodeIntegrity/Operational`	3076: audit would-block; 3077: enforcement block; correlate 3089 signature details by ActivityID. 3099 records a loaded policy.
`Microsoft-Windows-AppLocker/EXE and DLL`	AppLocker 8003: audit would-block; 8004: blocked. Check the file, rule and user SID.
`Microsoft-Windows-AppLocker/MSI and Script`	AppLocker 8006/8007: audit/block. App Control 8028/8029: audit/enforcement script-host decision; 8038: correlated signer details. The host decides whether to constrain or block. Microsoft documents this channel as absent on Server Core.
`Microsoft-Windows-PowerShell/Operational` or `PowerShellCore/Operational`	Host errors and, when enabled, script-block events such as 4104. PowerShell Core needs its event provider registered before it can write these events. Correlate with embedded-host/fallback messages in the agent log.
`Microsoft-Windows-Windows Defender/Operational` and the EDR console	Detection, quarantine, ASR or other vendor action; use the actual alert’s remediation guidance.

Get-ExecutionPolicy -List
Get-AppLockerPolicy -Effective -Xml
Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-CodeIntegrity/Operational'
    Id=3076,3077,3089,3099
    StartTime=(Get-Date).AddHours(-1)
} | Select-Object TimeCreated, Id, Message

Run these read-only checks with the relevant administrative permissions. An empty channel or lack of a block event is not proof of approval. Check the effective policy, signature status, service identity, dependency file and exact failing stage. Script-block logs can capture sensitive script/input data; keep diagnostic evidence access-controlled and redact it before sharing.

The artifact inspection and source paths above were checked on 9-10-2026 against release 1.4.2. The Windows security behaviour is documented by Microsoft; the execution and update details come from that release’s implementation. No Windows runtime test under App Control, AppLocker, antivirus or EDR was performed for this guide. Record your OS/build, agent version, policies, vendor settings and the outcome of install, service start, discovery, deployment, verification and update in your pilot.