Background

On May 4th, 2026 InCommon will begin issuing all TLS certificates, both RSA and ECC, from new public intermediate certificate authorities (CAs). These new intermediate CAs are cross-signed by the widely trusted, but now legacy, USERTrust RSA and ECC roots as well as the modern Sectigo Public Server R46 and E46 roots to ensure compatibility with older clients.

Important: Chrome and Firefox are removing USERTrust from their trusted root programs; after removal, certificates relying solely on the USERTrust chain will fail in those browsers.  

Important: We are waiting for additional guidance from InCommon, some dates may change.

What this means for you:

• Custom trust stores: If your application explicitly trusts specific root CAs rather than delegating to the OS trust store (sometimes common in Java applications, containers, and embedded systems), you will need to update it to trust the new root when the server certificate is renewed.  You can find the new root certificates in the FAQ below.
• Modern client compatibility: Most modern applications, browsers, and operating systems already trust the new certificate chain.
• No impact to existing certificates: As long as they were issued before May 4th and their chain is presented correctly, they will validate using the existing USERTrust path until expiration.
• New certificates use new chain: Certificates issued on or after May 4th, 2026, will use the new CA chain.
• Server and application administrators: Be sure to include both of the listed intermediate certificates (InCommon and Sectigo) along with your server leaf certificate in TLS configurations.

Current chain (until May 2026)

RSA Certs

When using certificates issued by InCommon for your service/server, the recommended certificate chain is as follows.  You should include the first two certificates listed below in your application/server's TLS configuration.

your_server_leaf_certificate
InCommon RSA Server CA 2 (intermediate; expires 2032)
USERTrust RSA Certification Authority (root; expires 2038)

You can download these certificates here:

• InCommon RSA Server CA 2
• USERTrust RSA Certification Authority

ECC Certs

ECC certificates follow the same logic with an ECC intermediate.

your_server_leaf_certificate
InCommon ECC Server CA 2 (intermediate; expires 2032)
USERTrust ECC Certification Authority (root; expires 2038)

You can download these certificates here:

• InCommon ECC Server CA 2
• USERTrust ECC Certification Authority

New chain (After May 4th 2026)

RSA Certs

When using certificates issued by InCommon for your service/server, the recommended certificate chain is as follows to ensure maximum backward compatibility.  You should include all three of the certificates listed below in your application/server's TLS configuration.

your_server_leaf_certificate
InCommon RSA OV SSL CA 3 (intermediate)
Sectigo Public Server Authentication Root R46 (cross-signed root acting as intermediate)

You can download these certificates here:

• InCommon RSA OV SSL CA 3
• Sectigo  Public  Server  Authentication  Root  R46 (cross-signed with USERTrust Root)

ECC Certs

ECC certificates follow the same logic with E46/ECC intermediates.

your_server_leaf_certificate
InCommon ECC OV SSL CA 3 (intermediate)
Sectigo Public Server Authentication Root E46 (cross-signed root acting as intermediate)

You can download these certificates here:

• InCommon ECC OV SSL CA 3
• Sectigo Public Server Authentication Root E46 (cross-signed with USERTrust Root)

About cross-signing

We are recommending that the new cross-signed intermediates be used for maximum backward compatibility.  This provides two verification paths for certificates during the transition off of the USERTrust root CA.

Two versions of Sectigo Public Server Authentication Root R46 and E46

The two verification paths

Path A (legacy clients without R46): via USERTrust (cross-signed chain)

Leaf cert
  └── InCommon RSA OV SSL CA 3
        └── Sectigo Public Server Authentication Root R46 (cross-signed)
              └── USERTrust RSA Certification Authority  ← root in trust store

Path B (modern clients): via R46 as native root

Leaf cert
  └── InCommon RSA OV SSL CA 3
        └── Sectigo Public Server Authentication Root R46 (self-signed)  ← root in trust store

Because R46 has the same Subject DN and public key in both variants, a client that has the self-signed R46 in its trust store will recognize the cross-signed cert in the chain as anchoring to that trusted root. It terminates the chain there and never needs to go up to USERTrust.

What happens when USERTrust is distrusted

• Clients with R46 in their trust store: Unaffected. Path B succeeds independently. Modern OS/browser trust stores (updated since ~2022) include the R46 root natively. Chrome, Firefox, macOS, iOS, recent Windows and Linux distributions all have it.
• Clients with only USERTrust (not R46): Chain breaks. These are typically older or unmaintained trust stores such as legacy Android (pre-7.1), old Java runtimes, embedded systems, older enterprise certificate bundles that haven't been updated.
• Clients with both: Fine. Path B is preferred; USERTrust status is irrelevant.

FAQ

openssl x509 -noout -in /path/to/your/server/certificate -issuer