Transfer CFT registration

The following topics describe the tasks to register Transfer CFT in Central Governance.

The parameters for connecting Transfer CFT and Central Governance are specified during installation of Transfer CFT. After installation, the Transfer CFT Copilot is started, and Copilot connects to Central Governance to begin the registration process. Only Copilot, and not Transfer CFT server, must be started to begin the registration process.

The following graphic illustrates the Transfer CFT registration process with Central Governance.

Picture of the Transfer CFT registration process with Central Governance

As noted in 4. Transfer CFT configuration updated, Central Governance pushes configurations to Transfer CFTs upon registering. Central Governance sets Transfer CFTs to use the Sentinel configured with Central Governance. See Use local settings for Sentinel for details.

Supported versions

Central Governance supports the following Transfer CFT versions:

  • 3.1.3 SP12 and higher service packs (see TLS versions)
  • 3.2.4 SP2 and higher service packs
  • 3.3.2 and higher

Using a proxy server

To use a proxy server between Transfer CFT and Central Governance, set the following Transfer CFT proxy parameters prior to registering with Central Governance:

  • cg.proxy.in.host
  • cg.proxy.in.port
  • cg.proxy.in.login
  • cg.proxy.in.password

You can also specify an outgoing HTTP proxy that Transfer CFT has to use to connect to Central Governance. Refer to the Transfer CFT User Guide > Central Governance options for more information.

1. Registration request

Copilot must be started to begin the registration process. Transfer CFT also can be started, but this is optional for registration. Copilot makes a simple-authentication connection to Central Governance.

A registration request is sent that contains:

  • Information about Transfer CFT, including its instance name, host, port, operating system and version.
  • The Central Governance shared secret. The shared secret, obtained from the Central Governance administrator, is set in Transfer CFT when Transfer CFT is installed.
  • Certificate signing requests (CSRs) for Central Governance to process, and the names of the certificate authority (CA) services that process the CSRs.

Products must use the Central Governance shared secret to register successfully. The shared secret was set during initial configuration of Central Governance, immediately after it was installed but before the server was started the first time.

Note When setting the Central Governance shared secret during a Transfer CFT z/OS installation, translation issues may occur if you use certain characters. For example, if you enter !SECRET (using code page IBM1147) the shared secret is translated to §SECRET during the Central Governance registration. Therefore, you must use compliant characters in the shared secret value when working in a z/OS environment.

2. Certificates for Transfer CFT

The following describes the certificates Central Governance sends to Transfer CFT, depending on your choice of certificate authorities.

A new Transfer CFT registration (new installation using the Central Governance configuration) creates one client and one server CFTSSL objects and two PKI entities. The PKI entity holds the root certificate IDs, and the entity ID of the entity is then used in the ROOTCID field in CFTSSL.

Default CAs

When the default CAs are used, the Central Governance Access and Security service creates a security entity for Transfer CFT. It uses as the entity name the concatenation of the Transfer CFT InstanceId and InstanceGroup, which both were set during installation of Transfer CFT.

Central Governance then generates a signed business certificate to be used for securing file transfers between the registering Transfer CFT and all other Transfer CFTs. The Transfer CFT name is used to identify the business certificate. The business certificate authority is the internal CA that generates and signs the certificate, which is known as the PassPort CA in the Access and Security service.

Along with the business certificate, Central Governance generates and sends a governance certificate to Copilot. The governance certificate is used to secure communications between Central Governance and Transfer CFT and its Copilot. The governance certificate authority is the CA that generates this certificate, which is known as PassPort Product CA in the Access and Security service.

Custom CAs

You can customize the business and governance CAs on the Central Governance configuration page. See Access and security for details.

Note For custom Governance and Business CAs, you must use the same password for file protection and the private key.

Before Transfer CFT is registered in Central Governance, the custom governance CA must be known and trusted by the registering Transfer CFT.

Customizing the business CA affects the secured transfers between the registering Transfer CFT and other Transfer CFTs. All other Transfer CFTs must know and trust the new business CA.

SAF-based PKI (for example, RACF)

When you register a Transfer CFT z/OS that uses system as security (pki.type=system), Central Governance retrieves the CFTPROTs and SSL profiles during registration. However, Central Governance does not retrieve the server certificate and certificate aliases, so the Transfer CFT communication profiles will have an inactive status. You must manually modify the Transfer CFT configuration used in RACF in order to be able to define and deploy flows.

  • On the Transfer CFT z/OS configuration protocol:
    • Upload a new public certificate
    • Set the PARM field (for Transfer CFT z/OS )
  • For a Transfer CFT non z/OS configuration protocol:
    • Configure the CA (certificate alias)
    • Deploy flows between:
      • Transfer CFT z/OS and Transfer CFT z/OS
      • Transfer CFT z/OS and Transfer CFT non z/OS

3. Mutually authenticated connection

Once Copilot has the certificates, it connects to Central Governance on the secured communications port using the Central Governance certificate.

All heartbeat connections between Copilot and Central Governance are mutually authenticated on the same port. Only Copilot sends heartbeats during registration.

Every time Copilot starts it checks the validity of the certificates. A renewal request is scheduled when a certificate has expired or is about to. The Transfer CFT parameter cg.renewal_period, with a default value of 60 days, is used to identify certificates about to expire.

For certificates about to expire, renewals are through the mutually authenticated connection. However, if the certificate used for mutually authenticated connections has expired, the simple authentication connection is used. Before Transfer CFT receives a new certificate, the product status is Unreachable in the Central Governance user interface.

4. Transfer CFT configuration updated

Completing the registration process, Central Governance gets the current configuration of Transfer CFT and changes it.

  • Transfer CFT is configured to use the Central Governance Access and Security service for access management.
  • Transfer CFT is configured to use the Central Governance Sentinel for transfer monitoring. For Transfer CFT 3.2.2 and higher, a secured connection is used.

These changes create two security profiles (CFTSSL) on the Transfer CFT (except when using a SAF-based PKI Transfer CFT). The profiles are named SSL_DEFAULT; one profile is of type client and one is of type server. Their SSL version is TLSV1COMP. The configured cipher list is CIPHLIST= ('53','47') for Transfer CFT 3.1.2 and 3.1.3. The values represent the following cipher suites:

The values represent the following cipher suites:

  • 47: TLS_RSA_WITH_AES_128_CBC_SHA
  • 53: TLS_RSA_WITH_AES_256_CBC_SHA

For Transfer CFT 3.2.2 and higher, the configured cipher list is CIPHLIST= ('49200', '49199', '49192', '49191', '157', '156', '61', '60', '53', '47'). The values represent the following cipher suites:

  • 49200: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • 49199: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • 49192: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • 49191: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • 157: TLS_RSA_WITH_AES_256_GCM_SHA384
  • 156: TLS_RSA_WITH_AES_128_GCM_SHA256
  • 61: TLS_RSA_WITH_AES_256_CBC_SHA256
  • 60: TLS_RSA_WITH_AES_128_CBC_SHA256
  • 53: TLS_RSA_WITH_AES_256_CBC_SHA
  • 47: TLS_RSA_WITH_AES_128_CBC_SHA

The client and server security profiles must be mutually authenticated. However, by default, a registered Transfer CFT does not have a protocol with a security profile. You must edit the Transfer CFT configuration to support protocols with mutual authentication.

Central Governance sends the updated configuration to Transfer CFT. The following are the Transfer CFT parameters updated in this process. However, you can overwrite certain default values by assigning an existing policy at registration. Please see, below for details.

Parameter Value
am.passport.cg.organization Org
am.passport.domain CG
am.passport.hostname <Central Governance host name >
am.passport.instance_id $(cft.instance_group).$(cft.instance_id)
am.passport.port 6666
am.passport.use_ssl Yes
am.passport.userctrl.check_permissions_on_transfer_execution No
am.type passport
cft.purge.rt 10D
cft.purge.rx 10D
cft.purge.st 10D
cft.purge.sx 10D
cft.server.bandwitdth.cos 4
cft.server.bandwitdth.cos.0.max_rate_in -1
cft.server.bandwitdth.cos.0.max_rate_out -1
cft.server.bandwitdth.cos.1.weight_in 80
cft.server.bandwitdth.cos.1.weight_out 80
cft.server.bandwitdth.cos.2.weight_in 15
cft.server.bandwitdth.cos.2.weight_out 15
cft.server.bandwitdth.cos.3.weight_in 5
cft.server.bandwitdth.cos.3.weight_out 5
cft.server.bandwitdth.enable No
cg.mutual_auth_port <secured communications port>
copilot.misc.createprocessasuser No
pki.type

cft

Note Except when using a SAF-based PKI Transfer CFT, in which case system is the value.
sentinel.trkipaddr <Sentinel – Front-end host >
sentinel.trkipport <Sentinel - Font-end port>
sentinel.xfb.enable Yes
sentinel.xfb.use_ssl Yes

Transfer CFT instance id

When you register Transfer CFT with Central Governance, Central Governance sets the CFTPARM PART parameter to the same value as the Transfer CFT installation instance ID. Having a different value may impact transfer monitoring.

Assign a policy at registration

In addition to the changes described in the table above,Transfer CFT becomes linked to the policy configured in the Transfer CFTcg.configuration_policy parameter. If the policy does not exist in Central Governance at registration, no operation is performed even if the policy is created after registration.

The policy configuration might overwrite the default parameters Central Governance updates. For instance, if the policy contains access management set to None, Transfer CFT is configured to use None rather than the Central GovernanceAccess and Security service.

See Manage policies for information about adding policies for Transfer CFTs in Central Governance

Set the Group at registration

You can automatically set a Transfer CFT's Group during registration. On Transfer CFT, define the UCONF  cft.instance_group parameter value prior to registration.

On Central Governance:

  1. Navigate to the com.axway.cmp.cgcft-default.cfg configuration file.
  2. Set the registration.set_default_group parameter to true.
  3. Save.

Registration attributes

In addition to pre-defining the Group, you can also set the following attributes in the com.axway.cmp.cgcft-default.cfg configuration file prior to product registration. Set as indicated to enable the feature upon registration.

Parameter Value Description
enableBandwidthThrottling true Enable bandwidth throttling

setSentinelAtRegistration

true Set the Transfer CFT parameters for Sentinel

registration.create_application

true Automatically create an application

registration.application_name

{%name%} Application {%name%}, which may contain the following variables: name, id, version, and OS

registration.set_default_group

true Set the group based on the Transfer CFT UCONF cft.instance_group value

Network definitions

Windows and Linux

For Transfer CFT to register successfully with Central Governance, it must have at least one of the following Central Governance network types defined, but cannot have more than one of each type: TCP, pTCP, and UDT. This means that you can register a Transfer CFT that has a maximum of three CFTNET objects, where the Transfer CFT type=TCP and CLASS is different for each CFTNET.

The CFTNET objects are:

  1. One pTCP, where ID = <pTCP_ID> and CLASS=<X> and the UCONF parameter acceleration.ptcp = <pTCP_ID>.
  2. One  UDT, where ID = <UDT_ID> and CLASS=<Y> and the UCONF parameter acceleration.udt = <UDT_ID>.
  3. One TCP, where ID=<TCP_ID> and CLASS=<Z>.

Central Governance does not manage additional CFTNET types; these are stored, without modification, on the Transfer CFT as retrieved on registration.

Communication profiles

If the Transfer CFT that is registering has existing network definitions, for example a server type TCP_SSL definition, Central Governance creates the appropriate corresponding communication profile on registration.

Protocol definitions

If you have modified the Transfer CFT network configuration, see the recommendations in Check protocol-related settings prior to registration.

Use local settings for Sentinel

When Transfer CFTs register, Central Governance configures the Transfer CFTs to use Sentinel to work with Central Governance. However, there may be occasions when Transfer CFTs are using another Sentinel installation, and need to continue using it after registering with Central Governance. In this case, you can disable Central Governance so that it does not overwrite existing Transfer CFT configurations for using Sentinel.

Set the following Central Governance property to false before registering Transfer CFTs:

setSentinelAtRegistration=false

The property is in the com.axway.cmp.cgcft-default.cfg file at <install directory\runtime\com.axway.nodes.ume_<UUID>. Restart Central Governance for the change to become effective.

The following are the Sentinel properties in Transfer CFTs whose values are untouched when the registration property in Central Governance is disabled.

  • sentinel.trkipport
  • sentinel.trkipaddr
  • sentinel.xfb.enable
  • sentinel.xfb.use_ssl

Supported Transfer CFT protocols

Central Governance can create Transfer CFT flows that are configured with the PeSIT E or SFTP protocol. When a Transfer CFT registers with Central Governance, for each CFTPROT where TYPE=PESIT and PROF=ANY, or TYPE=SFTP, an entry is created in the Protocols section of Transfer CFT static configuration.

However, if the Transfer CFT has protocols that are not supported in Central Governance, the registration is successful and Central Governance creates legacy flow objects. Unsupported protocols include PeSIT D, SNA, OFTP and EBICS. For more information on Legacy flows, see Transfer CFT legacy flows.

Protocol CFTPROT TYPE CFTPROT PROF CFTNET Central Governance usage
PeSIT E PESIT ANY TCP Central Governance flows
SFTP SSH ANY N/A Central Governance flows
PeSIT E PESIT ANY X25 or LU62 Legacy Flows
PeSIT D PESIT SIT or External or CFT TCP, X25, or LU62 Legacy Flows
SNA PESIT ANY or SIT or External or CFT SNA Legacy Flows
OFTP ODETTE N/A TCP, X25, or LU62 Legacy Flows
EBICS EBICS N/A TCP, X25, or LU62 Legacy Flows

SFTP protocol at registration

If you register a Transfer CFT that has existing SFTP protocols, these SFTP protocols and their server communication profiles are created in Central Governance.

Additionally, all SSH private keys that are used in server CFTSSH (direct=server) definitions are imported, except if they are not also attached to a CFTPROT definition. If a SSH private key is used in a client CFTSSH (direct=client) definition, and is also used in a CFTPART definition, it is imported.

If there is an SFTP protocol (CFTPROT) that is defined with a client CFTSSH (direct=client), the Transfer CFT registers in error. To correct this:

  • Remove this Transfer CFT from Central Governance.
  • On Transfer CFT, correct the configuration by associating the CFTSSH with the corresponding CFTPART for each occurrence.
  • Repeat the registration procedure.

Registration approval

You can configure Central Governance to require approval when Transfer CFT 3.2.2 or higher attempts to register. Transfer CFT 3.1.3 and lower register automatically, as these versions do not support the registration approval feature.

Configure registration approval

You can enable registration approval from the Central Governance configure mode. See Configuration and startup for details.

Approve a registration

  1. Start the Transfer CFT Copilot. In the Central Governance Product list page, the Transfer CFT status becomes Ready to register.
  2. Access the Transfer CFT details page and click Approve registration. The user must have MODIFY rights on the product resource to approve the registration.
Note An approval type registration may take longer than a registration without approval for Transfer CFT.

Reject a Transfer CFT registration

You can reject a Transfer CFT that is in the Ready to register status by removing it from Central Governance and then stopping Copilot. It is strongly recommended that you wait for at least 1 minute before stopping Copilot.

Rejecting a registration sets the Transfer CFT cg.enable parameter to No. To re-register Transfer CFT:

  1. Run the following command to set the parameter to Yes:
  2. CFTUTIL UCONFSET ID=cg.enable, VALUE=Yes
  3. Restart Copilot to begin the registration process.

Registration results

Registration is successful when one of the following statuses is reported on the Central Governance Product List page:

  • Started. Registration succeeded, and Transfer CFT is running.
  • Stopped. Registration succeeded, and Transfer CFT is not running.

If a problem occurs during registration, Transfer CFT is registered with an error. See Transfer CFT registration troubleshooting for information on registration errors.

 

 

Central Governance | Document Directory

Related Links