System Configuration - SSL and SSH - SSL - Client Certs - Overview

Just like the SSL server certificate is used to verify the identity of the server to the client, clients can also present SSL certificates to the server in order to help verify their identity. SSL certificates presented by a client to the server are called Client Certificates. While most SSL servers do not require clients to present their own certificates, more and more servers are starting to, as client certs provide an additional factor of authentication. MOVEit DMZ supports accepting or requiring client certs on both the FTP/SSL and HTTPS interfaces.

As is the case with almost any client key/certificate scheme, the higher security offered by cryptographic-quality client certificates is offset by additional administrative work. The SSL server must typically be configured to require client certificates or not (though IIS is able to accept client certificates if they are present, but still allow connections when they are not), and the client certificate must be trusted by the server in order for the connection to continue. Trusting a client certificate, like trusting a server certificate, requires either the certificate itself to be trusted, or the certificate be signed by a trusted Certificate Authority.

Client Certificate Connect/Authenticate Criteria

To use a client cert to authenticate a specific user to either the FTP/SSL or HTTPS interfaces, at least one of the following "CA" conditions and one of the following "credential" conditions must BOTH be true. Client certs must match one of the "CA" conditions in order to actually connect to MOVEit DMZ, while matching one of the "credential" conditions allow the client to authenticate to MOVEit DMZ.

• CA Conditions
  • The client cert itself must be installed in the Microsoft Trusted Root cert store.
  • The client cert must be signed by a CA cert which is trusted, either because the CA cert itself is installed in the Microsoft Trusted Root cert store, or a CA in the signing chain is installed in the Microsoft Trusted Root cert store.
• Credential Conditions
  • The client cert's thumbprint must be assigned to the specific user's profile.
  • The client cert's common name (CN) must be assigned to the specific user's profile AND the client cert's CA must be in the org-level list of approved CAs.
  • The client cert's common name (CN) must match the username or fullname of the specific user, the org-level "Match Cert CN to Username/Full Name" option must be enabled, AND the client cert's CA must be in the org-level list of approved CAs.

Client Certificate Connect/Authenticate Example - Fixed Cert, Flexible Criteria

To illustrate how these conditions would apply to a real certificate, consider a client certificate with the following characteristics.

• CN = "Frank"
• Thumbprint = "3D17 CFF3 E27B 127D 2753 A7F1 873E 2743 783B FBD2"
• Signed by CA cert with CN = "Chug and Ring"
• The CA cert has been signed by another CA cert with CN = "Toot"

To use this certificate to connect and authenticate a specific user, one of the following "CA" conditions and one of the following "credential" conditions must be true.

• To allow an SSL connection to occur, one of the following CA conditions must be true:
  • The "Frank" cert has been installed in the Microsoft Certificate Trusted Root cert store.
  • The "Chug and Ring" CA cert has been installed in the Microsoft Certificate Trusted Root cert store.
  • The "Toot" CA cert has been installed in the Microsoft Certificate Trusted Root cert store.
• To allow the client certificate to serve as a valid credential for a specific user, one of the following "credential" conditions must be true:
  • A thumbprint of "3D17 CFF3 E27B 127D 2753 A7F1 873E 2743 783B FBD2" has been assigned to the specific user's profile.
  • A CN of "Frank" has been assigned to the specific user's profile AND "Chug and Ring" has been added to the org-level list of approved CAs.
  • The specific user's username or full name is "Frank", the org-level "Match Cert CN to Username/Full Name" option has been enabled, AND "Chug and Ring" has been added to the org-level list of approved CAs.

Client Certificate Connect/Authenticate Example - Flexible Cert, Fixed Criteria

The following diagram provides an example in which the authentication criteria are fixed and a number of different client certs may be used for authentication. Please take a moment to find the following sections on the diagram:

• MOVEit DMZ Server: The three important stores of certification information and an important setting are pictured.
  • User Profile (Accepted Certs) of "Rich": Several thumbprints are listed here, as is the alternate CN of "Dick". ("Rich" is also an allowed CN because the "Match CN to Username/Fullname" option is checked.)
  • Trusted CAs: Certificates which present a CN for authentication must be signed by one of these CAs. Notice that one CA ("Verisign") is listed as trusted but certificates signed with this CA will fail to connect anyway because the CA is not installed in the Microsoft Trusted Root Certificate Store.
  • Microsoft Trusted Root Certificate Store.: This is the only place client certificate information is installed (rather than referenced). All client certs must be signed by CA in this store (or be installed themselves) before any FTP/SSL connection will work.
  • Match CN to Username/Fullname: See "User Profile..." above.
• Third-Party CAs: A selection of third-party CAs and some "reseller" CAs whose signing certificates have been signed by a "root-level" CAs.

Given this configuration, various client certificates will connect and authenticate with various degrees of success, depending on the CN, Thumbprint and CA associated with each certificate. (Self-signed certificates are indicated by a large black bar where most other certificates list the name of their CA.)

• Client Certs That Cannot Connect: These client certs do not "chain up" to any certificate installed in MOVEit DMZ's Microsoft Trusted Root Certificate Store.
• Client Certs That Can Connect But Not Authenticate: All of these client certs "chain up" to a certificate installed in MOVEit DMZ's Microsoft Trusted Root Certificate Store. However, these certificates are not registered properly for authentication because:
  • The certificate has a matching CN but its CA is not a Trusted CA.
  • The certificate's thumbprint does not match a user profile thumbprint.
• Client Certs That Can Connect And Authenticate: All of these client certs "chain up" to a certificate installed in MOVEit DMZ's Microsoft Trusted Root Certificate Store. All of these certificates also authenticate properly because:
  • The certificate has a matching CN and has been signed by a Trusted CA.
  • The certificate's thumbprint matches a user profile thumbprint.

Client Certificate Administration

As said above, the tradeoff for the increased security of client certificates is increased administrative overhead, however MOVEit DMZ tries to make it as easy as possible to manage users with client certs. Administration of client certs is done via the Edit SSL Client Certificates page, which is accessible from the User Profile. On the user profile page, click either the HTTP Policy or FTP Policy links...

...then click on the Edit SSL Client Certificates link...

This will take you to the client certificate management page for the user.

From here, existing cert entries may be removed, new ones added manually, imported from a file or created from scratch A "Trusted CAs" link also provides quick access to the list of trusted CAs and the organizational CA used to sign any client certificates created through the web interface. The section at the bottom of the page also allows any pending Holding Tank entries to be accepted or removed.