Web Server Setup

The Web Server Setup page in the Tagnet Admin Console controls how the Tagnet service is reached: whether it listens on HTTP, HTTPS, or both, the ports and certificate for each, and the External URL that readers and emailed links use. The Tagnet service binds the ports directly. There is no IIS to install and no reverse proxy to run.

HTTP and HTTPS are independent switches, so a server can be in one of three states:

State	What it means
HTTP only	The default after installation. No certificate needed.
HTTP and HTTPS	Both ports serve requests. Use this while readers and integrations are moved to HTTPS.
HTTPS only	The HTTP port is not bound at all. Nothing answers on it.

The page is laid out from the most basic setting to the most specific: HTTP, then HTTPS, then the External URL, which is derived from the two above and only needs an override when devices reach the server through a different name.

Every save validates the configuration, opens the configured ports in Windows Firewall, writes appsettings.Production.json, and restarts the Tagnet service. The page requires administrator rights; click Restart as administrator if prompted.

There is one rule the page enforces: HTTP and HTTPS cannot both be off, because the service would then listen on nothing and the only way back would be editing the configuration file on the server.

HTTP

Enable HTTP binds the plain HTTP port. 5000 is the installer default, and 80 works too; because the service binds the port itself, no netsh URL reservation or special right is needed.

To change the port, enter the new one, click Validate, then Save and restart. The page confirms the port is free (or already Tagnet's), opens it in Windows Firewall under a rule named Tagnet Web Server (HTTP), and restarts the service.

Two things to know before changing it:

Readers stop delivering until redeployed. Readers were deployed with the old port in their ingest URL. After the change, redeploy each one from Devices. The page asks you to confirm for this reason.
The installer's rule is replaced, not left behind. The installer opens the port chosen at install time so a machine nobody has configured is still reachable. The first time you save here, the console writes its own rules for the ports you chose, deletes the installer's, and records that it now manages the firewall, so later upgrades leave your configuration alone.

Redirect HTTP requests to HTTPS

Available once HTTPS is enabled. With it on, the HTTP port stays bound but answers every request with a redirect to the HTTPS address instead of serving it.

The redirect applies to everything, including reader ingest and API-key integrations. That is deliberate: a rule with exceptions is a rule nobody can predict. Leave it off while readers still post over HTTP, because a redirect is an unexpected response to reader firmware and some models handle it badly.

Use it when browsers should be upgraded automatically and every machine client is already on HTTPS. If your goal is to close the HTTP port instead, turn Enable HTTP off rather than using the redirect.

Before you enable HTTPS

A server certificate with its private key in the Local Computer Personal store (certlm.msc). Any of these works:
- A certificate from your organization's certificate authority, for example Active Directory Certificate Services. Domain-joined browsers and devices trust it automatically. This is the recommended option.
- A certificate from a public CA, if the server has a public host name.
- A self-signed certificate for testing. From an elevated PowerShell prompt:
```
New-SelfSignedCertificate -DnsName "tagnet.corp.local", "tagnet" -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(2)
```
  Browsers and readers will not trust it until you distribute it to them (see Client trust).
The certificate must name the host devices will use. Its common name or one of its DNS names should be the name readers and browsers connect to, such as tagnet.corp.local.
A port. 443 is what browsers and readers assume. Kestrel binds the port directly under the service account; no netsh URL reservation or IIS binding is involved.

Enable HTTPS from the Admin Console

Open the Tagnet Admin Console and choose Web Server in the left navigation. Click Restart as administrator if prompted.
Leave Enable HTTP and its port as they are for now. Turning HTTP off is the last step of a migration, not the first; see Moving an existing server to HTTPS.
Check Enable HTTPS. The certificate and HTTPS port fields appear.
Choose the certificate. The list shows every certificate in the Local Computer Personal store, usable ones first. The details below the list show the subject, issuer, DNS names, validity period, and whether a private key is present. Click Refresh after importing a new certificate.
Set the HTTPS port. Leave 443 unless another service already uses it.
Check the External URL preview. This is the address readers, invitation links, and password-reset emails will use. It is derived from the certificate name and the HTTPS port, for example https://tagnet.corp.local. Leave the override blank unless devices reach this server through a different name, NAT, or a load balancer. See What the External URL controls.
Leave the firewall option checked to allow the configured ports inbound on Domain and Private networks. The rules are named Tagnet Web Server (HTTP) and Tagnet Web Server (HTTPS), are owned by the console, and survive installer upgrades. See Network profiles if the server is unreachable from other machines afterwards.

Click Validate. The checks are:

Check	What it confirms
Listeners	At least one of HTTP and HTTPS is on, and it names what the combination will do.
HTTP port	The HTTP port is valid, differs from the HTTPS port, and is free or already Tagnet's. Skipped when HTTP is off.
Certificate	The selected certificate is still in the store.
Validity period	Not expired and not yet valid. Warns when fewer than 30 days remain.
Private key	The certificate has a private key. Without one it cannot terminate TLS.
Server authentication	The certificate's key usage permits server authentication. Kestrel refuses a client-only certificate.
Service key access	The account the Tagnet service runs as (`LOCAL SERVICE` by default, or the domain account or gMSA you reconfigured it to) can read the private key. This is the step manual setups most often miss.
Subject match	Kestrel selects certificates by subject name, preferring an exact name match and then the latest expiry, and skips untrusted certificates unless told otherwise. This check confirms the certificate you picked is the one Kestrel will load.
Trust chain	Whether the certificate chains to a trusted root on this server. A warning here means clients must trust it explicitly.
HTTPS port	The HTTPS port is valid, differs from the HTTP port, and is free or already Tagnet's.
Host name	The certificate covers the host name devices will use, and that name resolves in DNS from this server.
External URL	The override, if any, is a valid address, and is not an `http://` address on a server where HTTP will not answer requests.

With HTTPS off, the certificate checks are skipped and only the listener, port, host name, and External URL checks run.

If Service key access fails, click Grant key access. The console gives the service account read access to the key, which is the same change as Manage Private Keys in certlm.msc. Click Validate again.
Click Save and restart. The console writes the configuration, restarts the Tagnet service, and reports the result. The Home page's Open Tagnet button now opens the HTTPS address.

Warnings do not block saving. Failures do.

What the External URL controls

The External URL is the base address Tagnet gives out: the ingest endpoint pushed to readers during deployment, the links in user invitations, and the links in password-reset emails. It is shown read-only on the System Settings page in the web UI together with where it came from.

Tagnet resolves it in this order:

Hosting: External URL, when set on this page. Use this when devices reach the server through a name the server cannot see, such as a NAT address, a DNS alias, or a load balancer.
Otherwise, when HTTPS is enabled, https:// plus the certificate's name plus the HTTPS port (omitted for 443).
Otherwise http:// plus the server's name plus the HTTP port.

Because the address changes when a port or HTTPS changes, readers deployed before the change need to be redeployed.

Two situations need the override:

Upgrading from a version where External URL was typed on the System Settings page. That value is no longer used. Tagnet logs a warning at startup and System Settings shows the old value when it differs from the derived address. If the old address was a NAT name or alias that devices depend on, set it as the override before redeploying any reader.
Hosted or container installs without the Admin Console. Set the Hosting__ExternalUrl environment variable to the public address; the derived default would be the container's internal name.

Moving an existing server to HTTPS

Enable HTTPS first and turn HTTP off last. Done in that order there is no interruption, because everything keeps working on HTTP while it is moved across one device at a time. Doing both in a single save is what causes an outage.

Enable HTTPS, leave HTTP on. Both ports now serve. Nothing that already works stops working.
Confirm clients can trust the certificate. A reader refuses a certificate it does not trust, and unlike a browser it cannot click through a warning. A certificate from your organization's CA is the reliable choice for reader networks; for a self-signed certificate, consult the reader vendor's documentation on installing a trusted certificate.
Redeploy the readers. In Tagnet, open Devices and redeploy each one. The deployment pushes the HTTPS ingest URL. Confirm reads arrive on the Ingest History after each redeploy.
Repoint API integrations. Anything using an API key against /api/v1 needs its base address changed to the HTTPS one.
Turn HTTP off and save. Anything still using the old address stops working now, which is the point: the failure is visible rather than silent.
Remove the HTTP firewall rule. See below.

Turning HTTP off

Uncheck Enable HTTP and click Save and restart. The console confirms first, then restarts the service with nothing bound to the HTTP port.

The console leaves the Tagnet Web Server (HTTP) firewall rule in place at this point, on purpose. With the rule open and nothing listening, a client using the old address is refused immediately and can log a clear error. With the rule removed, its packets are dropped instead and the client hangs until it times out, which is much harder to diagnose. The page then shows a Remove HTTP firewall rule button; use it once every reader and integration is confirmed working on HTTPS.

Two consequences worth planning for:

A client that hits the HTTP port gets no reply at all, not a redirect. There is nothing listening to send one. This is the trade for a closed port, and it is why the steps above put the redeployment before the switch.
A client that speaks plain HTTP to the HTTPS port also gets no useful answer, because the server expects a TLS handshake there.

If you would rather clients be told where to go than be refused, keep Enable HTTP on and use the redirect option instead. The HTTP port stays open in that case.

Network profiles

Windows classifies each network connection as Domain, Private, or Public, and a firewall rule only applies to the profiles it names. Tagnet's rules cover Domain and Private, which are the two a correctly classified server sits on. Domain is the important one: an enterprise server's network adapter sits on that profile, and a rule that covers only Private permits nothing there at all.

The installer writes one rule per profile, Tagnet Web Server (Domain) and Tagnet Web Server (Private), because the packaging format allows a rule only a single profile. The Admin Console writes one rule per listener instead, each covering both profiles. Configuring the web server removes the installer's pair.

Public is left out on purpose. Windows assigns it to networks it does not recognise, and opening a port on every profile is not a choice Tagnet should make on your behalf. If the server's network was never classified, though, it may well be sitting on Public.

The symptom is specific: Tagnet works in a browser on the server itself but nothing else on the network can reach it, even though the ports are open and the service is running. If you see that, tick Also allow on Public networks under the firewall option and save again.

To check the classification, run Get-NetConnectionProfile in PowerShell on the server and look at NetworkCategory.

The server's firewall is not the only thing in the way

Windows Firewall on the server is the last hop. Reaching Tagnet from another machine also needs DNS to resolve the address, and a network path to the port through any perimeter firewall, VLAN ACL, or VPN policy in between. Those are outside Tagnet's control and are frequently managed by someone else. If the rules here are correct and the server is still unreachable, that is where to look next.

Client trust

CA-issued certificate: nothing to do on domain-joined machines. Other machines need your CA's root certificate in their Trusted Root store.
Self-signed certificate: export the certificate (without the private key) as a .cer file and import it into Trusted Root Certification Authorities on each machine that browses to Tagnet, or distribute it with Group Policy. Until then browsers show a certificate warning.

Renewing the certificate

Import the renewed certificate into the Local Computer Personal store with the same name. Kestrel loads the latest-expiring certificate that matches the configured name, so it picks the new one on the next service restart with no configuration change. Two things still need doing:

Grant the service account read access to the new certificate's private key. A renewed certificate has a new key. On the Web Server Setup page, select the new certificate, click Validate, and use Grant key access if flagged.
Restart the Tagnet service, either with Save and restart on the page or from services.msc.

Turning HTTPS off

Turn Enable HTTP on first if it is off, or the page refuses the save. Then uncheck Enable HTTPS and click Save and restart. The console asks you to confirm, removes the HTTPS endpoint and its firewall rule, and restarts the service. Devices and links are given the HTTP address again, so redeploy readers that were switched to HTTPS.

Browsers that connected over HTTPS may keep insisting on HTTPS for that host name for up to 30 days (HTTP Strict Transport Security). Connect using the server's IP address in the meantime, or clear the browser's HSTS entry for the host.

Manual configuration

The page writes standard Kestrel settings, so the same result can be reached by hand on a server without the console. Everything below runs elevated.

For HTTPS, import the certificate into the Local Computer Personal store and grant the service account (LOCAL SERVICE unless you reconfigured the service) read access to its private key: in certlm.msc, right-click the certificate, All Tasks, Manage Private Keys.
Edit C:\ProgramData\Stratum Global\Tagnet\appsettings.Production.json. Port is the HTTP port; the Endpoints block is the HTTPS listener and can be omitted for HTTP only. The * host binds every IPv4 and IPv6 address:
```
"Kestrel": {
  "Port": 5000,
  "Endpoints": {
    "Https": {
      "Url": "https://*:443",
      "Certificate": {
        "Subject": "tagnet.corp.local",
        "Store": "My",
        "Location": "LocalMachine",
        "AllowInvalid": true
      }
    }
  }
}
```
Subject is matched as a substring of the certificate's subject. Set AllowInvalid to true only when the certificate does not chain to a trusted root on the server (self-signed, or a private CA not in Trusted Root); otherwise Kestrel refuses to load it.
The two switches live under Hosting at the top level of the same file:
```
"Hosting": {
  "HttpEnabled": false,
  "HttpRedirectsToHttps": false,
  "ExternalUrl": "https://tagnet.acme.com"
}
```
HttpEnabled defaults to true. Setting it to false without an HTTPS endpoint configured is ignored: Tagnet binds HTTP anyway and logs why, so a mistake here cannot leave the server unreachable. HttpRedirectsToHttps defaults to false and is ignored unless HTTP is enabled and HTTPS is configured. ExternalUrl points devices at a different name and can be omitted.
Allow the ports inbound in Windows Firewall with rules of your own, covering at least the Domain and Private profiles. Do not edit the installer's Tagnet Web Server (Domain) and Tagnet Web Server (Private) rules; installer upgrades recreate them unless the Admin Console has taken over the firewall.
Restart the TagNet service.

Troubleshooting

The service does not start after enabling HTTPS. The most common cause is the private key: the service account cannot read it. Open the Web Server Setup page, click Validate, and use Grant key access. The Tagnet log in C:\ProgramData\Stratum Global\Tagnet\logs names the certificate it could not load. The second most common cause is another process holding the port.

The service does not start after changing the HTTP port. Another process holds the new port. Validate reports this before saving; if the port became busy afterwards, pick another port and save again.

The browser warns about the certificate. Either the certificate is not trusted on that machine (see Client trust) or its name does not match the address in the browser. Use the name the certificate was issued for, or set the External URL override to that name.

Readers stopped sending data. Readers deployed before a port change or HTTPS switch keep using the old address. Redeploy them from Devices. A reader that was redeployed with the HTTPS address and then went quiet does not trust the certificate. Check its logs and see Moving an existing server to HTTPS.

The Admin Console still opens an HTTP address. The Open Tagnet button uses the External URL from the current configuration. If the page's save reported an error, the configuration was not applied; fix the reported check and save again.

A client cannot connect at all after HTTP was turned off. It is still using an http:// address. Nothing is listening there, so the connection is refused, or hangs if the firewall rule has already been removed. Repoint the client at the HTTPS address: readers by redeploying them from Devices, integrations by changing their base address. The Tagnet log records which listeners are bound at every startup, so check that first to confirm the server is in the state you expect.

Tagnet is still listening on HTTP after turning it off. With no HTTPS endpoint configured, the setting is ignored on purpose and the startup log says so. Enable HTTPS first, then turn HTTP off.

Browsers refuse to use HTTP after HTTPS was enabled. Once HTTP no longer serves requests, Tagnet sends HTTP Strict Transport Security, and browsers remember it for up to 30 days for that host name. If you turn HTTP back on, browsers that saw the header keep insisting on HTTPS. Connect using the server's IP address in the meantime, or clear the browser's HSTS entry for the host.

HTTP​

Redirect HTTP requests to HTTPS​

Before you enable HTTPS​

Enable HTTPS from the Admin Console​

What the External URL controls​

Moving an existing server to HTTPS​

Turning HTTP off​

Network profiles​

The server's firewall is not the only thing in the way​

Client trust​

Renewing the certificate​

Turning HTTPS off​

Manual configuration​

Troubleshooting​