Just like the TLS (SSL) server certificate is used to verify the identity of the server to the client, clients can also present certificates to the server to help verify their identity. TLS (SSL) certificates presented by a client to the server are called Client Certificates. While most servers do not require clients to present their own certificates, many do as client certs provide an additional factor of authentication. MOVEit Transfer supports accepting or requiring client certs on both the FTPS 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 TLS (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 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 FTPS 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 Transfer, while matching one of the "credential" conditions allows the client to authenticate to MOVEit Transfer.

  • 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 that 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 TLS (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

In the example shown in the diagram, the authentication criteria are fixed, and a number of different client certs can be used for authentication.

  • MOVEit Transfer 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 that 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 FTPS 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, 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 the Microsoft Trusted Root Certificate Store of MOVEit Transfer.
  • Client Certs That Can Connect But Not Authenticate: All of these client certs "chain up" to a certificate installed in the Microsoft Trusted Root Certificate Store of MOVEit Transfer. 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 connect to a certificate installed in the Microsoft Trusted Root Certificate Store of MOVEit Transfer. 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

The increased security of client certificates involves increased administrative overhead. In MOVEit Transfer, to manage users with client certs, use the Edit SSL Client Certificates page, which is accessible from the User Profile.

To manage users with client certs:

  1. Select USERS > username. The User Profile (user name) page opens. Locate the User Authentication section.
  2. Under Credentials Required for Access click either the HTTP Policy or FTP Policy link. The Edit HTTP Policy page (or Edit FTP Policy page) opens.
  3. At the bottom of the page, click Edit SSL Client Certificates. The client certificate management page for the user opens.

    In the Current SSL Client Certificates... section, you can

    • Remove an existing cert. Click the X icon.
    • Add (manually)
    • Import from a file
    • Create New
    • Trusted CAs. Provides access to the list of trusted CAs and the organizational CA that is used to sign any client certificates created through the web interface

      In the Holding Tank section, you can accept or remove any pending certificate entries.