Truststore Migration for MID Server
- MID server is a Java application shipped with a bundled JRE.
- Within the JRE there is a file called cacerts also known as JRE Truststore.
- The unmodified cacerts file contains trusted root certificates signed by the certificate authorities and the JVM uses these to establish SSL or TLS encrypted connections with the other systems
- As the certificates expire or revoked they are removed from the JRE.
- Different versions of JRE will have different contents in their Truststore.
- During the mid upgrade following the download and the extraction of packages, the mid server overwrites the files targeted for update.
- So, in the event of JRE upgrade if happens as part of the MID upgrade, the original cacerts file is overwritten and any self-signed certificates that the client had uploaded will be lost, and they have to re-uploaded post upgrade.
- This is fixed in Quebec by identifying and migrating the self-signed certificates found in the original Truststore and migrate them to the incoming JRE from the upgrade.
- Backups from the existing cacerts is also taken during this process
- Backup of the original bundled JRE’s Truststore is created
- The existing Truststore certificates re filtered for self-signed certificates
- A backup of the incoming upgrade JRE’s Truststore is created.
- Self-signed certificates are imported into incoming upgrade JRE’s Truststore with an “sac-” string prepended.
- This is only present for the upgrades of the bundled JRE but not If the customer is managing the JRE outside the MID bundled package.
- What backups are created and where ?
- Original Truststore, which will be renamed to “cacerts_before”
- Incoming Truststore, which will be renamed to “cacerts_from_upgrade”
- Created under /agent/work/truststore_migration/<epoch timestamp>
- Backups are created only in the event of JRE upgrade (but for not all MID upgrades where the JRE upgrade is not happening)
- The details of the certificate migration (successful/failure) during the upgrade will be captured in the agent logs something like below
- AutoUpgrade.3600 Not migrating X.509 cert
- AutoUpgrade.3600 Migrating X.509 cert
- AutoUpgrade.3600 TrustStore migration complete
- The same is as well tracked in the MID Server Upgrade History table with the name “MigrateTrustStore” and the associated states being Completed, Failed and Skipped
- What if the default password of the cacerts file is changed and can that be read during the upgrade ?
- The cacerts will have to have the default password in place and using the default password is mandatory.