FAQ: Forum Sentry SSL Initiation Policies Defined


When Sentry initiates a connection to a remote server that requires a secure connection (TLS), an SSL Initiation Policy is used. This article provides detailed definitions of all of the options available within an SSL Initiation Policy.


SSL Initiation Policies

The image below shows the options of an SSL Initiation Policy with v8.3 of Forum Sentry. Note that earlier releases may not include all of the functionality listed below.


Authenticate to Remote Server using Key Pair: If the remote server is validating the client's certificate that Sentry provides as part of the SSL handshake, a key pair needs to be specified here.  The public certificate is provided to the server for validation. If the server does not require client authentication, set this to ‘Authentication not required’.

Authenticate the Remote Server using Signer Group: The Signer Group used for X.509 certificate path validation of the server certificate provided to Sentry during the SSL handshake. This validation is enabled by default using the DEFAULT Signer Group that ships with Sentry. The DEFAULT Signer Group contains many commonly used public CA certificates.  Validation of the server certificates is strongly recommended, though it can be disabled by setting this option to ‘Do not Authenticate’.

Ignore Server Hostname Verification: Only enabled when ‘Authenticate the Remote Server using Signer Group’ is enabled. This option disables the DNS hostname verification of the provided server certificate. Server hostname verification via DNS is strongly recommended and enabled by default.

Protocols: The list of available TLS / SSL protocols for the SSL Termination policy. Forum Systems recommend using TLSv1.2 and TLSv1.1 only.

Cipher Suite Filters: Enables auto select / deselect of cipher suites based on the cipher suite category. For example, if you enable RSA, all RSA ciphers are selected below.

Cipher Suite: The cipher suites available for this SSL Initiation policy. See definition of ciphers suites below.

Cipher Suites with Known Vulnerabilities: A grouping of cipher suites with known vulnerabilities, which are not recommended for use but available for increased interoperability with legacy systems.

Null Ciphers: Sentry allows for using null ciphers with SSL policies, though the option is hidden by default. To enable the use of null ciphers, first enable this option under the User Preferences under the System Settings. Once enabled under the User Preferences, the null ciphers are available for selection.  The use of null ciphers is strongly discouraged and intended for troubleshooting only.


Forum Sentry SSL Initiation Glossary

CA - Certificate Authority, responsible for issuing digital certificates that are used with TLS/SSL among other things. CAs may be public (Verisign, Entrust, Thawte, DigiCert, etc...) or private. Typically a Sentry admin will generate a key in Sentry, creating either a self-signed certificate or a certificate signing request (CSR), which is then provided to the CA to be signed.  Sentry can also act as a CA.

Cipher Suites - A cipher suite is a named combination of authentication, encryption, and message authentication code (MAC) algorithms used to negotiate the security settings for a network connection using the TLS/SSL protocol. In Sentry, there are many cipher suite options, and administrators can choose to enable or disable specific cipher suites, including null ciphers.

Key Pair - In Sentry, a Key Pair is a private key with the corresponding public certificate.

Self-Signed Certificate - A self-signed certificate is an identity certificate that is signed by the same entity whose identity it certifies. All Root CA Certificates are self-signed certificates. To determine if a certificate is self-signed, check to see if the issuer of the certificate is the same as the subject.  Sentry can generate self-signed certificates.

Signer Groups - In Sentry, a Signer Group contains the intermediate and root CA certificates that are used for X.509 certificate path validation of an end user certificate. Other options within a Signer Group are certificate revocation (CRL Policies) and an option to send the client a "hint" or list of the CA certificates in the Signer Group during the SSL handshake (Send Accepted Issuers). Signer Groups are used with SSL policies, signature verification policies, and encryption policies in Sentry.

SSL Client Authentication – With an SSL Initiation policy Sentry is the SSL client connecting to the SSL server. If the server requires client authentication, a key pair needs to be specified in the 'Authenticate to Remote Server using Key Pair' option.

SSL Mutual Authentication – SSL mutual authentication refers to both parties (the client and the server) authenticating each other during the SSL handshake. With SSL Termination Policies in Sentry, the public certificate of the selected key pair is provided to the client as the server certificate for validation. This is the server authentication piece of the mutual authentication. The client certificate provided to Sentry is validated against the specified Signer Group. This is the client authentication piece of the mutual authentication.  SSL mutual authentication is sometimes referred to as two-way authentication, 2 way SSL, or mutual SSL.

TLS/SSL Handshake - This term refers to the process by which a client and server establish a secure TLS/SSL tunnel that data will then be transmitted over. For more details and the specific steps of the handshake see: http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake

X.509 Certificate Path Validation - Path validation in Sentry involves processing public key certificates and their issuer certificates in a hierarchical fashion until the certification path terminates at a trusted, self-signed certificate (the root CA certificate) where the subject is the same as the issuer. If there is a problem with one of the certificates in the path, or if Sentry cannot find a certificate in the trust chain, the certification path is considered a non-trusted certification path and Sentry will fail the SSL handshake.  A typical certification path includes a root certificate and one or more intermediate certificates.  Sentry will use the end user certificate and any intermediate certificates provided during the SSL handshake to build the trust chain; however, the root CA certificate has to exist in a Sentry signer group. The Forum Sentry X.509 Path validation has been certified by the US Department of Defense per compliance to RFC 3280 "Internet X.509 Public Key Infrastructure".


Article is closed for comments.