MOVEit Transfer uses the TLS and SSH standards to securely transport data between itself and various clients. MOVEit Transfer acts as server during all these transfers, so MOVEit Transfer is required to have an TLS/SSL server certificate (sometimes referred to as "cert" or "X.509 certificate") and an SSH server key.

Client certificates and client keys are OPTIONAL pieces of information which can be used in place of, or in addition to, a password to authenticate a particular user. Client certificates may be used with the two TLS (SSL) interfaces (HTTPS and FTPS) and client keys may be used with the SSH interface. In certain cases, client certificates will be stored on hardware tokens of some kind.

The sections in this topic describe the components and refer to other sections of the documentation that provide detailed setup information.

Also, the following procedures are also useful when getting started:

TLS (SSL) Server Certificates

TLS server certificates are usually obtained from Comodo, Thawte, Verisign or any other of the many commercial Certificate Authorities ("CAs") in the market. Self-generated certs may also be used, but the advantage of using a cert from a commercial CA is that many popular browsers, including IE and Firefox, will automatically trust your site (display the lock in the corner). Otherwise, your clients will need to explicitly opt to trust your certificate.

MOVEit Transfer server certs are configured in two places:

  • HTTP/TLS (web) - A certificate must be assigned to your MOVEit Transfer web site via the Microsoft Internet Services Manager application. ([Site] Properties menu, Directory Security tab, Secure Communications section)
  • FTP/TLS - The same certificate must also be assigned to your MOVEit Transfer FTP site via the MOVEit Transfer Config application. (FTP Certs tab)

TLS (SSL) Client Certificates

Users may be required to present a TLS client certificate during the signon process when using either the HTTPS or FTP/TLS interfaces. Complete information may be found in Client Certs - Overview and FTP - Configuration (Require Client Certificates).

SSH Server Keys

SSH keys do not have any relationship to a signer, so the MOVEit Transfer SSH server simply generates its own key the first time it runs.

You may view the fingerprint of your SSH key at any time via the MOVEit Transfer Config application. (SSH tab)

SSH Client Keys

Any SSH user may be required to present an SSH client key during the signon process. Complete information may be found in SSH Keys - Client Keys - Overview.

Relative Security of Passwords, Keys and Certificates

To protect passwords, MOVEit Transfer includes password strength requirements, password aging, per-user IP restrictions, per-user session restrictions, automatic lockouts and the use of TLS and SSH encrypted channels to securely transmit passwords.

Client certificates ("certs") and keys are typically tied to specific computers or hardware tokens. To misuse these credentials, an attacker must typically gain control of a desktop/laptop machine (for an installed key/cert) or possess a hardware token. All client certs and client keys rely on "public key / private key" cryptography. Under this model, gaining possession of a particular user's private key is often enough to act as that user. MOVEit Transfer does not work directly with the private key halves of client cert/keys, which avoids private key protection issues.

Because of weaknesses of passwords and client cert/keys, users are commonly required to authenticate with both a password and a client cert/key. To defeat this scheme, an attacker must possess a user's password and access to that user's private key. This "two factor" level of compromise is harder for an attacker to achieve than password or cert/key compromise alone.

Difference Between Keys and Certificates

The main difference between SSH keys and (X.509) TLS certs is that SSH keys are standalone credentials, while TLS certs must be verified.

SSH servers (MOVEit Transfer included) associate specific SSH client keys to specific users. If a SSH client presents an SSH key and it matches the one stored on the user record, the SSH client key will be authenticated.

TLS servers (MOVEit Transfer included) also associate specific TLS client certs to specific users, but SSL servers perform an additional background check on incoming TLS client certs. TLS client certs are signed (issued) by Certificate Authorities (CA). TLS servers maintain a list of CAs that they trust. If an TLS server receives a valid TLS client cert, but the client cert's CA is not trusted, the TLS server rejects the connection.

Configuring TLS authentication is more complicated than configuring SSH authentication.

Required Credentials

MOVEit Transfer users may authenticate with passwords, client keys (SSH only) or client certificates (HTTPS and FTP/TLS). Options on each user profile can be used to enforce exactly which combinations are allowed. (Default settings are available at the organization level.) The possible settings are:

  • Password Only (Any key/certificate is ignored)
  • Key/Cert Only (Any password is ignored)
  • Password OR Key/Cert (If either credential matches, the other is ignored)
  • Password AND Key/Cert (See also "Two-Factor Authentication")

Two-Factor Authentication

Systems that require "two-factor authentication" require the following items:

  • Statement of Identity (typically a username)
  • Unique Credential #1 (typically a password)
  • Unique Credential #2 (typically a client certificate or client key)

MOVEit Transfer supports "two-factor authentication" on its HTTPS and FTP/TLS interfaces with client certificates and on its FTP over SSH interface with client keys. To force this requirement on a particular user, the following user-level options MUST be enabled on each interface.

  • Require client key/certificate
  • Require password if a key/certificate is presented

Many FTP/TLS clients work with two-factor settings ("Password And Cert") in both interactive and batch modes. However, the most popular SSH client (OpenSSH) will only work in interactive mode when two-factor settings are applied (OpenSSH requires a one-factor Key Only or Password OR Key setting while in batch mode.)