Transport Layer Security#

The Curity identity Server supports versions 1.0, 1.1, 1.2 and 1.3 of the Transport Layer Security protocol.

By default, only TLSv1.2 is enabled on the Identity Server for server-side transport security.

TLSv1.0 and TLSv1.1 have well known security issues and are disabled by default due to that reason. However, they can be explicitly enabled via the enable-tls-1.0 and enable-tls-1.1 service role configuration settings respectively. A use case for this can be the requirement to accept connections from older devices or legacy software, which may not support the more recent TLS versions.

TLSv1.3 is disabled by default due to possible compatibility issues with previous setups, namely for mutual TLS. However, it can be explicitly enabled via the enable-tls-1.3 service role configuration setting.

For details on the configuration model, see the Configuration Reference .

Server Name Indication#

In order to support multiple hosts on the same IP-address while using TLS, a client can use the Server Name Indication (SNI) in the TLS handshake protocol to indicate for which server name the connection is to be requested. The Identity Server has the option to control the behaviour of how SNI is treated during connection setup by indicating that the SNI name from the client’s TLS request must match the server’s SSL certificate’s subject, or even by requiring the client to include the appropriate server name in its (TLS) request.

By default, the Identity Server will not verify the SNI of a TLS connection setup.

There are a few pitfalls when it comes to tightening the SNI requirements for a service role’s TLS connection:

  1. SNI checking is only done when the server’s SSL certificate contains multiple DNS names in its Subject Alternative Name (SAN) setting. Please ensure that your certificate has this.
  2. Using SNI only makes sense when the server is listening for multiple hostnames. As the Identity Server only supports singular keystores to be used for server SSL, this certificate must in this case contain multiple SAN DNS names.
  3. Enabling host checking will compare the hostname of the requested URI with the hostname of the certificate. This means that the hostname of the HTTP-request is used to validate. However, when enabling the require-sni option, the checks are done such that the hostname of the SNI name in the TLS ClientHello message must match the hostname of the certificate (or one of its SAN DNS names). Notice how the first option performs validation on the HTTP level, whereas the second option performs validation on the TLS level.
  4. A server name must be a Fully Qualified DNS name of the server. This means that for example localhost is not included (by a client) nor is it accepted (by the server) as valid ServerName in a TLS ClientHello message, as it is not fully qualified. As a result, a certificate issued for localhost is unusable with SNI.
  5. Using SNI when exposing the Identity Server via a reverse proxy (which is the normal deployment model) is atypical and probably not needed.

To check a certificate’s SAN settings, you can use openssl to show the certificate’s contents. Given the PEM-version of a certificate, issue the command:

$ openssl x509 -text < MyGoodPemEncodedCertificate.crt

This will show something like this in the output:

...
X509v3 extensions:
    X509v3 Subject Alternative Name:
        DNS:curity1.example.net
        DNS:curity2.example.net
...

To authenticate OAuth clients using a SAN, see OAuth Client SAN in the Token Service admin guide.

Was this helpful?