3.11. TLS configuration

Multiple Radiator configuration clauses are built on top of common server and client stream modules. These modules support TCP and SCTP stream transport protocols and can optionally be configured to use TLS for transport security.
The exact behaviour of many of the configuration parameters, such as the search order between TLS_CAFile and TLS_CAPath, depends on the TLS library Radiator uses. This is typically OpenSSL but can be LibreSSL or any other TLS library that works with Net::SSLeay Perl module. For more information about Net::SSLeay and OpenSSL, see Section 2.1.6. Net::SSLeay and OpenSSL.
Important
System certificate store is not used. The TLS configuration parameters must cover all CAs, CRLs and other settings that are needed.
The default values for the TLS configuration parameters are the same for all configuration clauses unless otherwise stated.

3.11.1. TLS_Protocols

TLS_Protocols forces SSL or TLS for the configuration clause and specifies a comma-separated list of SSL and TLS protocols that are permissible for SSL and TLS connections. Currently, the supported SSL and TLS protocols are:
  • SSLv3
  • TLSv1
  • TLSv1.1
  • TLSv1.2
  • TLSv1.3
    CAUTION
    TLSv1.3 is not enabled by default with Radiator yet. Testing reports are welcome. Net::SSLeay 1.83 or later is required if you use Radiator with SSL/TLS library that has TLSv1.3 enabled. Net::SSLeay 1.92 or later is recommended.
When set, TLS_Protocols overrides UseSSL and UseTLS. Otherwise UseSSL and UseTLS control the allowed protocols, if set. TLS_Protocols is not set by default.
Here is an example of using TLS_Protocols:
# Allow connections with these TLS versions only
TLS_Protocols TLSv1.1, TLSv1.2
Note
SSLv3 is obsolete and may not be supported by the TLS library Radiator uses. Use of SSLv3 is strongly discouraged but it is available for communicating with legacy SSLv3 peers.

3.11.2. TLS_CAFile

When TLS is enabled, this parameter specifies the name of a file containing Certificate Authority (CA) root certificates that may be required to validate TLS peer certificates. The certificates must be in PEM format. The file can contain several root certificates for one or more Certificate Authorities. Radiator looks for root certificates for RadSec connections in TLS_CAFile then in TLS_CAPath, so there usually is no need to set both.

3.11.3. TLS_CAPath

When TLS is enabled, this parameter specifies the name of a directory containing CA root certificates that may be required to validate TLS peer certificates. Radiator looks for root certificates in TLS_CAFile then in TLS_CAPath, so there usually is no need to set the both. When Certificate Revocation List (CRL) checks are enabled, this directory is also used by TLS library to look for CRL files.

Setting up CAPath directory for certificates and CRLs

The CA certificates must be in PEM format, one per file. When a certificate is needed, it is looked up using a special file name. Similarly lookup is done for Certificate Revocation List (CRL) files when certificate revocation lists are enabled. CRL files must also be in PEM format. Recent OpenSSL versions have a built-in command rehash that creates a symbolic link or a copy of file with the special file name. OpenSSL also comes with an separate tool called c_rehash that does the similar job. LibreSSL has a built-in command certhash to create symbolic links.
Here's an example of a directory with a file containing two CA certificates, a CRL file and a file with a single CA certificate. Note that no symbolic link is created when the file with two CA certificates is processed. The certificates in it must be separate files or otherwise the certificates in cafile.pem can not be used.
% ls -la
drwxr-xr-x   5 mikem  staff   160 Dec 20 13:09 .
drwxr-xr-x  97 mikem  staff  3104 Dec 20 12:59 ..
-rw-r--r--   1 mikem  staff  9957 Dec 20 13:09 cas.pem
-rw-r--r--   1 mikem  staff  2383 Dec 20 13:02 root-CA-crl.pem
-rw-r--r--   1 mikem  staff  4992 Dec 20 12:59 root-CA-crt.pem

% openssl version    
OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)

% openssl rehash -v .
Doing .
rehash: warning: skipping cas.pem,it does not contain exactly one certificate or CRL
link root-CA-crt.pem -> 322a67d3.0
link root-CA-crl.pem -> 322a67d3.r0

% ls -la
drwxr-xr-x   7 mikem  staff   224 Dec 20 13:17 .
drwxr-xr-x  97 mikem  staff  3104 Dec 20 12:59 ..
lrwxr-xr-x   1 mikem  staff    15 Dec 20 13:17 322a67d3.0 -> root-CA-crt.pem
lrwxr-xr-x   1 mikem  staff    15 Dec 20 13:17 322a67d3.r0 -> root-CA-crl.pem
-rw-r--r--   1 mikem  staff  9957 Dec 20 13:09 cas.pem
-rw-r--r--   1 mikem  staff  2383 Dec 20 13:02 root-CA-crl.pem
-rw-r--r--   1 mikem  staff  4992 Dec 20 12:59 root-CA-crt.pem
Note
Similar LibreSSL command is (dot is one of the command parameters): openssl certhash -v .
Testing indicates LibreSSL does not ignore files with multiple certificates but creates one symbolic link. For more information these OpenSSL and LibreSSL commands, see https://www.openssl.org/docs/manmaster/man1/c_rehash.html Opens in new window and https://man.openbsd.org/openssl.1 Opens in new window

3.11.4. TLS_CertificateFile

When TLS is enabled, this parameter specifies the name of the file containing the certificate that Radiator uses. This certificate is sent to the TLS peer and validated by the peer during TLS setup. The certificate file must be in PEM or ASN1 format, depending on the setting of the TLS_CertificateType parameter. The certificate file can also contain the certificate's private key if the TLS_PrivateKeyFile parameter specifies the same file.
Note
RadSec clients expect the server certificate to have a common name (CN) the same as the RadSec servers DNS host name or address.

3.11.5. TLS_CertificateChainFile

When TLS is enabled, this parameter specifies the name of the file containing Radiator's certificate chain. The certificate chain is sent to the TLS peer and validated by the peer during TLS setup. The certificate chain must be in PEM format. This should be used alternatively or additionally to TLS_CertificateFile for explicitly constructing the certificate chain, which is sent to the peer in addition to the Radiator's own certificate.

3.11.6. TLS_CertificateType

When TLS is enabled, this optional parameter specifies the format of the TLS_CertificateFile. Permitted options are:
  • PEM
  • ASN1
The default is ASN1.

3.11.7. TLS_PrivateKeyFile

When TLS is enabled, this optional parameter specifies the name of the file containing the private key of the certificate configured with TLS_CertificateFile. It is sometimes in the same file as the TLS_CertificateFile. Usually the private key is encrypted, use TLS_PrivateKeyPassword is the key to decrypt it. For more information, see Section 3.11.4. TLS_CertificateFile and Section 3.11.8. TLS_PrivateKeyPassword.

3.11.8. TLS_PrivateKeyPassword

When TLS is enabled, this optional parameter specifies the password that is to be used to decrypt the TLS_PrivateKeyFile. Special characters are permitted.

3.11.9. TLS_Ciphers

TLS_Ciphers specifies which subset of cipher suites is permissible for a connection when TLSv1.2 or earlier is negotiated. The parameter format is the cipher list format documented in OpenSSL manual for openssl ciphers command. The default value is DEFAULT:!EXPORT:!LOW.
# Exclude cipher suites using RC4 too
TLS_Ciphers DEFAULT:!EXPORT:!LOW:!RC4
This parameter affects only TLSv1.2 and earlier TLS versions. For the respective parameter for TLSv1.3, see Section 3.11.10. TLS_Ciphersuites
When SSL library supports security levels, a level can be set for each configuration clause together with cipher string. For more information about security levels, see Section 3.11.11. TLS_SecurityLevel
# System default level 2 is too strict for this module
TLS_Ciphers DEFAULT:!EXPORT:!LOW@SECLEVEL=1

3.11.10. TLS_Ciphersuites

TLS_Ciphersuites specifies which subset of TLSv1.3 cipher suites is permissible for a connection. The parameter format is documented in OpenSSL manual for SSL_CTX_set_ciphersuites() API function. For example: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256. Usually there is no need to set this parameter. There is no default and the system default is used.
# This cipher suite is mandatory for TLSv1.3
TLS_Ciphersuites TLS_AES_128_GCM_SHA256 
This parameter affects only TLSv1.3. For the respective parameter for TLSv1.2 and earlier TLS versions versions, see Section 3.11.9. TLS_Ciphers

3.11.11. TLS_SecurityLevel

TLS_SecurityLevel is an integer parameter that sets the SSL library security level for the enclosing clause. Security levels were added in OpenSSL 1.1.0 and are detailed in OpenSSL manual page SSL_CTX_set_security_level. There is no default and the system default is used. This parameter may be needed if you see unexpected TLS errors with older TLS peers.
Security level can also set together with ciphers in which case TLS_SecurityLevel is not needed. For more information, see Section 3.11.9. TLS_Ciphers
# The default pn this system, 2, is too strict for our peers,
# lower it for this Radiator module
TLS_SecurityLevel 1

3.11.12. TLS_RequireClientCert

This is an optional flag, which is available only for servers. It specifies whether the server clause requires each client to present a valid client certificate during TLS handshake or not. If the client certificate is not a valid certificate, the TLS handshake fails and the TCP or SCTP connection is disconnected. Certificate validity is determined by the root certificates that are configured for the server clause with TLS_CAFile or TLS_CAPath, and other TLS configuration parameters, such as TLS_ExpectedPeerName and TLS_SubjectAltNameURI.
Note
For compliance with RFC 6614, TLS_RequireClientCert is enabled by default for ServerRADSEC.

3.11.13. TLS_Verify

TLS_Verify is an optional string parameter which is available only for TLS clients. It specifies whether the client clause requires the server to present a valid server certificate during TLS handshake or not. The default is to require and verify the server certificate. If the server certificate is not a valid certificate, the TLS handshake fails and the TCP or SCTP connection is disconnected. Certificate validity is determined by the root certificates that are configured for the client clause with TLS_CAFile or TLS_CAPath, and other TLS configuration parameters, such as TLS_ExpectedPeerName and TLS_SubjectAltNameURI.
When TLS_Verify is set to value none, the server certificate is not verified. This may be useful during testing but it's not recommended for production configurations. Here is an example of using TLS_Verify:
<AuthBy REST>
    # TLS and other parameters

    # While testing, skip certificate validation
    TLS_Verify none

    # More parameters
</AuthBy>

3.11.14. TLS_RandomFile

When TLS is enabled, this optional parameter specifies the name of a file containing randomness. Usually there is no need to set this parameter.

3.11.15. TLS_DHFile

When TLS is enabled, this optional parameter specifies the name of the DH group. Usually there is no need to set this parameter, but it may be required if you are using ephemeral DH keys.

3.11.16. TLS_ECDH_Curve

When TLS is enabled, this optional parameter enables ephemeral EC keying by specifying the name of the elliptic curve to use. The default is to not enable ephemeral EC keying.
# Curves often have multiple aliases. Need OpenSSL name here.
# openssl ecparam -list_curves
TLS_ECDH_Curve prime256v1

3.11.17. TLS_CRLCheck

When TLS is enabled for a server, or TLS server has been configured to check client certificates with TLS_RequireClientCert, this optional flag parameter specifies that Certificate Revocation List (CRL) must be checked for revoked certificates during validation of the peer certificate.

3.11.18. TLS_CRLCheckUseDeltas

This optional flag parameter specifies if Delta Certificate Revocation List must be checked for revoked certificates in addition to base CRL. Currently delta CRL files are loaded with TLS_CRLFile parameter, similar to base CRL files.
CAUTION
TLS_CRLCheckUseDeltas is currently experimental.
Before enabling TLS_CRLCheckUseDeltas, note the following requirements and restrictions:
  • TLS_CRLCheck must be enabled in Radiator configuration
  • Both base and delta CRLs must use CRL v2 format
  • Do not use delta CRL files without enabling TLS_CRLCheckUseDeltas
  • OpenSSL indicates only one delta CRL file can be used
  • Review OpenSSL notes about delta CRLs on OpenSSL manual page for X509_VERIFY_PARAM_set_flags. Opens in new window
  • Test that your base and delta CRL work when CRL files are updated or refreshed
Please contact Radiator support about success or possible problems there might be with delta CRLs.

3.11.19. TLS_CRLCheckAll

When TLS is enabled, this optional flag parameter enables CRL checks for the entire certificate chain. This is not enabled by default. The CRL files for the intermediate CAs must be found or the certificate check fails. For more information, see TLS_CRLFile.
Note
TLS_CRLCheck must be enabled for any certificate checks to happen.

3.11.20. TLS_CRLFile

This optional parameter specifies one or more CRL files that are used to check peer certificates for revocation when all the following conditions apply:
  • TLS is enabled.
  • TLS is configured to check peer certificates with TLS_RequireClientCert.
  • CRL checking is enabled with TLS_CRLCheck.
The CRL files are also used when TLS_CRLCheckAll is enabled.
If the CRL file is not found or the CRL says the certificate has been revoked, TLS authentication fails with an error:
SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
To ease automation, CRLs may follow a file naming convention where each CRL file uses a special file name in TLS_CAPath directory. Setting up this directory is described in Section 3.11.3. TLS_CAPath. In this case you do not need to configure TLS_CRLFile.
If CRLs are not stored in the CAPath directory, one or more CRLs can be named with multiple EAPTLS_CRLFile parameters. The intended way CRL reloading works is this: Each CRL file named with TLS_CRLFile will be automatically reloaded and reread at the start of each new TLS session if the modification date of the named CRL file has changed since the last time it was loaded. If the CRL for a particular issuer changes, it is sufficient to replace the existing CRL file with the newer version and Radiator will reload the new CRL when required.
Tip
Operating system wildcards are supported, so you can name multiple CRLs with a single wildcard like:
TLS_CRLFile %D/crls/revocations-*.pem

3.11.21. TLS_PolicyOID

When a TLS peer presents a certificate, this optional parameter enables the certificate policy checking and specifies one or more policy OIDs that must be present in the certificate path. It sets the 'require explicit policy' flag as defined in RFC3280. Using this parameter requires Perl Net::SSLeay 1.37 module or later. This parameter may be used for additional certificate validity checks, for example, with RadSec.
When multiple TLS_PolicyOID parameters are configured, the peer certificate needs to match only one of the configured OIDs, not all of them.
# Require just one policy
TLS_PolicyOID 1.3.6.1.4.1.9048.33.2

3.11.22. TLS_ExpectedPeerName

When a TLS peer presents a certificate, this optional parameter specifies a regular expression pattern that is required to match the Subject in the peer certificate.
The default value for servers, such as ServerRADSEC, is .+ which means to accept any Subject.
Different configuration clauses have different defaults for certificate validation. See the documentation of the specific configuration clause, such as <AuthBy RADSEC>, for the details.
Here is an example of using TLS_ExpectedPeerName:
# Accept certificates with CN ending in .xyz.com
TLS_ExpectedPeerName CN=.*\.xyz\.com

3.11.23. TLS_SubjectAltNameURI

When a TLS peer presents a client certificate, this optional parameter specifies a regular expression pattern that must match against at least one subjectAltName of type URI in the peer certificate.
There is no default value and no subjectAltName checks are done.
Different configuration clauses have different defaults for certificate validation. See the documentation of the specific configuration clause, such as <AuthBy RADSEC>, for the details.
Here is an example of using TLS_SubjectAltNameURI:
# Accept certificates that have a subjectAltName type URI that 
# ends in open.com.au:
TLS_SubjectAltNameURI .*open.com.au

3.11.24. TLS_SubjectAltNameDNS

This optional parameter is used only by TLS clients. When a TLS server presents a certificate, this defines an FQDN that matches against a subjectAltNameDNS of type DNS in that certificate. Currently, this is not a regular expression but this is subject to change.
By default, the TLS client checks if the server certificate contains a subjectAltName extension of type IPADDR or DNS that matches the Host name used to connect to the server. When subjectAltNameDNS is configured, type DNS values are checked against the value configured with subjectAltNameDNS. This parameter has no default value.
Here is an example of using TLS_SubjectAltNameDNS:
# Host is set to an IP address so we set the expected name here
TLS_SubjectAltNameDNS test.server.open.com.au

3.11.25. TLS_CertificateFingerprint

You can require that the peer matches one of a specified set of signatures with TLS_CertificateFingerprint. When a TLS peer presents a certificate, this optional parameter specifies one or more fingerprints, one of which must match the fingerprint of the peer certificate. The format is algorithm:fingerprint. No fingerprint checks are done by default. Using this parameter requires Net::SSLeay 1.37 or later.
Here is an example of using TLS_CertificateFingerprint:
TLS_CertificateFingerprint \
    sha-1:8E:94:50:0E:2F:D6:DE:16:1D:84:76:FE:2F:14:33:2D:AC:57:04:FF
TLS_CertificateFingerprint \
    sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
TLS_CertificateFingerprint \
    sha-256:EC:14:77:FA:33:AD:2C:20:FF:D2:C8:1C:46:31:73:04:28:9E:ED:\
           12:D7:8E:79:A0:24:C0:DE:0B:88:A9:DB:3C
TLS_CertificateFingerprint md5:2A:2D:F1:44:40:81:22:D4:60:6D:9A:B0:F4:BF:DD:24

3.11.26. TLS_CertificateVerifyHook

This optional parameter specifies a Perl function that will be called for a custom verification of the peer certificate. It is passed the certificate, and various other details, and returns 0 for verification success, a new verification result code or < 0 for a failure, or an undefined value to continue Radiator builtin certificate verification.
Note
This parameter is currently available only for servers such as ServerRADSEC.
The function is passed the following arguments:
  • $_[0]: $hostname, for servers, such as ServerRADSEC, the peer's IP address
  • $_[1]: $x509_store_ctx, the OpenSSL store context (you can pass this to Net::SSLeay::X509_STORE_CTX_get_current_cert)
  • $_[2]: $cert, the current certificate, result of Net::SSLeay::X509_STORE_CTX_get_current_cert($x509_store_ctx)
  • $_[3]: $subject_name, the certificates subject name, result of Net::SSLeay::X509_get_subject_name($cert)
  • $_[4]: $subject, the certificate subject, result of Net::SSLeay::X509_NAME_oneline($subject_name)
  • $_[5]: $object, the Stream object created for this connection
<ServerRADSEC>
    ...
    # Accept immediately all certificates with O='OSC Demo Certificates'
    TLS_CertificateVerifyHook sub { my $subject = $_[4]; \
        my ($org) = $subject =~ /O=([^\/]*)/; \
        return unless $org eq 'OSC Demo Certificates'; return 0; }

</ServerRADSEC>

3.11.27. TLS_CertificateVerifyFailedHook

This optional parameter specifies a Perl function that will be called if verifying the peer certificate fails. It is passed the certificate (if present), and various other details.
The peer certificate $cert is not always present. An example of such case is a policy OID mismatch .
Note
This parameter is currently available only for servers such as ServerRADSEC.
TLS_CertificateVerifyFailedHook is passed the following arguments:
  • $_[0]: $verify_error
    This is the OpenSSL store context verification code.
  • $_[1]: $x509_store_ctx
    This is the OpenSSSL store context.
  • $_[2]: $cert
    This is the current certificate. May be undefined.
  • $_[3]: $subject_name
    This is the certificate's subject name. Undefined when $cert is undefined.
  • $_[4]: $subject
    This is the certificate subject. Undefined when $cert is undefined.
  • $_[5]: $object
    This is the Stream object created for this connection.
TLS_CertificateVerifyFailedHook must return a single value. This value is used as an OpenSSL error code to set the verify result code as follows:
  • > 0: Non-zero error code
    This is a new verification result code.
  • 0
    This changes verification failure to verification success.
  • < 0
    The verification process is immediately stopped with "verification failed" state.
  • Undefined
    This is handled as an OpenSSL error X509_V_ERR_APPLICATION_VERIFICATION.
Here are examples of using TLS_CertificateVerifyFailedHook.
<ServerRADSEC>
    ...
    # Accept all certificates
    # TLS_CertificateVerifyFailedHook sub { return 0; }

    # Allow expired certificates: 10 is X509_V_ERR_CERT_HAS_EXPIRED
    TLS_CertificateVerifyFailedHook sub { \
        if ($_[0] == 10) { return 0; } else { return $_[0]; } }

</ServerRADSEC>
Note
This parameter may cause security issues if not used properly. Use it only in special cases.

3.11.28. TLS_SRVName

TLS_SRVName is intended for use by <AuthBy RADSEC> and <AuthBy DNSROAM> to specify a DNS SRV Name that is matched against possible SubjectAltName:SRV extensions in the peer certificate. If TLS_SRVName is specified and the peer certificate contains SubjectAltName:SRV extensions, none of which match TLS_SRVName, the certificate is not accepted.
Format is _service._transport.name (this is the same format SRV names appear in DNS records). Only service and name are matched.
TLS_SRVName _radsec._tcp.example.com

3.11.29. TLS_UseCADefaultLocations

This is a flag parameter. When set, the default locations are used for loading CA certificates. This is not set by default.
The default CA certificate directory is certs/ in the default OpenSSL directory. Use SSL_CERT_DIR environment variable to override the default location. The default CA certificate file is cert.pm in the default OpenSSL directory. Use SSL_CERT_FILE environment variable to override the default file name.

3.11.30. TLS_CAPartialChain

This is a flag parameter. When set, only a partial CA certificate chain is required to validate TLS peer certificates. This functionality is required when restricting valid CA certificates to only a subset of CA hierarchy. This is not set by default.

3.11.31. TLS_NoClientCert

This is a flag parameter. When set, it turns off any client certificate checks and disables loading of any CA certificates for client certificate verification. This allows you to simplify configuration when client certificates are not requested with TLS_RequireClientCert.

3.11.32. TLS_OCSPCheck

This flag defines if Online Certificate Status must be checked for revoked certificates. Using this parameter requires LWP::UserAgent and HTTP::Request Perl modules.
Here are the requirements for using OCSP parameters:
  • OpenSSL 1.0.0 or later
  • Net::SSLeay 1.59 or later. Net::SSLeay 1.82 or later is recommended.
    If you use TLS_OCSPStapling, Net::SSLeay 1.82 or later is required.

3.11.33. TLS_OCSPStapling

This flag specifies that Online Certificate Status of our own certificate must be checked and returned to the peer as OCSP staple when running as a server. When running as a client, it requests OCSP staple. Using this parameter requires LWP::UserAgent and HTTP::Request Perl modules.
Using TLS_OCSPStapling does not require that TSL_OCSPCheck is set, but the same requirements apply when you use only TLS_OCSPStapling. See the requirements list in Section 3.11.32. TLS_OCSPCheck.

3.11.34. TLS_OCSPURI

This string defines OCSP URI that is used for all OCSP queries.

3.11.35. TLS_OCSPFailureBackoffTime

If the OCSP query fails, the query is not sent again to the failed OCSP URI. This integer defines the time for how long the failed OCSP URI is not contacted. The unit is seconds.

3.11.36. TLS_OCSPStrict

This optional flag parameter defines if Online Certificate Status must be checked successfully, otherwise the peer certificate is rejected.
When TLS_OCSPStrict is set, the certificate check must be successful in all phases. Here are some examples when the certificate check fails if TLS_OCSPStrict is set:
  • TLS_OCSPURI is not set and the certificate does not have OCSP URI.
  • OCSP responder is not responding.
  • OCSP responder cannot be reached.

3.11.37. TLS_OCSPCacheTime

This integer defines the time for how long OCSP replies are saved in the cache. The unit is seconds. The default value is 1200, that is 20 minutes.

3.11.38. TLS_OCSPCacheSize

This integer defines the maximum number of OCSP cache entries. The default value is 1000.

3.11.39. TLS_KeylogFilename

Sets the name of file Radiator uses for logging TLS key material. TLS key log allows fully decrypting EAP and Stream SSL/TLS sessions, including those that have forward security enabled. TLS keylog should only be used for debugging to avoid security issues.
The keylog file is written in NSS Key Log Format, also known as SSLKEYLOGFILE. Tools, such as Wireshark, can read this file and fully decrypt TLS, including TLS sessions that have forward security enabled.
# Enable when debugging, remove when in production
TLS_KeylogFilename %L/radsec-keylog
DANGER
Keylog should only be used for debugging to avoid security issues.

3.11.40. TLS_TraceState

TLS_TraceState is a flag parameter that turns on TLS state tracing for TLS-based Stream modules, such as AuthBy RADSEC, ServerRADSEC and HTTP Client. This may be useful for additional debugging of TLS handshake processing. TLS_TraceState is not set by default.
Radiator 4.27 with Net::SSLeay 1.92 and later automatically enables TLS handshake message logging when log level is set to DEBUG or higher with Trace or PacketTrace parameter. When TLS message logging is enabled, TLS state tracing can also be enabled by setting TLS_TraceState. TLS state and messaging logging contain similar information and in most cases it's not useful have them both enabled.
Here is an example of using TLS_TraceState:
# Turn on TLS state tracing for this ServerRADSEC
TLS_TraceState

3.11.41. UseTLS

This optional parameter forces the use of TLS for a configuration clause. When this parameter is enabled, the TLS_* parameters are available for use. For compliance with RFC 6614, it is enabled by default for RadSec clauses and <AuthBy DNSROAM>.
CAUTION
This option is obsolete. UseTLS enables TLSv1 only. For more information about the current preferred method of setting up TLS versions and parameters, see Section 3.11.1. TLS_Protocols and Section 3.11.9. TLS_Ciphers.
Here is an example of using UseTLS:
UseTLS

3.11.42. UseSSL

This optional parameter forces the use of SSLv3, TLSv1.1, or TLSv1.2 for the configuration clause. The availability of TLS versions depends on if the TLS library supports them. When this parameter is enabled, the TLS_* parameters become available for use.
CAUTION
UseSSL is obsolete and use of SSLv3 is strongly discouraged. For more information about the current preferred methods of setting up TLS versions and parameters, see Section 3.11.1. TLS_Protocols and Section 3.11.9. TLS_Ciphers.
Here is an example of using UseSSL:
UseSSL

3.11.43. TLS_SessionResumption

This is a flag that allows you to enable or disable support for TLS session resumption.
CAUTION
This parameter is obsolete. TLS Session resumption is not currently supported for the stream modules.

3.11.44. TLS_SessionResumptionLimit

This is an integer that specifies the limit how long (in seconds) after the initial session that a TLS session can be resumed.
CAUTION
This parameter is obsolete. TLS Session resumption is not currently supported for the stream modules.