FAQ: Forum Sentry SSL Termination Policies Defined


As an API Security Gateway, Forum Sentry provides granular control for centralized SSL/TLS protection of your APIs running on application servers, web servers or message queues.  Forum Sentry typically sits in front of such components and deals with all the SSL related communication for your APIs so that you can focus on building business functionality while Forum Sentry takes the ownership of your security policies.

For incoming requests, Sentry uses SSL Termination Policies to terminate SSL connections from various types of clients. This article will provide detailed definitions of all of the options available within an SSL Termination Policy.

For information on troubleshooting SSL termination issues see: Troubleshooting SSL Termination Issues


SSL Termination Policies

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


Key Pair:  The Sentry key pair used with the SSL Termination policy.  The key pair is composed of a public and private key. The public key (the server's public certificate) is provided to the client during the “server hello” step of the SSL Handshake.  If the key pair contains multiple certificates (e.g. the server cert, intermediate signer certs, and a root CA cert) then all of them will be sent to the client. The client may optionally verify the server cert.

Authenticate the Client: Whether or not the server (Sentry) requires clients to provide a certificate for authentication.

When disabled, Sentry does not require the client to provide a certificate for authentication.

When enabled, Sentry requires the client to provide a certificate that will then be verified using a Signer Group.  The verification of the client certificate happens via X.509 certificate path validation (see definition in glossary below).

Signer Group:  Only available when ‘Authenticate the Client’ is enabled. This is the group of intermediate and root CA certificates that are used with the X.509 certificate path validation of an end user certificate. The default setting is the DEFAULT Signer Group which ships with Sentry and contains many commonly used public CA certificates. See full definition for Signer Group below.

Associate subject DN to a user: Only available when ‘Authenticate the Client’ is enabled. When enabled, the client certificate (after it is validated) is matched to a known user and restricted by the selected ACL policy.  This allows a user to be identified based on a client certificate and then authorized by the ACL.

Use user attribute only (cn or uid): Only available when ‘Associate subject DN to a user’ is enabled. When matching the client certificate to a user stored in an LDAP repository, this option enables matching based on the username attribute (cn or uid) defined on the LDAP policy(s) enabled in the selected ACL.

ACL Policy: Only available when ‘Authenticate the Client’ is enabled. This is the ACL policy that contains the local or external user groups (e.g. LDAP policies) used when matching the client certificate to a known user.

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 cipher suite category. For example, if you enable RSA, all RSA ciphers are selected below.

Cipher Suite: The cipher suites available for this SSL Termination 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 preferences, the null ciphers are available for selection.  The use of null ciphers is strongly discouraged and intended for troubleshooting only.


Forum Sentry SSL Termination 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 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 Termination policy in Sentry, SSL client authentication is enabled with the “Authenticate the Client” option.  When this option is enabled, Sentry will perform the X.509 Certificate Path Validation for the client certificate provided.

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".

Have more questions? Submit a request


Article is closed for comments.