Resolving WinCC V19 Upd3 Sia.exe Signature Error on Server 2022

David Krause10 min read
SiemensTroubleshootingWinCC
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

1. Problem Overview

When installing SIMATIC WinCC Runtime Professional V19 Update 3 on Windows Server 2022 virtual machines in an air-gapped (no Internet) environment, the installer may abort immediately with the message:

The file Sia.exe does not have a valid signature. Installation cannot be continued.

Reference: Siemens Industry Online Support.

The error blocks the entire setup of the WinCC Runtime package even when earlier V19 base installs (WinCC Runtime Professional V19 and SIMATIC NET PC Software V19) succeed on the same machine. The conflict is signature verification performed by Sia.exe (Siemens Setup Installer Application) against the local Windows certificate trust chain. The Sia.exe bootstrapper is launched by Start.exe from the WinCC/PCS 7 DVD or downloaded Update archive, and it performs Authenticode signature verification before any other install step. A failed signature check therefore halts the setup before component deployment starts.

2. Affected Environment

Component Value
Product SIMATIC WinCC Runtime Professional V19 Update 3
OS Windows Server 2022 (Standard / Datacenter)
Topology 6 isolated VMs on shared ESXi host
Network access None (air-gapped)
Co-installs confirmed working WinCC Runtime Professional V19 (base), SIMATIC NET PC Software V19
Installer that fails Sia.exe (Siemens Setup Installer Application)
A successful base V19 install does NOT prove the V19 Update 3 installer is intact; the Update ships as a separately signed payload and must be verified independently.

3. Root Cause Analysis

The signature verification failure has three independent root causes that produce the same error. All three must be ruled out before the install will succeed.

3.1 Incomplete or Corrupted Update File

The Sia.exe payload inside the Update 3 archive is Authenticode-signed by Siemens AG. If any byte of Sia.exe, its catalog file (.cat), or the surrounding cabinet files is altered, the Authenticode hash mismatches and the signature is reported as invalid. Common corruption sources include:

  • Interrupted HTTP/HTTPS download to a partially-filled browser cache.
  • Antivirus or EDR product quarantining the file mid-transfer.
  • Copy via a network share that loses SMB credits or runs over a flaky link.
  • Proxy / web-filter content inspection rewriting the binary stream.

3.2 Installation from a Network Path

Running Start.exe directly from a mapped network drive (e.g., \\fileserver\share\WinCC_V19_Upd3) is unsupported. Even when the share is local to the VM (e.g., on the same ESXi host), the SMB-attributed NTFS alternate data stream (Zone.Identifier) can flag the binary as internet-mark-of-the-web, which strips the signature trust context. Always stage to C:\Install\... or another local NTFS path.

3.3 Outdated Windows Root Certificate Store

Authenticode trusts are anchored against the local Trusted Root Certification Authorities and Intermediate Certification Authorities stores. Windows normally refreshes these automatically via the Microsoft Automatic Root Certificate Update mechanism (the MicrosoftRootCertificateAuthority2011 program and CTL updates). On isolated systems, this refresh never occurs. If the relevant cross-certificate or root (e.g., Siemens Issuing CA chained under Symantec / DigiCert / Siemens Root) is missing, Sia.exe is signed by a publisher whose chain cannot be built, and Windows reports the signature as invalid.

Reference: Microsoft Trusted Root Certificate Program.

4. Pre-Installation Diagnostic Checklist

Run the following checks on the target VM before invoking Start.exe. Record results so the failure can be triaged in five minutes instead of five hours.

  1. Confirm the OS build: winver must report Windows Server 2022 (build 20348 or later cumulative). WinCC V19 is qualified for this platform per the TIA Portal V19 Readme.
  2. Confirm the file lives on a local NTFS volume: fsutil fsinfo volumeinfo C:\ must show NTFS, not ReFS.
  3. Confirm Microsoft.Update.Session is reachable or confirm the local root store is up-to-date (see Section 8).
  4. Confirm no third-party AV is intercepting Sia.exe: temporarily add C:\Install\WinCC_V19_Upd3 to the AV exclusion list.
  5. Confirm the current user has Administrator rights and UAC is honored (do not run as SYSTEM).
  6. Confirm Group Policy does not block Turn off Automatic Root Certificates Update at Computer Configuration > Administrative Templates > System > Internet Communication Management > Internet Communication settings.

5. Step-by-Step Resolution

5.1 Download the Update from a Trusted Source

Re-download SIMATIC WinCC Runtime Professional V19 Update 3 from the Siemens Online Support entry:

  1. Open Siemens Industry Online Support on a workstation with Internet access.
  2. Search for the exact article title "SIMATIC WinCC Runtime Professional V19 Update 3" (entry ID varies by region; the file name pattern is SIMATIC_WinCC_Runtime_Professional_V19_Upd3.zip).
  3. Disable any web-filter, antivirus on-access scan, and proxy SSL inspection on the workstation before downloading.
  4. Save directly to C:\Downloads\WinCC_V19_Upd3 (local disk only).

5.2 Verify File Integrity with SHA-256

Open PowerShell on the download workstation:

Get-FileHash -Path "C:\Downloads\WinCC_V19_Upd3\SIMATIC_WinCC_Runtime_Professional_V19_Upd3.zip" -Algorithm SHA256

Compare the resulting hash with the SHA-256 published on the Siemens download page (Siemens publishes hashes for each TIA Portal / WinCC package). If the values differ, delete the file and re-download.

After extraction, also hash the inner Sia.exe:

Get-FileHash -Path "C:\Downloads\WinCC_V19_Upd3\Setup\Sia.exe" -Algorithm SHA256

Any mismatch at this step proves the archive was tampered with or partially downloaded.

5.3 Stage to a Local NTFS Path on the Target VM

Do not run the install from a network share. Use one of the following transports, in order of preference:

  1. Direct copy from the workstation to the VM console: paste via VMware Remote Console (VMRC) or RDP file-copy. This is the method that resolved the reported incident.
  2. Robocopy from a trusted file server: robocopy \\fileserver\share\WinCC_V19_Upd3 C:\Install\WinCC_V19_Upd3 /MIR /Z /NP followed by a hash check at both ends.
  3. Mount the ISO directly via the VM's virtual DVD (preferred when the package is supplied as .iso): Get-VM <name> | Add-VMDvdDrive -Path D:\WinCC_V19_Upd3.iso.
Verify the copy by recomputing SHA-256 on the VM after the transfer. Even brief SMB drops can corrupt a 4-7 GB install archive.

5.4 Update the Local Root Certificate Store

For air-gapped systems, Windows cannot fetch the CTL (Certificate Trust List) automatically. Pre-stage the root and intermediate certificates required by Siemens code-signing:

  1. On an Internet-connected workstation running the same OS build, export Trusted Root Certification Authorities and Intermediate Certification Authorities via certlm.msc > All Tasks > Export.
  2. Copy the resulting .sst / .pfx file to the isolated VM.
  3. On the isolated VM, open certlm.msc as Administrator and use All Tasks > Import against the relevant store.

Microsoft also ships a frozen offline update mechanism via rootsupd.exe, distributed monthly as part of the standalone root update package. Extract rootsupd.exe and execute it with the /u switch to update the offline store without network access.

Reference: Microsoft Trusted Root Certificate Program and KB 293781 - Root Certificate Update Procedure.

5.5 Verify Group Policy

Open gpresult /h C:\gp.html and confirm the Turn off Automatic Root Certificates Update setting is Not Configured or Disabled. If GPO forces it to Enabled, you must either:

  • Override locally via gpedit.msc on the VM (skips GPO temporarily), or
  • Push an updated GPO that disables the setting, then run gpupdate /force and certutil -pulse to force CTL refresh.

5.6 Launch the Installer Locally

  1. Open an elevated Command Prompt on the VM.
  2. Change directory: cd C:\Install\WinCC_V19_Upd3\Setup
  3. Run: Start.exe
  4. If Start.exe still invokes an unsigned Sia.exe, launch directly with Sia.exe /silent /norestart and watch the setup log in %TEMP%\Siemens\SIA\Setup.log.

6. Verification

After install completes:

  1. Confirm the install exit code: a clean install returns 0x00000000; partial installs return non-zero and leave state in %ProgramData%\Siemens\Automation.
  2. Confirm the registered version: reg query "HKLM\SOFTWARE\Siemens\Automation\WinCC RT Professional" /v Version must show the V19 Update 3 build string.
  3. Confirm the WinCC RT service is registered: sc query "SiemensS7Trace" and sc query "CCAgent".
  4. Launch WinCC Runtime via the desktop shortcut or WinCCRTPro.exe /Project="C:\Projects\Sample.mcp" and confirm the runtime starts without license dialog.

7. Network Path vs Local Path Decision Matrix

Launch Path Outcome with V19 Upd3 Action
\\fileserver\share\Start.exe Signature verification fails (Zone.Identifier + path trust) Copy locally first
Mapped drive Z:\WinCC_V19_Upd3\Start.exe Intermittent; depends on SMB signing policy Use local NTFS path
Mounted ISO via virtual DVD Works when hash is correct and root store is current Preferred for ISO images
C:\Install\WinCC_V19_Upd3\Start.exe Works when both file and root store are intact Recommended
USB stick attached to VM Works if the stick is NTFS-formatted and not write-protected Acceptable as a staging method

8. Certificate Store Maintenance Procedure

For a fleet of isolated Windows Server 2022 VMs, automate the root store refresh using the offline updater:

  1. Download the latest rootsupd.exe from Microsoft Trusted Root Certificate Program.
  2. Copy rootsupd.exe to each isolated VM (via approved removable media).
  3. Run: rootsupd.exe /u (updates without prompting).
  4. Verify: certutil -store Root should list at least 100 root CAs and include the major CAs (DigiCert, Sectigo, GlobalSign, Siemens).

For Siemens-specific intermediates, import the Siemens AG Issuing CA certificates from a known-good machine that already has them installed.

9. Virtualization Layer Considerations (ESXi)

Layer Risk Mitigation
VMware Tools Old Tools version may interfere with Authenticode Match Tools build to ESXi host build
VM hardware version Windows Server 2022 requires HW v17+ for full feature support Upgrade VM to HW v19 / 20
Time sync Skewed clock invalidates signature timestamp Enable VMware Tools time sync with host
AV intercept on virtual disk AV scan during extract can quarantine signed binaries Whitelist install path in AV policy
Shared ISO / storage Concurrent reads across 6 VMs may trigger SMB timeouts Use local VMDK staging instead of shared ISO

Reference: VMware ESXi documentation for hardware compatibility and Tools build guidance.

10. Prevention Best Practices

  • Maintain an offline image of rootsupd.exe refreshed every 60-90 days and apply it to all isolated VMs during planned maintenance.
  • Stage all Siemens installers on a dedicated local folder per VM (C:\Siemens\Stage\<version>) and re-hash before each install attempt.
  • Build a checklist of expected Authenticode signer subjects (Siemens AG, Siemens Industry Software) and verify with Get-AuthenticodeSignature:
$files = Get-ChildItem C:\Siemens\Stage\WinCC_V19_Upd3 -Recurse -Filter *.exe
foreach ($f in $files) {
  $s = Get-AuthenticodeSignature $f.FullName
  Write-Host "$($f.Name): $($s.SignerCertificate.Subject) - $($s.Status)"
}

Status must be Valid; NotSigned or HashMismatch indicates corruption.

  • Keep ESXi, VMware Tools, and Windows Server 2022 cumulative updates current within the constraints of your change-management window. Authenticode enforcement tightens with each Windows cumulative update and previously tolerant setups may fail.
  • Document the certified version of SIMATIC WinCC Runtime Professional V19 Update 3 in your change record so future audits can trace which payload was deployed to which VM.

11. Troubleshooting Matrix

Symptom Likely Cause Remediation
Generic "invalid signature" on Sia.exe Corrupted archive Re-download, hash-check, recopy locally
"A certificate chain processed correctly, but trust is broken" Missing root or intermediate Run rootsupd.exe /u and re-launch
Install fails only on one VM in the fleet Local GPO / clock skew / AV Sync time, clear GPO override, whitelist in AV
Install fails on every VM but base V19 works Update payload corruption common to all copies Re-download from a different mirror / workstation
Setup log shows 0x800B0100 (TRUST_E_CERT_SIGNATURE) Signature hash does not match certificate Replace Sia.exe from a known-good source
Setup log shows 0x800B0101 (CERT_E_EXPIRED) Code-signing certificate out of validity window Verify system clock; check CTL

12. FAQ

Why does the WinCC V19 Update 3 Sia.exe report an invalid signature when the base V19 install succeeded?

The base V19 package and Update 3 are separate, separately-signed downloads. A working base install does not validate the Update 3 payload; verify Sia.exe with SHA-256 and confirm the local Trusted Root store contains the Siemens issuing CA chain. See Sections 5.2 and 5.4.

Can I install WinCC V19 Update 3 directly from a network share?

No. The installer must run from a local NTFS volume. Copy the archive to C:\Install\... on the VM, recompute SHA-256, and launch Start.exe from there. Mounted ISOs via the VM's virtual DVD are an acceptable alternative.

How do I refresh root certificates on a Windows Server 2022 VM with no Internet access?

Use the offline updater rootsupd.exe with the /u switch, sourced from a connected workstation that runs the same OS build. Import the resulting certificates into the Trusted Root and Intermediate stores via certlm.msc.

What error code indicates a corrupted Sia.exe vs a missing root certificate?

Setup log entries of 0x800B0100 (TRUST_E_CERT_SIGNATURE) typically indicate file corruption / hash mismatch, while certificate chain / CTL problems surface as 0x800B0101 or CERT_E_UNTRUSTEDROOT. The %TEMP%\Siemens\SIA\Setup.log file contains the precise Win32 status.

Is Group Policy "Turn off Automatic Root Certificates Update" the real cause?

It is one of the documented causes, but on isolated systems the absence of any auto-update path is the deeper issue. Even with the GPO setting Disabled, no Internet means no CTL refresh; the offline rootsupd.exe procedure is the proper remediation regardless of GPO state.

Back to blog