What a root certificate is
A root certificate is a self-signed certificate: its issuer and subject are the same, and it is signed with its own private key. It sits at the top of a chain and acts as the trust anchor. Nothing inside it proves it is legitimate. It is trusted only because a browser, operating system or administrator put it in a trust store. For example, Mozilla treats a CA certificate as trusted only while it is unexpired, not listed in OneCRL, and either included in its root store or chained to a certificate that is. [Mozilla Wiki, CA Audit Statements]
Because a root is only a certificate that people choose to trust, anyone can make one in seconds, which is what the Generate tab does. A root made here is trusted by nobody until someone installs it. Local development tools such as mkcert do the same thing and then install the root in your system trust store, and their documentation warns that the root key gives complete power to intercept secure requests on that machine. [GitHub, FiloSottile/mkcert]
How public roots earn trust
Public roots are admitted through root store programs with formal requirements. Mozilla requires audits of its included roots and of intermediates that can issue server or email certificates. The audits must be repeated at least annually with no gaps between periods, done by independent, qualified auditors against standards such as WebTrust or ETSI. If a CA stops providing audit statements, the certificate can be removed from the store and added to OneCRL. [Mozilla, Root Store Policy] [Mozilla Wiki, CA Audit Statements]
Offline roots and intermediates
A CA protects its root key by using it rarely. Let's Encrypt keeps its root key material offline and issues subscriber certificates from intermediates, and it has said the root and intermediate private keys are stored on hardware security modules. This is why the Generate tab builds a three-level chain: the root signs the intermediate once, and the intermediate signs leaf certificates. [Let's Encrypt, Chains of Trust] [Let's Encrypt, Let's Encrypt Root and Intermediate Certificates]
One certificate can have more than one valid chain. For ECDSA subscriber certificates, Let's Encrypt offers a chain ending at ISRG Root X1, which is larger but works with the oldest clients, and a chain ending at ISRG Root X2, which is smaller but needs clients with newer trust stores. [Let's Encrypt, Chains of Trust]
Path length limits control how deep a chain may go. The path length constraint gives the maximum number of non-self-issued intermediate certificates that may follow a CA certificate, and it only applies when the CA flag is set. In this tool the root allows one intermediate and the intermediate allows none, so it can only sign leaf certificates. A certificate whose key usage includes certificate signing must also have the CA flag set. [IETF, RFC 5280: Internet X.509 PKI Certificate and CRL Profile]
What the Validate tab checks
The Validate tab checks that each certificate is inside its validity period, that each issuer name matches the next certificate, that each signature verifies with the issuer's public key, that every issuer has the CA flag, and optionally that the leaf covers a hostname. It is a teaching model. It does not check path length, name constraints, key usage on CA certificates or revocation, so a chain that passes here may still be rejected by a real browser.
For hostnames, the Common Name must not be used to identify a service. Clients match the name against the DNS entries in the subject alternative names. A wildcard is valid only as the whole left-most label and covers exactly one label, so *.example.test matches www.example.test but not a.b.example.test. [IETF, RFC 9525: Service Identity in TLS]
Lifetimes and revocation
Public TLS certificates are getting shorter lives. CA/Browser Forum ballot SC-081v3 sets a schedule that reduces the maximum validity from 398 days toward 47 days, starting in March 2026 and finishing in March 2029. The generated leaf lasts 200 days, a short life in keeping with that trend, while the CA certificates last years. [CA/Browser Forum, Ballot SC081v3]
Revocation tells clients to stop trusting a certificate before it expires. Let's Encrypt turned off its OCSP service on August 6, 2025 and now publishes revocation information only through certificate revocation lists. It named privacy as the main reason: with OCSP the CA learns which sites a visitor checks. This tool does not model revocation. [Let's Encrypt, OCSP Service Has Reached End of Life]