Renew Central Governance CAs

As of Central Governance 1.1.3 SP9, you can renew key certificates before they expire.

Note If you upgrade Sentinel to 4.2.0 SP15 Patch 3 or higher, but did not follow the procedure for changing the default Governance CA on Central Governance, skip the following renewal sections and execute the Update the CA for Sentinel procedure instead.

Certificates that expired in 2019

Upgrade process Certificate Current expiry date New expiry date
 

Apply SP9 to any Central Governance version 1.1.3

PassPort SSO CA

08/09/2019

Not renewed

PassPort SSO Agent 08/09/2019 03/14/2024

ROOT CA

11/28/2019 03/14/2029

Default Governance CA

11/28/2019 Not renewed

The PassPort certificate expiration affects:

  • The communication between Central Governance and Transfer CFT
  • The communication between Central Governance and SecureTransport
  • The communication between Central Governance and Sentinel
  • The communication between Central Governance internal processes

To remedy these issues, perform the following steps:

  • Renew the Passport SSO agent
  • Renew the Governance CA
  • Update the certificates for Sentinel

About the PassPort SSO agent

The PassPort SSO agent is automatically renewed when you upgrade to Central Governance 1.1.3 SP9. The new certificate has a root certificate, called PassPort CA, that is uploaded during the upgrade process.

Prerequisites

You require the following minimum versions to use the Renew Governance CA procedure described below:

  • Transfer CFT version 3.2.4 SP4 P2 or Transfer CFT 3.3.2 SP4 and higher
  • Sentinel 4.2.0 SP15 Patch 3 and higher

Renew the PassPort SSO agent

The PassPort SSO agent is automatically renewed when you upgrade to Central Governance 1.1.3 SP9. 

Renew Governance CA

The Governance CA signs certificates that products use to register with Central Governance via an SSL\TLS mutual authenticated connection.

Perform the following steps:

  1. Upload an inactive Governance CA (see below for details).
  2. Check the certificate upload on Transfer CFTs:
  3. In the Central Governance UI, each Transfer CFTs is displayed as an entry in the Deployment List > Governance CA page after the default period of 10 minutes. To modify the wait time, please see Modify the automatic certificate activation time.
  4. Once the inactive Governance CA uploads on all the Transfer CFTs, activate the certificate using the cgcmd configure --updateca command. See cgcmd configure- u for details.
  5. The --updateca command:
    • Checks if the new certificate file exists and is valid
    • Starts Central Governance with the new Governance CA
  6. The impacted Transfer CFTs then activate the new certificate using one of two methods:
    • Automatic: Once the Governance CA certificate is within 60 days of expiring, the Transfer CFT certificates are renewed using the new CA.
    • Forced: You can perform a renewal request on targeted Transfer CFT instances using REST API. See in REST API: Renew a certificate.
    Note   For the new Governance CA to be taken into account, you must restart the Copilot server for all Transfer CFT versions except Transfer CFT 3.3.2 SP4.
  7. Renew the Governance CA on registered SecureTransports. See If the Governance CA changes after SecureTransport registration.

Upload an inactive Governance CA

Starting with SP9 Central Governance no longer delivers a default Governance CA, so you must use a custom Governance CA. Therefore, for SP9 and higher, you upload a new Governance CA and push it to all registered Transfer CFTs. The Transfer CFTs then have both the old and the new Governance CA.

Proceed as follows:

  1. Create a .p12 certificate. Refer to the Security Guide > Certificate management for details on supported certificates.
  2. Upload this new Governance certificate to Central Governance. See in REST API: Renew a certificate for details.

POST /api/v2/configurations/cas

 

{

"certificateContent": <New Governance CA. P12 certificate encoded in Base 64>,

"certificatePassword": <certificate password>,

"name": <certificate alias>

}

Modify the automatic certificate activation time for Transfer CFT

To change the default certificate activation time:

  1. Navigate to <Central Governance dir>/runtime/<cftconnector_node>/uma/conf/conf.properties.
  2. Add the property governance_ca.deployment.period.seconds to this file.
  3. Set this property to a value equal to the desired number of seconds until the CA activation.

Update certificates for Sentinel

This section describes the certificate updates needed for the connection between Central Governance and Sentinel.

Updates when Sentinel is using custom certificates

If Sentinel is configured with custom certificates, you must update the customized Sentinel truststore and the customized PassPort truststore to include the new PassPort CA.

For Sentinel lower than SP15 Patch 3

  1. Export the PassPort CA from Central Governance:
  2. keytool -exportcert -alias passportsso -file Passport_CA.cer -keystore <path to CG sso.jks>
  3. On Sentinel, import the public certificate for the PassPort CA into the Sentinel SSL truststore:
  4. keytool -import -file Passport_CA.cer -alias Passport_CA_new -keystore <path to Sentinel truststore.jks>
  5. Provide the custom truststore.jks password.

For Sentinel SP15 Patch 3 and higher

  1. Import the new PassPort CA into the Sentinel custom SSL truststore:
  2. keytool -importkeystore -srckeystore <Sentinel installation directory>/Sentinel/conf/security/truststoreSSO.jks -destkeystore <path to Sentinel custom truststore.jks>
  3. Alternatively, you can export the certificate with the passport alias from the default truststoreSSO.jks, and then import it into the custom Sentinel SSL truststore.

  4. If you use a custom PassPort truststore, you must manually import the new PassPort CA into the Sentinel custom PassPort truststore:

  5. keytool -importkeystore -srckeystore <Sentinel installation directory>/Sentinel/conf/security/truststoreSSO.jks -destkeystore <path to Sentinel custom passport truststore.jks>

    • Enter the password for destination truststore, which is the password with which you created the Sentinel custom PassPort truststore.

    • Enter the password for the source truststore, where the password is the default Sentinel password.

  6. Alternatively, you can export the certificate with the passport alias from the default truststoreSSO.jks, and then import it into the Sentinel custom PassPort truststore.

Updates when Sentinel is using default certificates

The connectivity between Central Governance and Sentinel is impacted by the PassPort SSO CA and Passport CA expiration. As the PassPort SSO CA expires on August 9, 2019 and the PassPort CA expires on November 28, 2019, you must update to Sentinel 4.2.0 SP15 Patch 3. Refer to the Security GuideCertificates for details.

Note If you upgrade Sentinel to 4.2.0 SP15 Patch 3 or higher, but did not follow the procedure for changing the default Governance CA on Central Governance, you must perform the steps in this section. However, if you update the Governance CA using POST /api/v2/configurations/cas, this overwrites the Sentinel CA setting. Rerun the cgcmd configure command to set the PassPort CA on Central Governance, and then deploy the new CA on all Transfer CFTs.

Update the Sentinel keystore with the new CA

Perform the following operations in Sentinel:

  1. Obtain the new public Governance root CA (PEM, DER, or CER file) used for Central Governance.
  2. On Sentinel, import the Governance CA as a trusted entity in the truststorePassPort.jks file:
  3. keytool -import -file <path to root governance authority PEM|DER|CER file> -alias root_GovernanceCA -keystore <Sentinel installation directory>/Sentinel/conf/security/truststorePassPort.jks

  4. Enter the password to protect the Java KeyStore. Select Yes to trust the certificate entry.

Update the Sentinel truststore SSL

Perform the following operations in Central Governance. If Sentinel uses default certificates, Central Governance and Sentinel no longer have the same root authority. To enable communication between Transfer CFTs and Sentinel, you must set the new Sentinel root CA:

  1. Launch the cgcmd configure command and set Use Governance CA for front-end SSL to No.
  2. Upload the truststore containing the Sentinel CA. In a Sentinel default installation, use the truststoreSSO.jks located in the <Sentinel_Installation_Dir>/Sentinel/conf/security directory.
  3. The truststore may contain multiple certificates. Provide the certificate alias for the Sentinel CA keystore entry, where passport is the alias for the new PassPort CA.
  4. Deploy the new configuration on all Transfer CFTs. From the Deployment List > Configuration page, deploy the updated configuration.

Post-update actions

After updating Sentinel to 4.2.0 SP15 Patch3 or higher, Sentinel will use the new PassPort CA. However, Sentinel does not automatically use the new PassPort CA, you must first remove the following files and restart Sentinel:

  • <Sentinel installation directory>/Sentinel/conf/security/PAMKeystore.jks
  • <Sentinel installation directory>/Sentinel/conf/security/passport.properties

When you then start Sentinel, these files are regenerated with the new PassPort CA.

You must execute this procedure regardless of if it is a Sentinel configured with default certificates, or for Sentinel configured with custom certificates.

Update the new CA on SecureTransport

For registered SecureTransports, you must manually import both the:

  • New Sentinel CA to SecureTransport's trusted CAs.
  • Issuer of the new Governance CA to SecureTransport’s trusted CAs.

Renew the Business CA

The Business CA signs certificates that managed products used to make business SSL\TLS connections for file transfers.

Transfer CFT

If you change any of the Central Governance certificate authorities after registering Transfer CFTs with Central Governance, you must resubmit the certificates that were obtained during registration.

  • Transfer CFT Copilot requests a new SSL certificate signed by the new CA.
  • Central Governance sends the requested certificate to Copilot.

See the Business CA section for details.

SecureTransport

SecureTransport uses its own certificate, so changing the Business CA has no impact. However if the SecureTransport admind certificate expires for a flow, you should refer to the information in Change the admind after it expires.

Business certificate expiration and flow impact

Central Governance automatically updates the status of a deployed flow if it has an internal certificate that is invalid or about to expire. See Manage communication profiles for information about flows with expired certificates.

Note When a Transfer CFT certificate is renewed, both the old and the renewed certificate are present in the Access and Security Transfer CFT Entity and have an Active status. The renewed certificate though, is marked as Default.

Limitation

The flow where the certificate is used does not change status to Saved, Not Deployed. To force the renewed certificate's deployment on the corresponding products, copy the flow, remove the originally deployed flow, and deploy the flow copy.

Alerts for internal certificates

This section describes alerts for internal communication profile certificates that are about to expire.

When you perform a cgcmd start or cgcmd status command, Central Governance checks for internal certificate expiration and sends a notification if there are certificates that are about to expire. You can use the cgcmd configure command to configure the number of days prior to certificate expiration to send a notification. You can use the cgcmd status -c command to display all internal certificates and their expiration dates. Please see the cgcmd command section for more information.

Note Central Governance cannot start if any of the internal certificates have expired.

 

Central Governance | Document Directory

Related Links