HTTPS and Certificates

Where TLS lives in Infohub#

Infohub's web surfaces are ASP.NET Core (Kestrel) applications hosted by Bootstrap:

• Bootstrap itself (ports 4500/4501) can run HTTP or HTTPS; its HTTPS mode takes a certificate identified by subject name from the Windows certificate store (the service supports a -useHttps / certificate-subject configuration).
• Flow Server (the web client) serves browsers on its configured port, HTTPS when configured with a certificate.
• Report/notification content that embeds links inherits whatever scheme the server publishes.

The certificate is therefore a machine-level Windows certificate store item on each Platform host — not a file in Infohub's folders. That single fact explains most of the failure modes below.

The rules that prevent tickets#

1. The certificate must be in the Local Machine store (not Current User) on the Platform host, with its private key, and the Bootstrap service account must have read access to that private key. A certificate imported under an admin's user store works for testing in Config and fails for the service — the classic works-then-doesn't.
2. The subject/SAN must match the name users type. A certificate for flowserver.corp.local does not cover https://flowserver/ — browsers and inter-component calls both object.
3. The chain must be trusted by the clients — browsers, other Platform hosts, and the mobile app. An internal CA that desktops trust but a plant-floor terminal does not yields per-client "untrusted" behaviour that looks intermittent.
4. Validity matters to machines that don't complain visibly. Inter-component traffic fails quietly compared to a browser's red warning — see renewal, below.

Failure 1 — it broke when the certificate was renewed#

The most common HTTPS ticket, and it has a precise shape: HTTPS worked for a year; the certificate was renewed/replaced; now Infohub returns gateway errors while IIS or other software on the same box is happy with the new certificate.

Why: Infohub's binding is to the certificate configured for it (by subject, from the store). A renewal that changes the certificate (new thumbprint, sometimes new subject shape, sometimes imported without private key or without service-account access) leaves Infohub either bound to the old, now-invalid certificate, or unable to read the new one.

The renewal checklist:

1. Import the renewed certificate to Local Machine, with private key.
2. Grant the Bootstrap service account read on the private key.
3. Confirm the subject matches what Infohub's HTTPS configuration names (if the subject changed, update the configuration).
4. Restart the Flow Bootstrap service — bindings are read at start; a renewal without a restart keeps serving the old certificate until it expires, which is exactly the "worked for weeks after renewal, then died" variant.
5. Verify from a client that shows you the certificate (browser padlock) that the new one is being served.

Failure 2 — "ensure the Bootstrap Service and Platform are running and using the correct HTTPS port"#

This deploy-time error names HTTPS but is really an reachability mismatch: the deploying side and the Bootstrap disagree about scheme or port. Check, in order:

1. Is Bootstrap actually configured for HTTPS (or not), and does the deploy target use the same scheme? An HTTP deploy against an HTTPS Bootstrap — or vice versa — produces exactly this.
2. The port: 4501 reachable from where you are deploying (firewall, and nothing else bound to it).
3. The certificate valid right now — an expired cert fails the handshake and presents as this same error.
4. The Platform row's host matching the machine (the perennial cause wearing an HTTPS costume).

Failure 3 — untrusted certificate, sometimes#

Per-client trust (rule 3). The tell: some browsers/machines fine, others warned. Fix the trust distribution (push the internal CA to all clients, including non-domain terminals and phones using the mobile app) rather than weakening anything server-side. For internet-exposed instances, use a public CA and this failure disappears.

SQL's TLS is a different subject#

The Config tool or Bootstrap failing to reach SQL Server with certificate errors ("trust server certificate") is SQL client encryption policy, not Infohub's web TLS — the fix is a proper certificate on SQL Server or the trust flag in the connection. Covered in Users, Groups, and Access.

A sane rollout order#

1. Get the certificate right on one Platform host (store, key access, subject).
2. Enable HTTPS on Bootstrap; restart; verify 4501 serves the certificate.
3. Enable on Flow Server; verify the client.
4. Repeat per Platform host — every host needs its own valid certificate.
5. Diarise the expiry with the renewal checklist attached. Certificate expiry is the single largest "stopped and nothing changed" cause across all of Infohub.

See also#

• Users, Groups, and Access
• Infohub Architecture at a Glance
• Installing Infohub
• Common Problems and Fixes