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 that may not yet include the new roots.

Important:  Chrome and Mozilla are removing trust for the legacy USERTrust CAs.  See this article for more information:  https://www.sectigo.com/resource-library/changes-to-root-ca-hierarchies-and-trust-status#removal-of-trust-for-legacy-cas

What this means for you:

• Custom trust stores: If your client-side code explicitly trusts a specific root CA instead of relying on the operating system’s built-in CA store (an uncommon setup), you will need to update it to trust the new root when the server certificate is renewed.  You can find the new root certificate here: https://crt.sh/?d=4256644734
• Widespread compatibility: Most modern applications, browsers, and operating systems already trust the new certificate chain.
• No impact to existing certificates: Certificates issued before May 4th, 2026, will continue to work normally.
• 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.

Certificate chain for InCommon-supplied SSL certificates (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, intermediate/bridge certificate)

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

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 ECC OV SSL CA 3 (intermediate)
Sectigo Public Server Authentication Root E46 (cross-signed, intermediate/bridge certificate)

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-signed certificates

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.

The Two Verification Paths

Path A — 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 — 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.

Certificate chain for InCommon-supplied SSL certificates (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

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 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

Which certificates to send (after May 2026)

We recommend sending the cross-signed "Sectigo  Public  Server  Authentication  Root R46 or E46" intermediate, the "InCommon ECC or RSA OV SSL CA 3" intermediate, and your server certificate. There is almost never any reason to send the legacy USERTrust root certificate.

Should you send the root CA certificate?

No. Clients connecting to your application have a collection of their own trusted certificates so if they do not already trust your root certificate nothing is changed by your application sending it.

Validating certificate source

Your server's SSL certificate is supplied by InCommon if it is issued by the "InCommon ECC or RSA" certificate. To see your certificate's issuer you can use the online certificate decoder. You can also use the openssl tool:

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