How Can We Help?

Chain hierarchy and intermediate certificates

You are here:

Sectigo's public roots enjoy the same trust in the industry as everyone else. In fact, Sectigo's root ubiquity exceeds 99.99% of the systems used today and is 100% for modern browsers, mobile devices and operating systems.

As a rebrand of the company, formerly known as Comodo CA, Sectigo owns and operates all of Comodo's old roots.

In January 2019 we launched our Sectigo intermediate on our old USERTrust root. This root directory has proven to be reliable in production since that date and has ubiquitous browser compatibility.

Corporate customers have the choice to use the new Sectigo brand root or the old Comodo brand root indefinitely.

What is root? What is intermediate level?

Ein «Root» -Zertifikat ist im Allgemeinen ein Zertifikat, das selbst signiert ist (derselbe Betreff und derselbe Aussteller), das jedoch auch von einem Anbieter in einem vertrauenswürdigen Root-Speicher enthalten ist.
We generally speak of 3 root certificates (5 if you include the ECC variants of COMODO CA and USERTRUST, which I did not specify here):

AddTrust External CA strain:
https://crt.sh/?id= 1
Uses sha1WithRSAEncryption. Expires in May 2020.

USERTrust RSA certificate authority:
https://crt.sh/?id=1199354
Uses sha384WithRSAEncryption. Expires in January 2038.

COMODO RSA CA:
https://crt.sh/?id=1720081
Uses sha384WithRSAEncryption. Expires in January 2038.

The AddTrust certificate is owned by Sectigo and was acquired many years ago. COMODO and USERTrust were created by Sectigo (then Comodo).
AddTrust has been included in some root programs for longer than the newer roots of SHA-2 COMODO / USERTrust.

Although the number of platforms is very small, there are still some platforms that may not have the newer SHA-2 roots for various reasons. Since we generated these newer root certificates, we also signed cross-certificates where the AddTrust certification authority was used to sign the individual SHA-2 certification authorities. An example of the AddTrust signed USERTrust RSA certification authority: https://crt.sh/ ? id = 4860286

(Note that the AddTrust CA itself uses SHA-1, but this is not a security risk. The problems with SHA-1 were the feasibility of collisions that could be calculated in advance, but these risks are self-evident, when * new * certificates are created and not when a certificate has already been created and distributed with SHA-1. For this reason, the various core programs from Microsoft, Mozilla, Apple and Google have continued to take these into account and have no concerns about being linked with them ( Older roots. Of course, many of them expire at short notice and will therefore soon no longer be used.)

Jetzt mit diesen Gegenzertifikaten und dem im Mai 2020 auslaufenden AddTrust
Wir können mit Sicherheit sagen, dass moderne Clients von diesem Ablaufdatum nicht betroffen sind. Browser wählen einfach eine Kette direkt zum SHA-2-Stamm (COMODO oder USERTrust) und das Gegenzertifikat zurück zu AddTrust wird einfach ignoriert.
Die meisten Pathbuilder ignorieren dies aufgrund des Ablaufs. Außerdem müssen Clients in den TLS-RFCs nicht die Schachtelung der Ablaufdaten überprüfen, sodass ein End-Entity-Zertifikat nach dem Ablauf eines Zertifikats «weiter oben» abläuft. Die Kette ist nicht problematisch.

The only clients that would have problems would be those that * don't * have the newer roots, but have AddTrust. An example could be a incredibly old EoL Android version.

(Of course, the use of the AddTrust cross certificates presupposes that the client has cached the certificate, retrieves AIA URLs for retrieval or that the Server provides the cross certificate in the TLS handshake.)

Das dokumentierte Verhalten, wenn eine Endentität eine Gültigkeitsdauer hat, die größer als der Wert von ‹SHA1 ROOT› ist, wenn dies der Standardanker ist, der auf einer Maschine vorhanden ist.
Wenn AddTrust der «einzige» Anker ist, wird das End-Entity-Zertifikat nach Ablauf von AddTrust Ende Mai 2020 Fehler erzeugen. Vorher sollten Kunden keine Fehler haben, da TLS keine Überprüfungsanforderungen enthält. Aber es besteht natürlich die Möglichkeit, dass esoterischere Kunden die Spezifikation ignorieren und versuchen, sie zu überprüfen.

The following figure shows our chain of trust.

Important note: When our AddTrust External CA Root expires, the chain of trust A is no longer used by customers, but via the chain of trust B

concatenated. The certification path is checked automatically on the client side and no changes should be necessary at the customer end. *** Testing is still recommended. For more information, please contact support. ***

Trust chain path A:
AddTrust External CA strain [
Strain] USERTrust RSA Certification Authority (Intermediate) [Intermediate 2]
Sectigo RSA DV / OV / EV security server CA [Intermediate 1]
End entity [leaf certificate]

Trust chain path B:
USERTrust RSA Certification Authority (Root CA) [Root]
Sectigo RSA DV / OV / EV Security Server CA [Intermediate 1]
End entity [leaf certificate]

Sectigo-Hierarchiekette

Previous Can I use my old CSR?
Next Configure security for FileMaker Server 14 and earlier
Table of Contents