This page contains:

• Setting up HTTPS in Kestrel: enabling the HTTPS endpoint and configuring a certificate in Kestrel
• Setting up Additional HTTPS Settings (required for both Kestrel and IIS)

Since version 12.0, the default Redgate Monitor web server has been upgraded to ASP.NET Core, and is now hosted by Kestrel instead of IIS Express. Kestrel is a Microsoft-supported production-ready web server that supports HTTPS.

If you choose to use the default Redgate Monitor web server in the web installer, then you will need to configure and enable HTTPS after the installer is complete. If installing on Windows Server there is an option to use IIS hosting - see Installing Redgate Monitor on IIS. In either case, you must also configure the Additional HTTPS Settings described at the bottom of this page.

Enabling the HTTPS endpoint and configuring a certificate in Kestrel

In order to configure the HTTPS endpoint, you'll need to copy the Webserver.Kestrel.config file from the website installation directory to the program data directory and edit it accordingly.

Installation directory (copy from)

Do not edit this file directly. 

• (Windows) %ProgramFiles%\Red Gate\Redgate Monitor\Web\Webserver.Kestrel.config
• (Linux) /opt/redgate/redgatemonitor/web/Webserver.Kestrel.config

Program Data directory (destination - for editing)

Settings can be overridden by making changes to this copy:

• (Windows) %ProgramData%\Red Gate\Redgate Monitor\Webserver.Kestrel.config
• (Linux) /etc/opt/redgate/redgatemonitor/web/Webserver.Kestrel.config

You should see that the <http> endpoint is enabled on the port configured by the installer. You will need to uncomment the <https> endpoint, then fill in one of the certificate configurations. The unused certificate configuration elements should be removed.

After editing the config file, restart the Redgate Monitor Web Service Windows service to ensure that the configuration has been reloaded.

Configuring HTTPS using a .pfx certificate file on disk

A PFX formatted certificate containing the private key is required. The .pfx certificate configuration is in the following format:

        <certificate>
          <path>/path/to/certificate.pfx</path>
          <password>[PFX cert password]</password>
        </certificate>

Specify the path to the certificate file, as well as the password to decrypt the certificate file if required. The Web Server Service account should have read access to this file.

Configuring HTTPS using PEM certificate files on disk

With a PEM formatted certificate, the certificate data and private key are expected to be in separate files. The certificate configuration is in the following format:

        <certificate>
          <path>/path/to/certificate.crt</path>
          <keypath>/path/to/keypath.key</keypath>
          <password>[PEM cert password]</password>
        </certificate>

Specify the path to the certificate file, the path to the private key file, and the password to decrypt the private key if required. The Web Server Service account should have read access to this file.

Configuring HTTPS using a certificate from the Windows Certificate Store

Using a certificate from the Windows Certificate Store is more secure than the above options, but requires more setup. The certificate configuration is in the following format:

        <certificate>
          <subject>[certificate subject CN]</subject>
          <store>[certificate store]</store>
          <location>[certificate location]</location>
          <allowInvalid>false</allowInvalid>
        </certificate>

The configuration values should be set as follows:

• subject: Specify the Common Name (CN) for the certificate here. This value will be used to filter the list of available certificates.
• store: The programmatic name of the certificate store that should be searched for the certificate. 
• location: LocalMachine or CurrentUser. If CurrentUser is specified, make sure that the Redgate Monitor Web Service windows service is running as the appropriate user to see the certificate.
• allowInvalid: If set to true, this may allow certificates that are expired or otherwise invalid. This should be kept as false unless strictly necessary.

The following PowerShell script may help to find the appropriate configuration values. It will list all certificates that are visible to the user running the script which are eligible for use by Kestrel:

$serverAuth = New-Object -TypeName Microsoft.PowerShell.Commands.EnhancedKeyUsageRepresentation -ArgumentList "Server Authentication", "1.3.6.1.5.5.7.3.1"

Get-ChildItem -Recurse Cert:\ |
    Where-Object { ! $_.PSIsContainer } |
    Where-Object { $_.HasPrivateKey } | 
    Where-Object { $_.EnhancedKeyUsageList -contains $serverAuth } |
    Where-Object { $_.Verify() } |
    Select-Object @{n = 'Path'; e = { Convert-Path $_.PSParentPath } }, Subject, FriendlyName, Thumbprint

Here is some example output from the script:

Path           Subject      FriendlyName
----           -------      ------------ 
CurrentUser\My CN=localhost Example site certificate

In order to use this certificate, we would specify "localhost" as the [certificate subject CN], "CurrentUser" as the [certificate location]and "My" as the [certificate store] store like this:

        <certificate>
          <subject>localhost</subject>
          <store>My</store>
          <location>CurrentUser</location>
          <allowInvalid>false</allowInvalid>
        </certificate>

Additional HTTPS settings

Since version 12.0.9, there are a number of additional HTTPS settings that can be configured in the appsettings.json file

Installation copy (do not edit)

Default values are found in this file, which will be overwritten on update of Redgate Monitor (hence do not edit).

• (Windows) %ProgramFiles%\Red Gate\Redgate Monitor\Web\appsettings.json
• (Linux) /opt/redgate/redgatemonitor/web/appsettings.json

Program Data copy (for editing)

Settings can be overridden by making changes to this file:

• (Windows) %ProgramData%\Red Gate\Redgate Monitor\appsettings.json
• (Linux) /etc/opt/redgate/redgatemonitor/web/appsettings.json

The Strict-Transport-Security HTTP response header

All HTTP responses include the Strict-Transport-Security header. This is a setting that is used by web browsers so that when a user enters the server address directly in their browser's address bar, the browser will automatically prefix the address with https, rather than first making a potentially insecure http request that gets redirected to https.

The default value of the header is max-age=300, which means the setting will be remembered for just 5 minutes (300 seconds = 5 minutes). This is useful when first setting up HTTPS on a new server, but for production use this value should be gradually increased to max-age=63072000 (2 years). See https://HSTSpreload.org/ for more guidance.

{
    "customHeaders": {
        "Strict-Transport-Security": "max-age=300"
    }
}

The isHttpsEnabled setting

This indicates to Redgate Monitor whether or not HTTPS is actually being used. This controls a number of internal behaviours in Redgate Monitor, such as security flags on various cookies. By the default the value will be automatically determined based on whether or not you've enabled the HTTPS endpoint for the built-in Kestrel webserver, as described above. However, if you've enabled HTTPS using some other means (for example, by hosting Redgate Monitor in IIS, or using a reverse proxy such as NGINX) then you should explicitly set this value to true.

{
    "httpsSettings": {
        "isHttpsEnabled": true
    }
}

The shouldRedirectHttpToHttps setting

This indicates that all incoming HTTP requests should be redirected to HTTPS. The default value is true when isHttpsEnabled is true, or false when isHttpsEnabled is false. You might want to explicitly set this value to false if you're using a reverse proxy to deal with incoming HTTPS requests which are then transparently passed through to Redgate Monitor using HTTP.

{
    "httpsSettings": {
        "shouldRedirectHttpToHttps": false
    }
}

The shouldDisplayHttpWarning setting

This indicates that a security warning about the use of HTTP should be displayed at the top of any page that's served over HTTP. If you want to disable this warning, set the value to false.

{
    "httpsSettings": {
        "shouldDisplayHttpWarning": false
    }
}

The disableInsecureTlsVersions setting

Set this value to true to disable the use of TLS 1.0 and TLS 1.1, which are considered insecure. Redgate Monitor will use TLS 1.3 if supported by the underlying operating system, or fall back to TLS 1.2 if TLS 1.3 is unavailable. Alternatively, consider disabling TLS 1.0 and TLS 1.1 for the underlying Windows operating system.

{
    "httpsSettings": {
        "disableInsecureTlsVersions": true
    }
}