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 Curity 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.
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 Curity 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 Curity 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:
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 Subject Alternative Name:
To authenticate OAuth clients using a SAN, see Subject Alternative Name in the Token Service admin guide.