Scout Board HTTPS Certificate Setup

Scout Board HTTPS Certificate Setup

Note:

This certificate setup guide applies to Scout Board version 15.2603 and later

This guide explains how to configure the HTTPS certificate that Scout Board presents to administrators in the web browser.

Three options at a glance

Option A: Self-signed certificate (default)

If you do nothing, Scout Board generates a new self-signed certificate the first time the service starts. Browsers will warn that the connection is not trusted, but Scout Board itself works.

This is suitable for evaluation only. Use a CA-signed certificate for production.

Option B: CA-signed certificate, selected during installation

The Scout Board installer in 26.03 introduces a Certificate dropdown on the Scout Board settings page. The dropdown lists every certificate in the Windows LocalMachine –> Personal store that has an accessible private key. When you pick a certificate, the installer exports it together with any intermediate (and root) certificates it can find in the Windows certificate stores, and writes the result to certificate.crt.

Steps

1. On the machine where you will install Scout Board, import your CA-signed certificate (with private key) into LocalMachine –> Personal. For PFX/PKCS#12 imports, use the Windows Certificate Manager (certlm.msc); the wizard places intermediate CA certificates into Intermediate Certification Authorities and any root into Trusted Root Certification Authorities. Give your leaf cert a meaningful Friendly Name so you can recognise it in the dropdown.

2. Run the Scout bundle installer.

3. On the Scout Board settings page, open the Certificate dropdown and pick your imported certificate. If you imported it after the wizard was already open, click the refresh button next to the dropdown.

4. Continue the installation as usual.

Note:

If after install you see a browser certificate warning or you are redirected to a license-switch page when signing in, the chain in certificate.crt is most likely incomplete. The next section tells you how to verify and fix.

If the certificate chain is incomplete after install

The installer can only export intermediate certificates that exist in the Windows certificate store at the moment you run it. If you imported a leaf certificate without its accompanying intermediate(s) - a common situation when the source PFX did not bundle them - the installer will write only what it found, which may be just the leaf.

To diagnose:

1. Run the count check from Verifying your setup below. A count of 1 with a CA-signed certificate means the chain is incomplete.

2. Check backend.log for certificate.crt contains only a leaf certificate or unable to verify the first certificate.

To fix:

1. Stop the Scout Board Windows service.

2. Append the missing intermediate certificate(s) (and, for an internal/private CA, the root) to <InstallDir>\scoutboard\certificate.crt. The next section shows how to build the chain.

3. Start the Scout Board Windows service.

On the next install or upgrade, the installer will detect that you have built a complete chain and will leave your certificate.crt alone, so the manual fix survives.

Option C: CA-signed certificate, configured after installation

Use this when you cannot pick the certificate at install time, when the certificate is being renewed, or when you upgrade Scout Board from a release older than 26.03.

1. Stop the Scout Board Windows service.

2. Place your full chain file at <InstallDir>\scoutboard\certificate.crt. The default install directory is C:\Program Files\Unicon\Scout\Scout Board\.

3. Place your unencrypted PKCS#8 private key at <InstallDir>\scoutboard\private.key.

4. Open <InstallDir>\scoutboard\.env in a text editor and set CERTIFICATE=CUSTOM. The legacy value CERTIFICATE=SIGN is still accepted as an alias for backward compatibility.

5. Start the Scout Board Windows service.

Building the certificate chain file

certificate.crt is a single text file in PEM format. It can hold one or many certificates back-to-back. The order matters: leaf first, then each intermediate moving up to the root.

A correctly built file looks like this:

-----BEGIN CERTIFICATE-----
... your leaf certificate (the one issued for your Scout Board hostname)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... intermediate CA certificate (the one that signed your leaf)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... next intermediate, if your CA uses a multi-level chain
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... root CA certificate — only required if you use an internal/private CA
-----END CERTIFICATE-----
<!--NeedCopy-->

What to include depends on your CA:

1. Public CA (DigiCert, GlobalSign, Let’s Encrypt, etc.): leaf + intermediate(s). The root is optional - Scout Board already trusts public roots out of the box.

2. Internal/corporate CA: leaf + intermediate(s) + your private root. Without the root, Scout Board cannot validate the chain because it does not consult the Windows trust store by default.

Most public CAs publish a downloadable bundle file (often called “intermediate bundle” or “CA bundle”) that you can simply append to your leaf certificate using any text editor or:

# Build certificate.crt = leaf + intermediate bundle
Get-Content leaf.crt, intermediate-bundle.crt | Set-Content certificate.crt
<!--NeedCopy-->

Verifying your setup

After placing the files and (re)starting the Scout Board service, run these checks.

How many certificates does certificate.crt contain?

`Select-String -Path "C:\Program Files\Unicon\Scout\Scout Board\certificate.crt" -Pattern "BEGIN CERTIFICATE" | Measure-Object`
<!--NeedCopy-->

If the count is 1 and you are using a CA-signed certificate, the chain is incomplete. Append your intermediates and restart the service.

Does Windows agree the chain is valid?

certutil -verify -urlfetch "C:\Program Files\Unicon\Scout\Scout Board\certificate.crt"
<!--NeedCopy-->

Does the Scout Board log show any chain warnings?

Open backend.log in C:\Users\Public\Documents\Unicon\Scout\ScoutBoard\ and look for either of these lines:

certificate.crt contains only a leaf certificate without the intermediate CA chain
License validation error ... unable to verify the first certificate
<!--NeedCopy-->

Either of these means the chain is incomplete. The companion file backend_error.log in the same folder records error-level entries only - chain warnings appear in backend.log.

Select-String -Path "C:\Users\Public\Documents\Unicon\Scout\ScoutBoard\backend.log" -Pattern "leaf certificate|unable to verify"
<!--NeedCopy-->

Open Scout Board in a browser

The browser should display the padlock without warnings, and you should be able to log in without being redirected to a license-switch page.

Troubleshooting

Permissions, ownership and restart

1. Both certificate.crt and private.key must be readable by the account running the Scout Board Windows service. By default this account is LocalSystem, which has access.

2. Replacing either file requires a service restart - Scout Board reads them once at startup.

3. The installer cleans up both files on a complete uninstall, but preserves them across upgrades. Your custom certificate survives a Scout Board upgrade.

4. If you have manually edited certificate.crt to append intermediates, the installer detects this on upgrade and leaves the file alone - your manual fix survives.

Frequently asked questions

Can I use a wildcard certificate?

Yes. Wildcard certificates work the same way — the leaf is the wildcard certificate, and the intermediate(s) come from the CA that issued it.

Can I use the same certificate as another service on this machine (IIS, Citrix Gateway, etc.)?

Yes, provided the certificate covers the hostname customers use to reach Scout Board. Import it into LocalMachine\Personal once and it will appear in the installer dropdown.

What happens at certificate renewal time?

Stop the Scout Board service, replace certificate.crt and private.key with the renewed file (full chain), then start the service. No installer rerun is needed.

What happens during a Scout Board upgrade?

Your existing certificate.crt and `private.key? are preserved across upgrades. You do not need to re-import or rebuild the chain file. If you previously appended intermediates manually, those are preserved too.

Where are the Scout Board log files?

C:\Users\Public\Documents\Unicon\Scout\ScoutBoard\backend.log (info-level entries and above, including chain warnings) and backend_error.log (error-level only) in the same folder. There is also a Windows service wrapper log at %APPDATA%\ScoutBoard\, but for certificate issues you want backend.log.

Why does Scout Board need the intermediates in the file rather than relying on the Windows certificate store?

The Scout Board service uses its own bundled trust list and does not read intermediate certificates from the Windows store at runtime. This keeps Scout Board behaviour consistent across servers regardless of what is installed in the local Windows trust store. The trade-off is that you must ensure certificate.crt is a complete chain.