This article describes the steps necessary to configure
In this section:
Related articles
Standard TLS
Overview
Transport Layer Security (TLS) is a cryptographic protocol providing communication security over the Internet which is designed to prevent eavesdropping and tampering. In TLS, the server proves its identity to the client.
Standard TLS handshake
- The client sends a ClientHello message with a list of the supported cipher suites, random number, the supported TLS versions and the compression methods.
- The server sends a ServerHello message with the TLS version, a random number, the strongest cipher suite, and a compression method from the client's list.
- The server sends its own certificate.
- The server sends a ServerHelloDone message.
- The client sends a key depending on the cipher selected, and then begins computing the primary secret.
- The client sends the ChangeCipherSpec message - authentication and encryption starts.
- The client sends its Finished message, which the server decrypts and verifies.
- The server sends a ChangeCipherSpec message, which the client decrypts and verifies.
- The server sends a Finished message.
The encrypted application messages then start flowing until the session ends.
Unable to show "metadata-from": No such page "_space_variables" Configuration for Standard TLS
In order to configure
Enabling Fallback Compatibility Mode will allow reversion of the connection to an earlier, less secure, version of TLS (for example to SSLv3), thus weakening the security level. For details, refer to Creating and Modifying TLS Profiles.
Mutual TLS (MTLS)
MTLS Overview
Mutual TLS provides mutual identity authentication of the server and the client through the exchange and verification of their digital certificates.
Verify Peer Server Certificate can only be disabled if MTLS is disabled.
MTLS Illustration Notes
Step 3 - Always takes place when Mutual Authentication is enabled. If MTLS is disabled, then Verify Peer Server Certificate can be disabled.
Step 4 - This action takes place when MTLS is enabled and Validate Server FQDN is enabled. If Verify Peer Server Certificate is disabled, the Validate Server FQDN is also disabled. Validate Server FQDN is an enhanced security feature of
Steps 5, 6, 7 and 8 - If MTLS is enabled, steps 5, 6, and 7 are mandatory and point 8 could be made optional but the steps 5 through 8 are performed by default. If MTLS is disabled, steps 5 through 8 will not be performed.
Step 8 - This action takes place when MTLS is enabled and Validate Client FQDN is enabled. If MTLS is disabled, the Validate Client FQDN is also disabled. Validate Client FQDN is an enhanced security feature of
Unable to show "metadata-from": No such page "_space_variables" Configuration for MTLS
In order to configure
If you want to validate the client FQDN, you must enable Validate Client FQDN.
If you want to check and verify the TLS profile that was used, you must capture a debug log of the SIP subsystem at DEBUG level and search for the TLS Profile string. The example log below is when MTLS is enabled and client and server FQDN validation is disabled, for example when ITSP uses an IP address instead of a FQDN in the CN of the certificate:
Dump: TLS Client socket uses TLS Profile #1 'ITSP TLS Profile' {ver=TLS1, mutual=Yes, validate client:server FQDN=No:No, verify peer=Yes, cipher=AES128 & 3DES Sha, selfsigned=No