Configuration Procedures

The following procedures describe how to configure Control-M MFT additional functionality:

  • FTP over SSL/TLS Configuration

  • Configuring Connection Details for a Remote Windows Server

  • Configuring LDAP with SSL

  • Configuring an FTP Firewall in Active and Passive Mode

  • Configuring an SFTP Firewall

  • Adding Users to Local Security Policies

  • Extending the Timeout Period in Control-M/EM

  • Extending the Timeout Period in Control-M/Server

  • Configuring Control-M in the aft_configurable.properties File

    Control-M MFT Security

    The following table lists the available options you can use to secure and encrypt connections in Control-M MFT:

    Option

    Description

    PGP encryption

    For push or pull actions (where the File Transfer job initiates a connection to a remote server directly and uploads or downloads a file), you can use PGP templates in File Transfer jobs to encrypt a file before uploading to remote server, or decrypt it after downloading to a local host. For more information, see PGP Template Management.

    BMC does not provide the PGP utility. You must install it separately.

    For incoming files from external partners (where they initiate the connection to the Control-M MFT Enterprise Gateway and upload an encrypted file to the Hub), you can either use processing rules or File Watcher jobs to decrypt. For more information, see Creating an MFT Enterprise Post Processing Rule.

    • Defines a rule with the condition files from a specific partner that has a PGP extension and that runs a script that decrypts them so that they are decrypted in the Hub's file system.

    • Defines a file watcher job that watches the specific folder, downloads the file locally, and decrypts it. This can be followed by another job that sends the decrypted file to an application that can process it.
    SFTP (SSH)

    MFT Client:

    • Uses libraries that depend on JCE

    • Generates a key pair (RSA or ECDSA type)

    • The private/public keys are stored in a local file system, with rw permission only for the Control-M /Agent account.

    • The public key must be stored in a remote SSH server’s authorized_keys file.

    • File Transfer jobs support both password and key authentication.

    • Fingerprints of remote servers (hostkeys) are stored in a local file (known_hosts) to allow verifying remote host after connecting.

    • By default, the first connection is accepted, and block future connections if the host key has changed. This behavior can be changed.

    Supported Algorithms:

    • Cipher:blowfish-cbc,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,arcfour,arcfour128,arcfour256,[email protected], [email protected], [email protected]

    • Key exchange: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,, diffie-hellman-group14-sha256, diffie-hellman-group15-sha512, diffie-hellman-group16-sha512, diffie-hellman-group17-sha512, diffie-hellman-group18-sha512, curve25519-sha256, [email protected], curve448-sha512

      MAC: hmac-md5, hmac-sha1, hmac-md5-96, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512, [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]

    • Host key type: ssh-dss,ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519* supported only if the Java version is 15 or higher, rsa-sha2-512, rsa-sha2-256, ssh-ed448* supported only if the Java version is 15 or higher.

    MFT Server:

    • FTS/Hub accepts clients with both password and/or key authentication.

    • FTS/Hub also has authorized_keys file where the Administrator can add other user keys for remote users to connect.

    • Supported SSH key types are: ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nist521, and ssh-ed25519

    Supported algorithms:

    • Cipher: aes128cbc, aes128ctr, aes192cbc, aes192ctr, aes256cbc, aes256ctr, arcfour128, arcfour256, blowfishcbc, tripledescbc, [email protected], [email protected], [email protected]

    • Key exchange: diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha1, diffie-hellman-group14-sha256 , diffie-hellman-group15-sha512, diffie-hellman-group16-sha512, diffie-hellman-group17-sha512, diffie-hellman-group18-sha512 , ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, curve25519-sha256, [email protected], curve448-sha512

    • MAC: hmac-md5, hmac-md5-96, hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512, [email protected], [email protected], [email protected]

    SSL/TLS

    • File Transfer jobs and FTS support FTP connection over SSL (FTPS)

    • Hub supports HTTPS

    • SSL/TLS is supported in Encryption only, Server Authentication only, and Both Server and Client authentication.

    • Supports TLS1.2 and TLS1.3.

    • FTP Client supports both Explicit/Implicit SSL, CCC/CDC.

    • Several keystore files for storing remote servers’ CA x.509 certificates and a few keystores for the server to store its and clients certificates and keys (for different protocols: FTPS, HTTPS, AS2) Supports PKCS12 and BCFKS keystore formats.

    • For FTPS, we support more than 70 different ciphers by default. On FIPS mode, some ciphers are disabled.

    Secured data in configurations

    • MFT secure data is stored encrypted with AES256-GCM (local key that can be rotated)

    • Secure data is also transferred encrypted with AES256-GCM

    • External user passwords are stored hashed (cannot be decrypted)

    • Control-M components can communicate over SSL

FTP over SSL/TLS Configuration

To configure your support for FTP over SSL/TLS, do the following to define jobs with Control-M MFT via an FTP over SSL/TLS server:

SSL Security Levels

The following table describes the SSL security levels:

Security Level

Authentication

Client certificate

Security
2 No authentication Not sent Low
3 Sever authentication Not sent Moderate
4 Server and client authentication Sent High

You can define the host security level in a connection profile utility, as described in FTP Protocol Parameters.

Control-M MFT Authentication

An SSL certificate is a small data file that digitally binds a cryptographic key to an organization's details and is used to authenticate a connection between a client and server.

The following procedures describe how to configure Control-M MFT for server and client configuration:

To authenticate the identity of the server and the server to authenticate the client, you must complete both procedures.

Control-M MFT uses a Java Keytool as key and certificate management utility. It allows you to manage your own public/private key pairs and certificates. Java Keytool stores the keys and certificates in a keystore and protects the private keys and keystore with the same password.

The Java Keytool utility path is <Agent home directory>/cm/AFT/JRE/bin/keytool. Each certificate in a Java keystore is associated with a unique alias.

All paths described in the following procedures are written for UNIX users. Users of Microsoft Windows should change all occurrences of a foreslash ("/") to a backslash ("\").

You must not use the sslcmd utility provided with Control-M/Agent. The utility and kdb format are no longer supported by Control-M MFT.

Configuring Control-M MFT for Server Authentication

This procedure describes how to configure Control-M MFT for server authentication. To implement server authentication you must import the CA belonging to each of the FTP over SSL/TLS servers to the Control-M MFT keystore.

Begin

  1. Set the host security to level 3.

  2. Copy the FTP over SSL/TLS server CA file to a temporary location where Control-M MFT is installed.

  3. Navigate to the following location:

    <Control-M/Agent home directory>/cm/AFT/JRE_LINK/bin/

  4. Import the certificate for the CA, as follows:

    • FIPS ON: ./keytool -J-Djava.security.properties==<java_security_file_path> -J--module-path="<ctm_agent>/ctm/cm/AFT/exe/providers" -J-Dorg.bouncycastle.fips.approved_only=true -importcert -alias <server_alias> -file <server_certificate_file> -keystore <keystore_file> -storepass <password> -storetype BCFKS

    • FIPS OFF: ./keytool -J-Djava.security.properties==<ctm_agent>/ctm/cm/AFT/data/java.security.mft -J--module-path="<ctm_agent>/ctm/cm/AFT/exe/providers" -importcert -alias <server_alias> -file <server_certificate_file> -keystore <keystore_file> -storepass <password>

      Where <java_security_file_path> is, as follows:

      • Windows, Solaris and AIX: <ctm_agent>/ctm/cm/AFT/data/java.security.mft

      • Linux: <ctm_agent>/ctm/cm/AFT/data/java.security.mft.bcf

Ensure that the certificate is valid before you import it as a trusted certificate. View it with the keytool -printcert command or the keytool -importcert command without the -noprompt option, and verify that the displayed certificate fingerprints match the expected ones.

Configuring Control-M MFT for Client Authentication

This procedure describes how to configure Control-M MFT for client authentication that allows the server to authenticate Control-M MFT. You can either use the Control-M MFT Certificate of Authentication (CA), or you can use one supplied by an outside vendor, as described in Configuring Control-M MFT for an Alternative CA.

Begin

  1. Set the host security to level 4.

  2. Configure Control-M MFT for server authentication, as described in Configuring Control-M MFT for Server Authentication .

  3. Do one of the following:

    • To use the Control-M MFT CA, use your server’s Import utility to import clientCA.crt file from the following location:

      <Control-M/Agent home directory>/cm/AFT/data/SSL/cert

    • To use an alternative CA, you must configure Control-M MFT so that this CA is recognized by the application, as described in Configuring Control-M MFT for an Alternative CA.

      All paths described in the following procedures are written for UNIX users. Microsoft Windows users must ensure that when following these commands, all occurrences of a foreslash / are changed to a backslash\.

Configuring Control-M MFT for an Alternative CA

This procedure describes how to configure Control-M MFT for client authentication using an alternative CA.

Before you begin

  • Create your own Java Keystore file.

  • Generate a CSR and submit the request to the CA.

  • Import the received certificate from the CA into the keystore.

  • Export the CA certificate that authenticates the public key to a file.

Use the same password to protect the keystore and private keys.

Begin

  1. Copy your keystore file to the following location:

    <Control-M/Agent home directory>/cm/AFT/data/SSL/cert

  2. Update the keystore filename, location, and type the following location, as described in Java Keystore Configuration:

    <Control-M/Agent home directory>/cm/AFT/data/ftpssl_config.properties

  3. Update the password, as follows:

    <Control-M/Agent_Home_Dir>/CM/AFT/exe/keystoreutil –changepassword –storepass <your keystore password> –new_storepass <your keystore password> -keystoretype AFT_SSL –keystore <full path to your keystore file>

    The keystore file password is maintained and the Control-M MFT SSL configuration file ftpssl_config.properties is updated with the encrypted password.

  4. Import the CA to your FTP server.

Java Keystore Configuration

The following table describes Java Keystore configuration properties. A keystore is a database of cryptographic keys, X.509 certificate chains, and trusted certificates.

By default, Control-M MFT is installed with a defined keystore file located in <Control-M/Agent home directory>/cm/AFT/data/SSL/cert/aftkeystore.pfx.

Parameter

Description
ssl.securitydir

Defines the path to the security directory where the Java keystore file is located.
ssl.keystore.filename

Defines the keystore file name.
ssl.keystore.type

(Optional) Defines a unique alias for the keystore. Use this option if you set security to level 4 and you have more than one private key entry in the keystore.

If there is only one private key entry, do not set this property.
ssl.keystore.password

Defines the encrypted password for the keystore. Use the same password for keystore and private keys.

The aftkeystore.pfx file is provided with the default password: password. To ensure data security, change this password immediately, as described in Changing the MFT Keystore Password. If you created a new keystore file in Configuring Control-M MFT for an alternative CA, use this password for future commands. If you have already changed it, use the new password.

Changing the MFT Keystore Password

This procedure describes how to change the keystore password and update the Control-M MFT SSL configuration file with the new encrypted password.

If this is the first time you are changing the keystore password, the default password is password.

Begin

  1. Navigate to the following location:

    <Control-M/Agent_Home_Dir>\CM\AFT\

  2. Type the following command:

    keystoreutil –changepassword –help

    For keystoretype parameter choose: AFT_SSL

    The keystore and Control-M MFT SSL configuration files are updated with the new password.

Creating your Own Keystore

This procedure describes how to create your own keystore for Control-M MFT and Control-M MFT B2B Gateway.

Begin

  1. Run the keytool for Control-M MFT and Control-M MFT B2B Gateway in the following locations:

    • MFT: <Agent Home>/cm/AFT/JRE_LINK/bin

    • MFT B2B Gateway: <Gateway Home>/mft-proxy/JRE/bin

  2. Do one of the following:

    • Generate a new keystore in PKCS#12 format by doing the following:

      1. Run the following:

        keytool -genkeypair -v -alias <my_alias> -keystore <keystorePath> -storetype PKCS12 -keypass <keystore_password> -storepass <keystore_password> -keyalg RSA -keysize 2048

      2. Create a certificate signing request from a CA and then import the certificate reply from a CA to the keystore.

    • Generate a new keystore in PKCS#12 format and bring your own key-pair into the keystore by doing the following:

      1. Empty the keystore from public/private key-pair entry, as follows:

        keytool -delete -alias <my_alias> -keystore <keystorePath> -storetype PKCS12 -storepass <keystore_password>

      2. Ensure that the keystore is empty by running the following:

        keytool -v -list --keystore <keystorePath> -storetype PKCS12 -storepass <keystore_password>

      3. Import the public/private key-pair stored in <file_location>.p12 (pfx) file into the keystore by running the folllowing:

        keytool -v -importkeystore -srckeystore <whateverthefileis.p12> -srcstoretype PKCS12 - srcstorepass <whateverthefileis_password> -destkeystore <keystorePath> -deststoretype PKCS12 -deststorepass <keystore_password>

    • Convert an existing keystore in JKS/PKCS12 format to the PKCS#12 format.

      keytool -v -importkeystore -srckeystore <srckeystorePath> -srcstoretype PKCS12 - srcstorepass <srcKeystorePassword> -destkeystore <destkeystorePath> -deststoretype PKCS12 -deststorepass <destKeystorePassword>

For more specific information, see Keytool documentation.

Configuring Connection Details for a Remote Windows Server

This procedure describes how to configure connection details for a remote Windows server, which enables you to avoid any problems caused by this issue when defining a Control-M MFT connection profile.

There is no standard way that Windows-based FTP/SFTP servers display the file system.

Begin

  1. From your local FTP/SFTP client, connect to the remote Windows FTP/SFTP server, as follows:

    1. FTP: enter ftp <host>

    2. SFTP: enter sftp <username>@<host>

      The FTP/SFTP server might require that you define the domain. Both the username and host must be the same values you use when defining the connection profile.

      The SFTP Client Application name might vary, depending on the application or platform you are using.

  2. Type your password.

  3. From the command line, type pwd.

    The user home directory appears.

    The syntax of the path of the home directory indicates the operating system where it is running.

  4. Select the appropriate host OS Type in Connection Profile Management utility according to the following:

    1. If the path uses foreslash / define the host as UNIX.

    2. If the path uses backslash \ define the host as Windows.

      If you select UNIX as the OS Type, you should not transfer files in ASCII mode.

  5. In the Connection Profile utility, ensure that home directory path name is defined using the same syntax as that shown in the pwd command (see step 3).

Configuring LDAP with SSL

This procedure describes how to configure LDAP with SSL/TLS, which takes the LDAP certificate (signed by CA) and adds it to the JRE trusted CA (cacerts) keystore.

Begin

  1. Import the CA certificate that signed the LDAP directory’s certificate, by running the following:

    <MFT JRE>/keytool -importcert -keystore <MFT JRE>/lib/security/cacerts -file <certificate> -alias <unique name>

    /home/ctmagent/ctm/cm/AFT/JRE_LINK/bin/keytool -v -importcert -keystore /home/ ctmagent/ctm/cm/AFT/JRE_LINK/lib/security/cacerts -file /p/qadata/LDAP/tlvldap.cer -alias myldap

  2. At the password prompt, type changeit.

  3. Modify the LDAP Server URL parameter to use LDAPS, as described in LDAP Settings for Internal Users (default SSL port is 636).

    ldaps://tlv-ldp-srv.bmc.com:636

  4. Restart the Hub.

Configuring an FTP Firewall in Active and Passive Mode

Control-M MFT supports both the Active Data Transfer Process and the Passive Data Transfer Process enabling it to work behind a firewall and connect to remote FTP servers. The FTP mode is defined in the Connection Profile utility when you define the connection definition.

This procedure describes how to configure an FTP firewall in active and passive mode.

Begin

  1. Open the following communication channels in the FTP server firewall:

    • FTP server's port 21 from anywhere (Client Connects the Server)

    • FTP server's port 21 to ports greater than 1023 (Server responds to client's control port)

    • FTP server's port 20 to ports greater than 1023 (Server initiates data connection to client's data port)

    • FTP server's port 20 from ports greater than 1023 (Client sends ACKs to server's data port)

    Active mode can be problematic for FTP clients behind a firewall because the FTP client does not initiate the connection to the data port of the server; rather the server connects to the client port as defined in the PORT command. Usually an outside system initiating a connection to the client is blocked by the client firewall.

    The FTP Passive Data Transfer mode was developed to resolve this issue. In Passive mode, the following sequence of events occurs:

    • The client initiates both connections to the server, by first connecting to Server command port 21.

    • The client then issues the PASV command, (which requests that the Server open a random unprivileged port for the data port, and sends the PORT command to the client).

    • The client then connects to the data Server port as specified in the PORT command.

  2. Open the following communication channels in the FTP server firewall, to support Passive mode FTP:

    • FTP server's port 21 from anywhere (Client connects the server)

    • FTP server's port 21 to ports greater than 1023 (Server responds to client's control port)

    • FTP server's ports greater than 1023 from anywhere (Client initiates data connection to random port specified by server)

    • FTP server's ports greater than 1023 to remote ports greater than 1023 (Server sends ACKs (and data) to client's data port)

      Problems can occur if an FTP server is behind a firewall, when FTP clients try to use passive mode to connect to a temporary random port number on the FTP server machine. The most common of these is that the firewall blocks the connection from the client to the server.

      When a restrictive firewall (one that denies a connection except for a few well known ports) exists on both the server and client sides, you should configure the firewall on the server side. Many FTP servers allow the administrator to specify a range of ports for the FTP server to use. The administrator can then limit the port range for the FTP server, and the firewall can then be configured to allow connection for the specified FTP server port range.

Configuring an SFTP Firewall

This procedure describes how to configure an SFTP firewall.

Begin

  • If the SSH server resides behind a firewall, open the SSH port for traffic.

    The client usually connects to SSH server port 22.

Adding Users to Local Security Policies

This procedure describes how to add users that are defined in the connection profile in the host where the Local CM checkbox is selected to Administrators, which enables you to execute PGP commands (Windows only).

Begin

  1. From the Computer Management window, select Local Users and Groups -> Groups ->Administrators.

    The Administrators Properties window appears.

  2. Click Add to define the user name defined in the connection profile, and then click OK.

  3. Click OK.

Extending the Timeout Period in Control-M/EM

This procedure describes how to extend the timeout period in Control-M/EM. and Control-M/Server, which prevents timeouts from occurring when you are generating an SSH key in the Control-M Configuration Manager.

Begin

  1. Log into the Control-M Configuration Manager.

  2. From the Tools menu, select System Parameters > Control-M/EM System Parameters.

    The Control-M/EM - System Parameters window appears.

  3. Double-click the RemoteCmdTimeout parameter.

  4. In the Value field, change the value to 3600.

  5. Click Save, and then click Close.

Extending the Timeout Period in Control-M/Server

This procedures how to extend the timeout period in Control-M/Server, which prevents timeouts from occurring when you are generating an SSH key in the Control-M Configuration Manager.

Begin

  1. Access the CTM_Server\data directory and open the config.dat file.

  2. Check the file for the following parameter:

    CTM_CONFIG_AGENT_TUNNEL_TIMEOUT <value>

  3. Do one of the following:

    1. If the parameter exists, change the value to 3600 or higher.

    2. If the parameter does not exist, add it to the file.

  4. Restart the Control-M/Server Configuration Agent.

Setting the Output File Permissions

This procedure describes how to configure the Control-M for MFT Output file permissions (UNIX only).

Begin

  • Open the <Control-M/Agent_home_dir>/ctm/data/FILE_TRANS.dat file and add the following:

    SYSOUT_MODE <required file permission>

SYSOUT_MODE 755

If the SYSOUT_MODE is not configured in the FILE_TRANS.dat, but rather the Agent CONFIG.dat, AFT uses the value configured in Agent CONFIG.dat.

Activating the Control-M for MFT Debug Level

This procedure describes how to activate the Control-M for MFT debug level, which enables you generate Control-M for MFT debug information.

Begin

  1. Raise the Control-M/Agent debug level to 4, as described in the Defining the Agent Debug Level.

    The debug files are created in the following location:

    <Control-M/Agent_home_dir>/proclog

  2. When you have all the required debug information, decrease the debug level to 0.

Changing the Encryption Key in MFT

This procedure describes how to change the AES256 key used to encrypt passwords in MFT accounts and property files.

The password can be encrypted with a non-default key for the Control-M/Agent version 9.0.18 or later and Control-M MFT 9.0.18 or later.

Begin

  1. Stop the Agent.

  2. Create a new key using the keygen script, as follows:

    • UNIX: ./ctm_agent/ctm/scripts/keygen.sh -keyoutput <file path>

    • Windows: <AGENT_HOME>\keygen.bat -keyoutput <file path>

  3. To rotate the the MFT existing key, copy and rename the created file to /home/dbauser/ctm_agent/ctm/cm/AFT/data/new_local.txt, which is the MFT encryption key, as described in Control-M Encryption keys.

  4. Start the Agent.

    After the MFT container starts, all secured data in accounts.xml and property files are re-encrypted using the new key.

Enabling FIPS on Control-M MFT

This procedure describes how to enable FIPS on Control-M MFT.

Before you begin

Back up all data before making any changes.

Begin

  1. Create the environment variable MFT_FIPS set to ON on all Hub and Gateway hosts.

  2. Create and configure FIPS compliant keystores, as described in Creating FIPS Compliant Keystores.

  3. ModifyMFT client SSL configuration by opening the <Agent>/cm/AFT/ftpssl_config.properties file and modify the relevant properties.

    # The path to the security directory where keystore file resided

    ssl.securitydir=${cm.home}/data/SSL/cert/fips

    # The keystore file name

    ssl.keystore.filename=aftkeystore.bcfks

    # The keystore type

    ssl.keystore.type=BCFKS

  4. Modify the MFT Server SSL/SSH configuration by opening the <Agent>/cm/AFT/data/fts_config.properties file and modify the relevant properties.

    • ftp.secure.keystore=${cm.home}/data/SSL/cert/fips/ftskeystore.bcfks

    • ftp.secure.keystore.type=BCFKS

    • ftp.secure.ciphers=SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

    • ssh.host.keystore=${cm.home}/data/Keys/fips/keystore.bcfks

    • ssh.host.keystore.type=BCFKS

    • ssh.ciphers=AES128CBC,AES256CBC,AES192CBC,AES128CTR,AES192CTR,AES256CTR,TripleDESCBC

      The FTP secure ciphers list does not include specific SHA functions security bits. If you want to enforce a specific cipher suite, add it as a suffix, such as TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.

    • Restart the Hub by running the following and then wait until it starts again:

      <Agent>/cm/AFT/exe/shutb2b.sh

  5. If you are using MFT Enterprise, verify to configure SSL server authentication between the Hub and the Gateway, as described in Configuring SSL Authentication between the Hub and Gateway.

Configuring SSL Authentication between the Hub and Gateway

This procedure describes how to configure SSL authentication between the Hub and Gateway.

Begin

  1. Verify that the SSL certificates exist in both the Hub and Gateway keystores.

    Gateway: ssl_keystore.pfx, Hub: ftskeystore.pfx

  2. Export the relevant public certificates from the keystores.

  3. On the Hub host, import the Gateway public certificate to the Hub trusted keystore file, with one of the following:

    • Use the JRE cacerts file (default)

    • Use a specific custom keystore

  4. Modify the hub_config.properties file, as follows:

    • To enforce SSL server authentication, set client.ssl.server-auth=true

    • To define a custom trusted keystore (not cacerts), set the following:

      • client.ssl.keystore=<path to the keystore file>

      • client.ssl.keystore.type=<keystore type, e.g.: PCKS12>

      • client.ssl.keystore.password=PLAIN:<keystore pass>

    • (Optional) To enforce the Hub to verify SAN (Subject Alternative Names) matching or CN (Common Name) matching (used as fallback only when no SAN are available), set client.ssl.server-hostname-verify=true.

  5. Restart the Hub by running the following:

    cm/AFT/exe/shutb2b.sh (\shutb2b.exe)

  6. On the Gateway host, import the Hub public certificate to the Gateway trusted keystore file, with one of the following:

    • Use the JRE cacerts file (default)

    • Use a specific custom keystore

  7. Modify the proxyConfig.properties file, as follows:

    • To enforce SSL server authentication, set client.ssl.server-auth=true

    • To define a custom trusted keystore (not cacerts), set the following:

      • client.ssl.keystore=<path to the keystore file>

      • client.ssl.keystore.type=<keystore type, e.g.: PCKS12>

      • client.ssl.keystore.password=PLAIN:<keystore pass>

    • (Optional) To enforce the Gateway to verify SAN (Subject Alternative Names) matching or CN (Common Name) matching (used as fallback only when no SAN are available), set client.ssl.server-hostname-verify=true.

  8. Restart the Gateway by running the following:

    /mft-proxy/exe/shut-mft-proxy.sh

    /mft-proxy/exe/start-mft-proxy.sh

Enabling FIPS on the Control-M MFT Gateway

This procedure describes how to enable FIPS on the Control-M MFT Gateway:

Before you begin

Back up all data before making any changes.

Begin

  1. Update the java.security file by renaming java.security.bcf to java.security in the following location:

    <Gateway Home>/mft-proxy/JRE/lib/security/

  2. Configure SunJSSE for FIPS mode, as follows:

    1. Open the java.security file and add BCFIPS to the end of the following line:

      security.provider.2=com.sun.net.ssl.internal.ssl.Provider BCFIPS

      The list of providers must be in the following order:

      • security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider C:DEFRND[SHA256];ENABLE{ALL};

      • security.provider.2=com.sun.net.ssl.internal.ssl.Provider BCFIPS

      • security.provider.3=sun.security.provider.Sun

      • security.provider.4=sun.security.rsa.SunRsaSign

  3. Modify the Gateway configuration on the MFT Hub by opening the <Agent>/cm/AFT/data/proxyConfig.properties file and modify the relevant properties.

    • param.ftp.secure.keystore=${cm.home}/data/SSL/cert/fips/ftskeystore.bcfks

    • param.ftp.secure.keystore.type=BCFKS

    • param.ftp.secure.ciphers=SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

    • param.ssh.host.keystore=${cm.home}/data/Keys/fips/keystore.bcfks

    • param.ssh.host.keystore.type=BCFKS

    • param.ssh.ciphers=AES128CBC,AES256CBC,AES192CBC,AES128CTR,AES192CTR,AES256CTR,TripleDESCBC

    • param.http.key.store.path=data/fips/ssl_keystore.bcfks

    • param.http.key.store.type=BCFKS

  4. Restart the Gateway by running the following:

    mft-proxy/exe/shut-mft-proxy.sh

  5. Create and configure FIPS compliant keystores.

Creating FIPS Compliant Keystores

This procedure describes how to create FIPS compliant keystores for Control-M MFT and Control-M MFT B2B Gateway.

If using the JSSE in FIPS mode, the key-stores containing either the private server credentials, or the private client credentials must be readable using the BCFIPS provider. The only key-store type the BCFIPS provider has available, that is FIPS compliant, is the BCFKS. When using the JSSE in FIPS mode, the key-stores for private key credentials is BCFKS. The PKCS12 key store is not available in FIPS mode of operation due to the algorithms required for PBE key generation in the PKCS12 standard.

<java_security_file_path> must be one of the following:

  • Windows, Solaris and AIX: <ctm_agent>/ctm/cm/AFT/data/java.security.mft

  • Linux: <ctm_agent>/ctm/cm/AFT/data/java.security.mft.bcf

Begin

  1. Run the keytool for Control-M MFT and Control-M MFT B2B Gateway in the following locations:

    • MFT: <Agent Home>/cm/AFT/JRE_LINK/bin

    • MFT B2B Gateway: <Gateway Home>/mft-proxy/JRE/bin

  2. Do one of the following:

    • Generate a new keystore in BCFKS format by doing the following:

      1. Run the following:

        keytool -J-Djava.security.properties==<java_security_file_path> -J--module-path="<ctm_agent>/ctm/cm/AFT/exe/providers" -J-Dorg.bouncycastle.fips.approved_only=true -genkeypair -v -alias <my_alias> -keystore <keystorePath> -storetype BCFKS -keypass <keystore_password> -storepass <keystore_password> -keyalg RSA -keysize 2048

      2. Create a certificate signing request from a CA and then import the certificate reply from a CA to the keystore.

    • Generate a new keystore in BCFKS format and bring your own key-pair into the keystore by doing the following:

      1. Empty the keystore from public/private key-pair entry, as follows:

        keytool -J-Djava.security.properties==<java_security_file_path> -J--module-path="<ctm_agent>/ctm/cm/AFT/exe/providers" -delete -alias <my_alias> -keystore <keystorePath> -storetype BCFKS -storepass <keystore_password>

      2. Ensure that the keystore is empty by running the following:

        keytool -J-Djava.security.properties==<java_security_file_path> -J--module-path="<ctm_agent>/ctm/cm/AFT/exe/providers" -v -list --keystore <keystorePath> -storetype BCFKS -storepass <keystore_password>

      3. Import the public/private key-pair stored in <file_location>.p12 (pfx) file into the keystore by running the folllowing:

        keytool -J-Djava.security.properties==<java_security_file_path> -J--module-path="<ctm_agent>/ctm/cm/AFT/exe/providers" -v -importkeystore -srckeystore <whateverthefileis.p12> -srcstoretype PKCS12 - srcstorepass <whateverthefileis_password> -destkeystore <keystorePath> -deststoretype BCFKS -deststorepass <keystore_password>

    • Convert an existing keystore in JKS/PKCS12 format to the BCFKS format.

      keytool -v -importkeystore -srckeystore <srckeystorePath> -srcstoretype PKCS12 - srcstorepass <srcKeystorePassword> -destkeystore <destkeystorePath> -deststoretype BCFKS -deststorepass <destKeystorePassword>

For more specific information, see Keytool documentation.

Control-M MFT Keystores

The following table lists the Control-M MFT keystores and location:

Keystore

Location

Non-FIPS keystore

FIPS keystore
FTS Keystore for fingerprints data\keystore\ keystore.pfx keystore.bckfs
MFT client keystore data\SSL\cert\ aftkeystore.pfx aftkeystore.bcfks
FTS keystore (SSL) data\SSL\cert\ ftskeystore.pfx ftskeystore.bcfks