Navigation:  Actions > Network > FTP >

FTP Action Security Tab

Previous pageReturn to chapter overviewNext page

This tab of the FTP action specifies security settings for secure FTP connections.

 

Protocol: Security protocol to use when connecting to the remote server:

None: No security protocol will be used
SSL, TLS, or PCT: Either the SSL 2.0, SSL 3.0, PCT or TLS protocols will be used when establishing a secure connection. The correct protocol is automatically selected.
SSL: Either SSL 2.0 or SSL 3.0 may be used when establishing a secure connection. The correct protocol is automatically selected.
TLS: The TLS 1.0 protocol will be used when establishing a secure connection.
PCT: The PCT 1.0 protocol will be used when establishing a secure connection.
SSH: Either SSH 1.0 or SSH 2.0 will be used when establishing a secure connection, based on the version of the protocol that is supported by the server, and the SFTP protocol will be used for transferring files.
SSH v1: The SSH 1.0 protocol will be used when establishing the connection, and the SFTP protocol will be used for transferring files. This is an older version of the protocol which should not be used unless explicitly required by the server. Most modern SFTP server support version 2.0 of the protocol.
SSH v2: The SSH 2.0 protocol should be used when establishing the connection, and the SFTP protocol will be used for transferring files. This is the default version of the protocol that is supported by most SFTP servers.

 

Fallback to insecure ciphers: Specifies that the client should permit the use of less secure cipher suites for compatibility with legacy servers. If this option is specified, the client will allow connections using TLS 1.0 and cipher suites that use RC4, MD5 and SHA1.

 

Options: Options related to the security protocol (does not apply for SFTP):

Default: specifies that the client should attempt to establish a secure connection with the server. Note that the server must support secure connections using either the SSL, PCT or TLS protocols.
Explicit SSL: The client will first send an AUTH TLS command to the server. If the server does not accept this command, it will then send an AUTH SSL command. If both commands are rejected by the server, an explicit SSL session cannot be established.
Implicit SSL: Negotiates a secure session as soon as the connection is established and does not require a command.

 

Certificate Info

 

Location: The location to retrieve the certificate from (user store, machine store, or PFX file).

 

Store name/file: The name of the store to open or the PFX file to retrieve the certificate from (optional).

 

Certificate name: Friendly name of the certificate to use (optional).  Note that the name must match completely, but the comparison is not case sensitive. If no matching certificate is found, the action will then attempt to find a certificate that has a matching common name (also called the certificate subject). This comparison is less stringent, and the first partial match will be returned. If this second search fails, the action will return an error indicating that the certificate could not be found.

 

Password: The certificate password (applies only for certificates in a PFX file).

 

Note: Certificate info does not apply for SSH/SFTP.

 

Send commands unencrypted: If checked, the command channel used to send commands to the server and receive command result and status information from the server will not be encrypted.  This may be necessary to allow a secure FTP connection through a firewall.  Changing the mode for the data channel requires that the server support the PROT command. If this command is not supported by the server, the function will fail and the channel mode will remain unchanged.

 

Transfer data unencrypted: If checked, the channel used to transfer data with the server will not be encrypted.  Changing the mode for the data channel requires that the server support the PROT command. If this command is not supported by the server, the function will fail and the channel mode will remain unchanged.

 

Verify host fingerprint: If checked, the specified fingerprint will be compared with the fingerprint value returned by the server, and the step will fail if they do not match. Build the step once to determine the host key, then use the value from the build output here for future use (to prevent man-in-the-middle security attacks).  This option applies only for SSH/SFTP connections.