PortBlocker 3.0 checks the SafeConsole server certificate against the Windows trusted root store. A SafeConsole On-Prem server with a self-signed certificate is rejected until the endpoint trusts that certificate. PortBlocker 2.x registered against these servers without complaint, so this shows up during a 2.x to 3.0 upgrade. This article shows how to confirm the problem and the three supported ways to fix it.

Applies To

• PortBlocker 3.0.416 or later for Windows (x64 and Arm64).
• SafeConsole On-Prem whose web certificate is self-signed, or issued by an internal CA the endpoint does not already trust.
• Not affected: SafeConsole Cloud (*.safeconsolecloud.io), and on-prem servers whose certificate comes from a public CA or from an internal CA already deployed to endpoints.
• Not supported: SSL/TLS inspection between the endpoint and SafeConsole. Add the SafeConsole server to the proxy's SSL-inspection bypass list (see Before You Start).

Symptoms

The MSI installs successfully (exit code 0), but the endpoint stays Not Registered and all affected devices are blocked.

• The service log C:\Windows\Temp\datalocker_pb_service.log contains:

WARN auto-register failed; endpoint remains unregistered error=safeconsole error: transport error: error sending request for url (https://<server>/connect)
INFO secure-default policy applied (block_default=true) — endpoint not registered
INFO starting auto-register retry loop interval_secs=600

After a manual or tray registration attempt, the service log's error_chain shows the underlying Windows error:

A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

Cause

PortBlocker 3.0 makes every SafeConsole connection with strict TLS validation:

1. The server certificate must chain to a certificate in the Local Machine Trusted Root Certification Authorities store. The PortBlocker service runs as SYSTEM, so a certificate trusted only in a user's store is not enough.
2. The hostname in the connection URL must match a DNS name in the certificate's Subject Alternative Name (SAN).

A self-signed certificate fails check 1 until it is trusted. Connecting by IP address, or by any name the certificate doesn't list, fails check 2 even when the certificate is trusted.

Before You Start

1. Use a hostname the certificate covers

The /connect URL must use a name listed in the certificate's SAN. For example, if the certificate is issued to WIN-SC01.local.loc, use https://WIN-SC01.local.loc/connect, not https://192.168.1.10/connect. The endpoint must also be able to resolve that name.

2. Exclude the server from SSL inspection

SSL/TLS inspection is not supported. PortBlocker 3.0 authenticates to SafeConsole with a client certificate (mTLS). An inspecting proxy replaces the server certificate and strips the client certificate, so registration and policy updates fail. Add the SafeConsole server (for example WIN-SC01.local.loc) to every proxy's SSL-inspection bypass list.

3. Get the certificate's SHA-256 fingerprint

You need this for Option 1 and Option 3. Get it from the SafeConsole administrator, or read it from the server with PowerShell on any machine that can reach it:

$server = 'WIN-SC01.local.loc'     # hostname from the /connect URL
$tcp = New-Object Net.Sockets.TcpClient($server, 443)
$ssl = New-Object Net.Security.SslStream($tcp.GetStream(), $false, { $true })
$ssl.AuthenticateAsClient($server)
$cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2($ssl.RemoteCertificate)
$sha256 = [Security.Cryptography.SHA256]::Create().ComputeHash($cert.RawData)
"Subject : $($cert.Subject)"
"SAN     : " + ($cert.Extensions | Where-Object { $_.Oid.Value -eq '2.5.29.17' }).Format($false)
"SHA-256 : " + (($sha256 | ForEach-Object { $_.ToString('X2') }) -join ':')
$ssl.Dispose(); $tcp.Close()

Note: Read the fingerprint from a machine whose traffic to the server is not SSL-inspected. Through an inspecting proxy you get the proxy's certificate instead, and pinning it will not work.

Important: Use the SHA-256 fingerprint. The Thumbprint field in the Windows certificate dialog and in Cert:\ is SHA-1, and PortBlocker rejects it with certificate fingerprint mismatch.

Choose a Fix

Option 1: Pin the Certificate at Registration (CLI)

Run from an elevated Command Prompt on the endpoint:

"C:\Program Files\DataLocker\PortBlocker\PortBlocker.exe" register ^
  --connection-token "https://WIN-SC01.local.loc/connect" ^
  --registration-token "<UniqueUserToken>" ^
  --accept-self-signed-cert-fingerprint "<SHA-256 fingerprint>"

--registration-token is required only when your SafeConsole demands a Unique Registration Token. It is the same value as the MSI's USER property.

The command then:

1. Connects to the server and shows the certificate it presents.
2. Compares that certificate's SHA-256 with the value you supplied. On a mismatch it stops and changes nothing.
3. Checks that the certificate covers the hostname in --connection-token. If it doesn't, it stops and changes nothing.
4. Installs the certificate into the Local Machine Trusted Root store.
5. Registers the endpoint and applies policy.

Expected output:

Fetching certificate presented by win-sc01.local.loc:443...

Server certificate:
  Common Name : WIN-SC01.local.loc
  Issuer      : WIN-SC01.local.loc
  Issued      : 2026-10-09T00:13:42Z
  Expires     : 2036-10-06T00:13:42Z
  SHA-256     : 2f0c912b799a2a91b6ac5763305a1668e732a57710dba470032d68562ef898a8
  SAN         : DNS:WIN-SC01.local.loc

Fingerprint matches — installing into the system trust store...
Certificate trusted. Continuing with registration.

Registration is complete

Note: The pin installs the certificate into the machine-wide Trusted Root store. Every application on the endpoint will then trust that certificate, not just PortBlocker. This is the same result as Option 2, scoped to one machine.

If the endpoint is already registered, the command stops with exit code 2 (device is already registered…) and changes nothing else. It's safe to run more than once. Don't unregister unless you want to re-enroll the endpoint, which gives it a new serial.

Option 2: Deploy the Certificate with Group Policy (zero-touch)

If the certificate is already trusted at install time, the standard silent MSI auto-registers with no extra steps.

1. Export the SafeConsole server certificate as a .cer file. Export the public certificate only, without the private key.
2. In Group Policy Management, edit a GPO linked to the endpoints. Go to Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities, choose Import, and select the .cer file.
3. Once the policy has applied (gpupdate /force or a reboot), deploy the MSI as described in PortBlocker MSI Command Line Arguments:

msiexec /i PortBlocker-Setup.msi /qn /norestart ^
 URL="https://WIN-SC01.local.loc/connect" ^
 USER="<UniqueUserToken>" ^
 EULA=1 ^
 /l*v "C:\Windows\Temp\PortBlocker-install.log"

To push the certificate with a script instead of GPO, run this elevated:

certutil -addstore Root "\\server\share\safeconsole.cer"

Option 3: Scripted Install and Pin (SCCM, Intune, PDQ)

There is no MSI property for the certificate fingerprint. Install the MSI without URL/USER, then register with the pin. Run the script as SYSTEM:

# Deploy-PortBlocker.ps1 - run as SYSTEM
$Msi         = '\\server\share\PortBlocker-Setup.msi'
$ConnectUrl  = 'https://WIN-SC01.local.loc/connect'
$UserToken   = '<UniqueUserToken>'
$Fingerprint = '<SHA-256 fingerprint>'
$Log         = 'C:\Windows\Temp\PortBlocker-deploy.log'

# 1. Install without URL/USER so the service does not attempt (and fail) auto-registration
$p = Start-Process msiexec.exe -Wait -PassThru -ArgumentList "/i `"$Msi`" /qn /norestart EULA=1 LAUNCH_CLIENT=0 /l*v `"C:\Windows\Temp\PortBlocker-install.log`""
"msiexec exit $($p.ExitCode)" | Out-File $Log
if ($p.ExitCode -notin 0,3010) { exit $p.ExitCode }

# 2. Pin the self-signed SafeConsole certificate and register
#    (PortBlocker.exe prints its version banner on stderr; capture it rather than treat it as an error)
$pb = Join-Path $env:ProgramFiles 'DataLocker\PortBlocker\PortBlocker.exe'
& $pb register --connection-token $ConnectUrl --registration-token $UserToken --accept-self-signed-cert-fingerprint $Fingerprint 2>&1 |
    ForEach-Object { "$_" } | Out-File $Log -Append
$rc = $LASTEXITCODE
"register exit $rc" | Out-File $Log -Append
exit $rc

Note: Don't set $ErrorActionPreference = 'Stop' around the PortBlocker.exe call. In Windows PowerShell 5.1 that turns the version banner on stderr into a terminating error, and the script exits 1 before registration runs.

Fixing Endpoints That Already Failed to Register

If PortBlocker was deployed with URL/USER and auto-registration failed, choose one:

• Pin it: run the Option 1 command on the endpoint.
• Trust it: deploy the certificate to Trusted Root (Option 2). The endpoint registers on its own at the next retry, within 10 minutes. To register it immediately, run this elevated:

"C:\Program Files\DataLocker\PortBlocker\PortBlocker.exe" service restart

Use PortBlocker.exe service restart to restart the PortBlocker service, not Restart-Service or sc stop/sc start.

Verify

"C:\Program Files\DataLocker\PortBlocker\PortBlocker.exe" status

A registered endpoint shows Status: IN_USE, Server: <your server>, and the SafeConsole server version. To confirm the TLS path, which shows the certificate's SHA-256 and the handshake result, run this elevated:

"C:\Program Files\DataLocker\PortBlocker\PortBlocker.exe" info --mtls-check

With a self-signed certificate, info --mtls-check always adds the warning Issuer isn't a known public CA and doesn't match a known inspection vendor by name. This is expected. Confirm that the SHA-256 it prints matches your server's certificate. If the Issuer it prints is your proxy or security vendor, or the SHA-256 doesn't match the server's certificate, SSL inspection is in the path. Add the server to the proxy's bypass list.

Registration and trust survive service restarts and reboots.

Troubleshooting

For more detail, enable debug logging (PortBlocker.exe logs --enable-debug), reproduce the problem, and send the archive from the tray's support-logs option to DataLocker Support.

Certificate Renewal

PortBlocker trusts the exact certificate it was given. When the SafeConsole certificate is replaced, every endpoint that trusted the old self-signed certificate loses contact on its next policy check:

• The service log shows WARN policy poll: transport failure, backing off, with terminated in a root certificate which is not trusted in error_chain.
• PortBlocker.exe status still shows IN_USE. The endpoint keeps enforcing its last policy and queues events locally, so nothing on the endpoint signals the outage.
• PortBlocker.exe refresh fails with transport error.

Recommended: distribute the new certificate before switching the server over, so endpoints trust both. Use the Option 2 GPO, adding the new certificate alongside the old one.

To fix endpoints already affected (no re-registration needed):

1. Get the new certificate's SHA-256 fingerprint (see Before You Start).
2. Re-run the register command with the new fingerprint, from an elevated prompt:

"C:\Program Files\DataLocker\PortBlocker\PortBlocker.exe" register --connection-token "https://WIN-SC01.local.loc/connect" --accept-self-signed-cert-fingerprint "<NEW SHA-256 fingerprint>"

Expected output: Fingerprint matches — installing into the system trust store... Certificate trusted., followed by device is already registered… (exit code 2). That is the expected result here. The new certificate is now trusted and the endpoint keeps its existing registration and serial.

3. Reconnect immediately with PortBlocker.exe refresh, or wait for the next policy check. Queued events then upload.

Alternatively, push the new certificate to Trusted Root by GPO or certutil -addstore Root. Endpoints reconnect on their own.

The old certificate stays in Trusted Root. Once every endpoint has the new one, remove the old one:

certutil -delstore Root <old certificate SHA-1 thumbprint>