A knowledge base article about InCommon Certificate Chain provided by the UC Berkeley IT Service Hub - Knowledge Portal

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:

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:

New chain (After May 4th 2026)

NOTE: The InCommon Certificate Manager will provide links to the appropriate chains described below when certificates are issued. Certificates issued using ACME should automatically contain the appropriate chains provided your ACME client is not configured to request a specific chain.

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:

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:

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

	Cross-signed version	Self-signed version
Subject	Sectigo Public Server Authentication Root R46 Sectigo Public Server Authentication Root E46	Sectigo Public Server Authentication Root R46 Sectigo Public Server Authentication Root E46
Issuer	USERTrust RSA Certification Authority USERTrust ECC Certification Authority	Sectigo Public Server Authentication Root R46 Sectigo Public Server Authentication Root E46
Public Key	Same	Same
Role	Intermediate	Root CA cert

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

Servers / applications aren't supposed to send the "root" certificate, but the new R46 and E46 certificates are labeled as "root".

These are special versions of the Sectigo  Public  Server  Authentication  Root R46 or E46 certificates that are signed by the legacy USERTrust root certificate. These act as additional intermediate certificates for maximal compatibility for clients. You can technically skip this at the risk of some legacy applications not working with your application.

Why is the USERTrust root CA being distrusted when it is not near expiration?

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

Why do you instruct not to send the root CA certificate?

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. The exception is when cross-signed certificates are used for backward compatibilty when root CAs are being distrusted. In those cases additional certificates that are signed by the older CA are issued with the same DN as the self-signed new/modern root.

How do I see what CA issued my certificate?

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

Where do I download the new root CA to include in my custom trust store?

Sectigo Public Server Authentication Root R46 (RSA)

Sectigo Public Server Authentication Root E46 (ECC)