Preparing Your EPP Trust Store for the TRS CA 2026 Migration

About the TRS CA 2026 migration

As part of the normal certificate lifecycle, TRS has issued new dedicated Server Root CAs (OT&E and Production) and new server certificates for all registry EPP hosts. To avoid connection failures, you must update your trust store before expiration of the existing certificates in November 2026.

TRS designed a process that allows our registrar partners to update their configuration at their own pace, complete testing and if necessary return to a known-good state without service disruption. To this end, we provide alternative DNS names for the EPP endpoints across our managed registry instances, configured with the new Root CA certificate. These new endpoints can be distinguished by the use of the label epp2026 instead of the usual epp in the FQDN of the EPP server.

After the expiration of the legacy Root and server certificates, the live EPP endpoints will be reconfigured to use the new Root CA certificate, which will remain valid until 2031. All changes will be widely communicated via our regular channels to keep registrars posted of any upcoming changes. At some point after expiration of the original certificates, TRS will be removing the temporary epp2026 names.

Why server certificate validation matters

TLS provides two critical protections: encryption of data in transit, and authentication of the server you are connecting to. Many EPP client implementations only use TLS for encryption, they disable certificate validation or skip hostname verification, often to simplify initial setup. This is dangerous.

Without server certificate validation, your EPP client cannot distinguish the real TRS EPP server from an impostor. An attacker performing a man-in-the-middle attack would still receive an encrypted connection from your client, but your client would be sending EPP commands (including authentication credentials and domain management operations) to the wrong endpoint. Encryption without authentication protects no one.

A properly configured EPP client must perform two checks on every connection:

1. Server certificate validation — verify that the server's certificate was signed by a trusted Certificate Authority (in this case, the TRS root CA in your trust store). This confirms the certificate is genuine.
2. Hostname verification — verify that the hostname you connected to matches the hostname in the server's certificate. This confirms you reached the intended server, not a different host presenting a valid but unrelated certificate.

If your EPP client currently disables either of these checks (e.g., verify=False in Python, TrustAllCerts in Java, SSL_verify_mode => SSL_VERIFY_NONE in Perl), fix this before proceeding with the trust store migration. The bundles and instructions in this article only work when your client actually validates the server certificate against its trust store.

Phase 1: Install the combined trust bundle

OT&E combined trust bundle

Add both of the following certificates to your OT&E trust store (use the ready-made bundle below):

1. TRS OT&E Server Root CA 2026 — validates new OT&E server certificates after switchover.
2. Uniregistry Root CA — validates current OT&E server certificates until switchover.

Note: The OTE Registry Intermediate is sent in the TLS handshake by the server. You do not need to add it to your trust store separately.

Download the file and place into trs-ote-bundle.pem:

Production combined trust bundle

Add both of the following certificates to your Production trust store (use the ready-made bundle below):

1. TRS Production Server Root CA 2026 — validates new Production server certificates after switchover.
2. Uniregistry Root CA — validates current Production server certificates until switchover.

Note: The Production Registry Intermediate is sent in the TLS handshake by the server. You do not need to add it to your trust store separately.

Download the file and place into trs-prod-bundle.pem:

Installing the combined bundle

Java KeyStore (JKS / PKCS#12)

# OT&E: import both CAs into your OT&E keystore
keytool -importcert -alias trs-ote-server-root-ca-2026 \
-file trs-ote-server-root-ca-2026.pem \
-keystore ote-truststore.jks -storepass changeit
keytool -importcert -alias uniregistry-root-ca \
-file uniregistry-root-ca.pem \
-keystore ote-truststore.jks -storepass changeit

# Production: import both CAs into your Production keystore
keytool -importcert -alias trs-prod-server-root-ca-2026 \
-file trs-prod-server-root-ca-2026.pem \
-keystore prod-truststore.jks -storepass changeit
keytool -importcert -alias uniregistry-root-ca \

# OT&E: use the combined bundle directly as your CAfile
# (replace whatever you previously used for your OT&E CAfile)
cp trs-ote-bundle.pem /path/to/ote-ca-bundle.pem

# Production
cp trs-prod-bundle.pem /path/to/prod-ca-bundle.pem

OpenSSL CApath

# Copy each cert individually into the CApath directory, then rehash
cp trs-ote-server-root-ca-2026.pem /path/to/ote-ca-dir/
cp uniregistry-root-ca.pem /path/to/ote-ca-dir/
c_rehash /path/to/ote-ca-dir/

Python ssl module:

import ssl, socket
ctx = ssl.create_default_context()
# Load the combined bundle for the target environment
ctx.load_verify_locations(cafile="/path/to/trs-prod-bundle.pem")
conn = ctx.wrap_socket(socket.socket(),
server_hostname="<epp-host>")
conn.connect(("<epp-host>", 700))

Verifying Phase 1

Before TRS deploys the new server certificates, confirm the legacy connection still validates against your updated trust store:

# OT&E - verify legacy cert still validates
openssl s_client -connect <epp-host>:700 \
-CAfile trs-ote-bundle.pem -verify_return_error 2>&1 | grep "Verify return"

# Expected: Verify return code: 0 (ok)

# OT&E - verify new cert validates once epp2026.* is live

openssl s_client -connect epp2026.ote.registry.<epp-host>:700 \
-CAfile trs-ote-bundle.pem -verify_return_error 2>&1 | grep "Verify return"

# Expected: Verify return code: 0 (ok)

# Production - verify legacy cert still validates

openssl s_client -connect epp.registry.<epp-host>:700 \
-CAfile trs-prod-bundle.pem -verify_return_error 2>&1 | grep "Verify return"

# Expected: Verify return code: 0 (ok)

# Production - verify new cert validates once epp2026.* is live

openssl s_client -connect epp2026.registry.<epp-host>:700 \
-CAfile trs-prod-bundle.pem -verify_return_error 2>&1 | grep "Verify return"

# Expected: Verify return code: 0 (ok)

Phase 2: Remove legacy material after the switchover

Once TRS confirms that all EPP servers have been switched to the new certificates and no legacy server certificates remain in use, remove the Uniregistry trust material from your trust stores. Retain only the TRS CA 2026 root for each environment.

Warning: Do not begin Phase 2 until you have received the official TRS switchover announcement. Removing the legacy root before the switchover will cause EPP connection failures.

Target state after cleanup

Java KeyStore cleanup

# Identify legacy aliases in your keystores
keytool -list -keystore ote-truststore.jks -storepass changeit
keytool -list -keystore prod-truststore.jks -storepass changeit

# OT&E
keytool -delete -alias uniregistry-root-ca \
  -keystore ote-truststore.jks -storepass changeit
# Only if you previously imported it manually
keytool -delete -alias ote-registry-intermediate \
  -keystore ote-truststore.jks -storepass changeit

# Production
keytool -delete -alias uniregistry-root-ca \
  -keystore prod-truststore.jks -storepass changeit
# Only if you previously imported it manually
keytool -delete -alias prod-registry-intermediate \
  -keystore prod-truststore.jks -storepass changeit

OpenSSL CAfile cleanup

# Replace the combined bundle with the single new root only

# OT&E

cp trs-ote-server-root-ca-2026.pem /path/to/ote-ca-bundle.pem

# Production
cp trs-prod-server-root-ca-2026.pem /path/to/prod-ca-bundle.pem

# OT&E

openssl s_client -connect <epp-host>:700 \
-CAfile trs-ote-server-root-ca-2026.pem -verify_return_error 2>&1 | grep "Verify return"

# Expected: Verify return code: 0 (ok)

# Production

openssl s_client -connect epp.registry.<epp-host>:700 \
-CAfile trs-prod-server-root-ca-2026.pem -verify_return_error 2>&1 | grep "Verify return"

# Expected: Verify return code: 0 (ok)

Certificate reference

Individual certificate details and PEM blocks for verification and manual trust store management. Fingerprints extracted from live EPP endpoints on 2026-03-05.

New root CAs (TRS CA 2026)

Individual PEM blocks:

• TRS OT&E Server Root CA 2026
• TRS Production Server Root CA 2026

Legacy certificates (expiring November 9, 2026)

Note: The two intermediate certificates are included in the TLS handshake by TRS EPP servers. Registrars do not need to add them to trust stores. They are listed here for identification and audit purposes only.

Next steps

• Complete Phase 1 immediately in both OT&E and Production. Installing the combined trust bundle now is the single most important action to prevent connection failures during the migration window.
• Verify the legacy connection still works in both environments. Use the openssl s_client commands in Verifying Phase 1 to confirm a clean Verify return code: 0 (ok) before the switchover.
• Watch for the TRS switchover announcement. TRS will notify registrars when all EPP servers have been migrated to the new certificates.
• Re-verify after the switchover. Run the same verification commands to confirm the new certificates also validate cleanly.
• Complete Phase 2 once the switchover is confirmed. Remove the Uniregistry root and any remaining intermediates from your trust stores.

Support

Questions? Contact Tucows Registry Services Support and reference the EPP server certificate rotation.

Was this article helpful? If not please submit a request here