The following topics describe what happens when SecureTransport registers in Central Governance and the prerequisites and process for registering.


After upgrading a registered SecureTransport 5.4 or 5.3.6 to SecureTransport 5.5, its status is Unreachable in Central Governance. This occurs even though the original SecureTransport had the status Started, as it is stopped during the upgrade procedure. Once you have upgraded to SecureTransport 5.5 or higher, you can manually update the status in the Central Governance user interface using the SecureTransport health check option.

As of SecureTransport 5.5, you can only registration using REST API; registering via the user interface is not supported for version 5.5 and higher.

Unique and duplicate server communication profiles

Before registering you should understand how unique and duplicate server communication profiles are determined when SecureTransport has SecureTransport Edge servers deployed within its infrastructure.

One or more SecureTransport Edge servers can be grouped in a network zone in SecureTransport. An edge can belong to one or more network zones. During Central Governance registration, for each network zone, protocol servers activated on each edge are imported as server communication profiles. If multiple edges in the same network zone have the same protocol server activated with the same configuration, a single server communication profile is declared for all edges. In this case the Edges field of the server communication profile lists the edge server titles as declared in the SecureTransport server.

A server communication profile is considered a duplicate when the following configuration is identical:

  • The exchange protocol
  • The exchange port
  • Whether SSL/TLS is enabled, and if enabled:
    • The client authentication mode
    • The certificate used to secure the connection is the same in terms of content
  • FIPS transfer mode

If any of these settings differs, separate server communication profiles are imported in the static configuration of SecureTransport. However, server communication profiles can be identical across network zones, in which case they are imported separately in each network zone.

See About SecureTransport network zones for more information.

PeSIT services

If PeSIT services are activated on SecureTransport, client communication profiles — corresponding to each SecureTransport server communication profile — are created in Central Governance during registration. The following information is retrieved from the server communication profiles:

  • The network protocol.
  • The PeSIT login which, as for the server communication profile, represents the SecureTransport product name.
  • If SSL is activated, the SSL certificate to be used when SecureTransport is client. The certificate must have both server and client authentication key usage extensions to be usable as both the client and server certificate.
  • FIPS mode.

If there is no server communication profile created in the private network zone during registration, no client communication profile is created.

The generated client communication profiles can be used in flows. However, you can create other client communication profiles. See PeSIT client communication profile.

SecureTransport registration limitations

Limitations when registering using the SecureTransport user interface

Registering via the user interface is not supported for version 5.5 and higher. However, if you are registering SecureTransport 5.4 or lower via the user interface, this process uses a Hazelcast agent mechanism and has the following limitations:

  • Hazelcast in open source does not support SSL connections.
  • You cannot register 2 SecureTransports that are located on different sub-networks.

Limitations when registering using REST API

When SecureTransport is registered using REST APIs, the checkbox Enable Central Governance Integration from SecureTransport UI is not enabled, even if the registration is successful. For details on REST API registration, see Register SecureTransport (REST API).


The SecureTransport prerequisites described in this section apply for registration using either the SecureTransport UI or REST API.

Before registering SecureTransport, make sure the configuration is correct for transferring files via preferred protocols. This includes services, ports, SSL certificates for services and protocol-specific configuration. Ensure also that SecureTransport and Central Governance are not using the same ports as this will lead to a failed registration.

Additionally, if you are installing both SecureTransport and Central Governance on the same machine, it is recommended that you install Central Governance first.

After registering, if you need to change the SecureTransport configuration, change it first on SecureTransport and then make parallel changes for the SecureTransport in the Central Governance user interface.

Central Governance and SecureTransport must be configured and running for SecureTransport to register successfully. The SecureTransport Transaction Manager must be running; SecureTransport Edge, if installed, must be configured correctly.

See the SecureTransport user documentation for more information about configuring SecureTransport properly for file transfers.

The following steps must be completed in the SecureTransport administration user interface.


To register multiple SecureTransports with Central Governance, where each SecureTransport uses a different network, the SecureTransport networks must be able to communicate with one another. If these multiple Secure Transports are not able to communicate with one another, none of them can register successfully.

Network zones

You must define network zones and the streaming configuration between the SecureTransport server and Edges in the SecureTransport Administration before starting the registration process. Additionally, ensure that streaming between the SecureTransport Back End and Edges is operational before registration.

In Central Governance the list of Edge node addresses is set in the Hosts field of the network zone. The FQDN is set by default to the first Edge node address. Registration fails if the definition of a network zone is invalid on SecureTransport.

Administrator account

  1. Make sure the SecureTransport administrator can log on using client certificates. In Authentication > Login, set the following:
    1. Select to enable Administrator login options > Certificates.

    2. The Client Certificate Settings pane is displayed. Under Client certificates select Optional.

    3. From the Accept certificates issued by drop-down menu, select any trusted issuer.

  2. Make sure you have an administrator user with a Master Administrator role in Accounts > Administrators. You must set this administrator user’s Certificate DN to C=FR,O=Axway,O=UM,OU=Central Governance,CN=default.
  3. Click Save.
  4. Restart SecureTransport.

See Registering SecureTransport in Central Governance in the SecureTransport Administrator Guide.

Static configuration

Static configuration must be setup and started on SecureTransport. Central Governance retrieves it in the registration process.

  1. Configure, enable and start the server protocols to be exposed in Central Governance at Operations > Server Control.
  2. Specify the Client Certificate Authentication and SSL Encryption. Determine whether client certificate authentication is optional or mandatory depending on your security policy.
  3. For SecureTransport 5.3.6 and higher, you can set the SSL Encryption in Access > Secure Socket Layer and the Client Certificate Authentication in Authentication > Login settings once you enable the use of a certificate in the end-user log-in options.
  4. If applicable, configure the SSL certificates for use by server protocols supporting secure connections. Generate or import certificates referenced in the SSL Key Alias fields.
  5. Central Governance retrieves the static configuration for FTPS during the registration process. Set the Base Port, Number of Ports and Port End under FTP Passive Mode at Setup > FTP Settings in SecureTransport.

Registration using the SecureTransport user interface

This section describes how to register SecureTransport via the SecureTransport user interface (UI).

Specify the parameters for connecting SecureTransport and Central Governance in the SecureTransport Administrative interface by selecting Setup > Central Governance. The Central Governance administrator must provide many field values, such as host and port, to the SecureTransport administrator, which are set on the configuration page in Central Governance. The SecureTransport fields are:


Must contain the same IP address or FQDN used on the configuration page in Central Governance. Registration fails unless the same value is used on both sides.


Port of the Central Governance agent as entered in the Agent section on the configuration page in Central Governance. The default port is 5701. See also the port information in the Prerequisites section.


Name of the Central Governance agent as entered in the Agent section on the configuration page in Central Governance.

Shared Secret

The shared secret set up on the configuration page in Central Governance for products to use during registration.

Product Identifier

Central Governance uses this value to uniquely identify the instance or cluster of SecureTransport being registered.

Administrator Name

The name of the administrator user account for Central Governance to use for logging on to the SecureTransport Administration Tool.

Local Bind Address

The IP address or FQDN of the computer running SecureTransport.

Local Bind Port

The port used by the Central Governance agent to listen for connections.

Account Home Folder Prefix

Base home folder for accounts created by Central Governance.

Real User (Windows only)

If the account home folder prefix is on a shared network; specify a real user who has access to it. You must specify the real user in a password vault file.

For more information, see the "Add a user to a password vault" topic in the SecureTransport Administrator Guide.

UID (Unix and Linux only)

UID for accounts created by Central Governance.


GID for accounts created by Central Governance.

Failed login attempts before account is locked

The number of times a user can attempt to log on with invalid credentials before being locked out. This field is optional.

Expire password on account creation

When enabled users must change their passwords after logging on the first time.

For more information see the Central Governance configuration topic in the SecureTransport Administrator Guide for the configuration to complete in SecureTransport.

Registration process

The following graphic illustrates the SecureTransport registration process with Central Governance. The process begins when the Central Governance configuration is saved in SecureTransport. The graphic shows what happens next.

Use the numbers in the graphic to correlate with the text describing each phase.

1. Auto-discovery registration

The SecureTransport agent connects over a pre-shared channel to the agent in Central Governance. The registration request includes the name, host name, operating system and version of the SecureTransport.

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.

2. Certificate exchange

The Central Governance Governance certificate authority generates and sends to SecureTransport an SSL certificate for securing connections between the two products. To establish mutual authentication, Central Governance also sends the governance certificate authority as a trusted authority. These enables the SecureTransport administrator user to have a secure connection.

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

All data connections between SecureTransport and Central Governance are mutually authenticated on the same port, via SecureTransport REST APIs. For instance, Central Governance pushes flow configurations over the mutually authenticated channel using the REST API HTTP PUT and POST methods. Deployment of flows by Central Governance to SecureTransport succeeds even if the SecureTransport Agent is unavailable.

When this certificate expires, Central Governance renews it and sends it to SecureTransport.

3. SecureTransport static configuration

Central Governance receives the current configuration of SecureTransport. This includes:

  • Server communication profiles corresponding to the activated and running protocol servers on SecureTransport.
  • Network zone definition and server communication profiles corresponding to the activated and running protocol servers on SecureTransport Edge servers, if any.
  • Certificates for the SSL certificates used by the servers supporting secured connections. Only the public key of the SSL certificate is retrieved along with the chain of certificate authorities.

4. Sentinel configuration

Central Governance configures SecureTransport to use a Sentinel configured to work with Central Governance. The following SecureTransport properties are changed during registration.


Property Value
Host Sentinel – Front-end host
Port Sentinel – Front-end port

Overflow file

Property Value
Name sentinel-overflow.db
Path var/run/
Size 5 MB
Warning threshold 90

The following properties are not changed:

  • Send Heartbeat to Axway Sentinel Every
  • Events (Available Event States, Event States to Send)
  • When Overflow File Exceeds Maximum Size.

Registration approval

You can configure Central Governance to require approval when SecureTransport attempts to register.

Configure registration approval

You can enable registration approval using the configure mode. See Configuration and startup for details.

Approve a registration

  1. Configure SecureTransport to register with Central Governance. In the Central Governance Product list page, the SecureTransport status becomes Ready to register.
  2. Access the Transfer CFT details page and click Approve registration. The user must have appropriate privileges to approve the registration.

Reject a SecureTransport registration

You can reject a SecureTransport that is in the Ready to register status by removing it from Central Governance.

Registration approval results

Registration is successful when SecureTransport is reported as Started on the Central Governance Product List page:

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

Registration results

Registration is successful when the SecureTransport status is Started on the Central Governance Product List page.

SecureTransport creates the following configurations for use in Central Governance:

  • CentralGovernanceApplication - An application of type AdvancedRouting to be used in all subscriptions.
  • CentralGovernanceRouteTemplate – A route package template to be used for all routes of AdvanceRouting type.

See the advanced routing topic in the SecureTransport Administrator Guide for more information.

If after registering the product does not appear on the Product List page or has a registered in error status, see SecureTransport registration troubleshooting.

Status monitoring

Central Governance monitors the status of registered SecureTransports through their agents. SecureTransport has a Started status in Central Governance when the SecureTransport agent communicates successfully with the Central Governance agent. Even if SecureTransport is not running, the status is Started in Central Governance as long the agents on both sides can communicate. If communication between agents breaks, the status of SecureTransport is Unreachable on the Product List page in Central Governance.

If the Governance CA changes after SecureTransport registration

After registering SecureTransport in Central Governance, changing the Governance CA requires that you upload the new Governance CA issuer to the SecureTransport list of Trusted CAs.

  • Import the public portion of the new CA in SecureTransport > Certificates > Trusted CAs.
Note If you use an intermediate certificate as a governance CA certificate, you must add the root CA certificate that signs this intermediate certificate to the SecureTransport list of Trusted CAs.
Note For custom Governance CAs, you must use the same password for file protection and the private key.

Change the admind after it expires

If the SecureTransport server communication profiles use admind, you can perform the following steps to change the admind in Central Governance after it has expired.

On SecureTransport

  1. Generate a new admind certificate and overwrite the expired one.
  2. Export the admind certificate with its private key and internal CA.
  3. Import these certificates to XCA to create the certificate chain.
  4. Set both certificates to Trusted.
  5. Export the admind as a .p12 chain file, and name it admindnew.

Refer to the SecureTransport Administrator Guide for more information.

On Central Governance

  1. Create a new communication profile in the SecureTransport configuration and upload the admindnew.
  2. Use a REST API GET to retrieve the admindnew certificate contents, where the X-EncryptionKey parameter is set to the .p12 base64 encrypted password. For example, if the password is 1, the x-encryptionkey=MQ==.
  3. GET /api/v2/product/id/certificates
  4. From the Central Governance UI, remove the communication profile that uses admindnew.
  5. Use a REST API to remove the admindnew certificate:
  6. DELETE /api/v2/product/id/certificate/id
  7. Use a REST API to replace the expired admind with the new one:
  8. PUT /api/v2/product/certificate/id
  9. {
  10. "businessId": "1e2bcedb-fe2b-470a-9339-b0c89d0f4fb7",
  11. "name": "admind",
  12. "certificateContent":"admindnew_content",
  13. "certificatePassword":"p12_certificate_password"
  14. }

See Manage SSH keys for details on using REST APIs for certificate management in Central Governance.

Master SecureTransport node fails

When you configure SecureTransport as a cluster, either a standard cluster or enterprise cluster (LEC), by default Central Governance deploys flows on the SecureTransport node that was the master when SecureTransport registered. The SecureTransport Configuration Connectivity> Administration host and Port parameters define the connection to this node.

If the master SecureTransport node fails, Central Governance can no longer deploy flows and cannot detect that another node has become active. However, you can update the SecureTransport Connectivity parameters for SecureTransport, by setting the host and port fields to redirect to the currently active node or a load balancer.

Scenario 1 - Using an internal load balancer

In SecureTransport Configuration > Connectivity, set the parameters to point to an internal load balancer positioned between Central Governance and SecureTransport.

  1. The SecureTransport enterprise cluster Node 1 is the node registered on Central Governance.
  2. The SecureTransport Node 1 fails and Central Governance can no longer deploy flows.
  3. Replace the SecureTransport Node 1 host and port in Central Governance with the load balancer host and port to enable continued flow deployment.

Scenario 2 - No internal load balancer is available

If no internal load balancer is available, update the SecureTransport Configuration > Connectivity parameters to point to the master SecureTransport node.

  1. The SecureTransport enterprise cluster Node 1 is the node registered on Central Governance.
  2. The SecureTransport Node 1 fails and Central Governance can no longer deploy flows.
  3. Replace the SecureTransport Node 1 host and port in Central Governance with the SecureTransport Node 2 host and port to enable continued flow deployment.

When you change the Connectivity parameters, the host is propagated to the Products list and Product details. When you deploy a flow with SecureTransport, Central Governance then tries to connect to SecureTransport on the new host and port.

Note Edges are common to SecureTransport cluster nodes, and are not affected by the change in Central Governance to SecureTransport Connectivity parameters.

Synchronize a cluster

After a standard SecureTransport cluster registers with Central Governance, you must manually synchronize the cluster so that the Central Governance certificates are copied to all nodes.

In the SecureTransport UI, select Operations > Cluster Management, then select Synchronize all to copy the certificates to the secondary node. The Central Governance CA and CG PassPort CA are copied from the primary SecureTransport to all the other nodes. This sets Accounts > Administrators > Admin > Certificate DN for all secondary nodes to C=FR,O=Axway,O=UM,OU=Central Governance,CN=default.

Remove and re-register

The best practice for removing a registered SecureTransport is to first ensure that the SecureTransport does not have the Unreachable status in Central Governance. Once you remove the product, the Central Governance configuration in SecureTransport becomes disabled. You can then enable the configuration in SecureTransport to re-register the product.

See Remove products for information about removing registered products from Central Governance.


Central Governance | Document Directory

Related Links