Configuring HTTPS with HTTP.sys

Seq's web interface and API can be hosted using HTTP.sys to gain additional Windows-specific functionality.

On Windows, Seq can use the HTTP.sys web server provided by the operating system. This was the default web server used by earlier Seq versions, and provides some functionality not available using Kestrel, which is the default web server for new Seq installs.

✅ Enabled by HTTP.sys

  • Windows Integrated Authentication via NTLM/Kerberos/Negotiate is supported, using a password-free link on the Seq login screen (Windows Authentication only)
  • SNI is supported, allowing different HTTPS hostnames to be used on the same port
  • Seq can be hosted under a "virtual directory" path
  • Multiple Seq instances can listen on each port
  • Incoming requests will be filtered by hostname

⛔ Unsupported with HTTP.sys

  • OTLP/gRPC ingestion requires HTTP 2.0 extensions which are unavailable under HTTP.sys
  • TLS certificates cannot be loaded from the Certificates\ storage folder

Switching between Kestrel and HTTP.sys

To check which web server is in use, from an administrative PowerShell prompt:

seq config show -k api.webServer

If the command prints Kestrel your Seq instance is using the Kestrel web server; otherwise, it's running HTTP.sys.

To enable HTTP.sys:

seq config set -k api.webServer -v HttpSys
seq service restart

To switch back to Kestrel:

seq config set -k api.webServer -v Kestrel
seq service restart

HTTP.sys certificate configuration

To configure HTTPS for Seq, you'll first need a certificate for the hostname that Seq is listening on. I.e. if you want to use Seq at then you'll need an SSL certificate for that domain.


For TLS to provide effective security, you need to ensure that both the apps writing log events, and the client machines used to browse to Seq web user interface, trust the certificate assigned to the Seq server.

It is possible to disable certificate validation in apps, or ignore certificate validation warnings in web browsers, but in both of these cases it is unlikely TLS provides any material protection against an observer intercepting communication with the server.

The certificate needs to be stored in the Local Machine/Personal certificate store on the Seq server.

If you don't generally issue certificates for machines in your organisation, you can follow these instructions to generate a self-signed certificate.

Finding the certificate thumbprint

The easiest way to obtain the certificate's thumbprint or "hash" is via IIS Manager's Server Certificates page.


Copy the thumbprint to the clipboard as-is.


To retrieve the thumbprint for a certificate without IIS Manager, open the Manage computer certificates app from the Windows Start screen.

Configure Seq

With the certificate installed and the thumbprint located, the last step is to configure Seq to listen at an HTTP URI.

The command-line below shows the complete process. If you've used named instances of Seq, or installed to a custom data folder, you'll need to include those parameters as appropriate.

The instructions assume that Seq will listen on the standard HTTPS port 443.

seq bind-ssl --thumbprint="THUMBPRINT HERE"
seq config set -k api.listenUris -v https://YOURSERVER
seq service restart

The bind-ssl command accepts a --port= parameter, and this should be specified if the Seq listening endpoint is different from the HTTPS default of 443. Run seq help <command> to see complete options for any of the commands above.

Specify --hostname= if the server is using SNI to distinguish between multiple hosted domain names.

Cipher suites and protocol versions

Because Seq uses the Windows HTTP stack, configuration for TLS cipher suites and protocol versions is the same as for IIS on Windows.

We recommend using a configuration tool such as IISCrypto by Nartac Software to view, disable, and enable various cipher suites and protocol versions.