When you access a website, a padlock icon appears in the address bar. The browser verifies the certificate sent by the server to determine if it matches the connected domain, if the certificate is valid, and if it was issued by a trusted Certificate Authority.
This raises a question:
How does the browser know which Certificate Authorities to trust?
The standard for this is the Root Store, which is a list of trusted root Certificate Authorities. While it’s commonly said that “browsers have a built-in list of Certificate Authorities,” the actual structure is a bit more complex. Browsers might use their own lists, or the operating system’s list, and company administrators can also add separate private Certificate Authorities.
This article examines what the lists of Certificate Authorities registered in browsers and operating systems are, how Chrome, Firefox, and Safari differ from each other, and what happens when a Certificate Authority is included in or removed from these lists.
The structure by which a browser verifies trust in a root Certificate Authority by following the certificate chain
Three Types of Certificates to Distinguish First
To understand HTTPS certificates, you need to distinguish between server certificates, intermediate certificates, and root certificates.
| Category | Role | Typical Location |
|---|---|---|
| Server Certificate | Links the connected domain with its public key | Delivered by the web server to the browser |
| Intermediate Certificate | Issues server certificates on behalf of the root CA | Delivered by the web server as part of the chain |
| Root Certificate | The ultimate trust anchor of the certificate chain | Browser or OS Root Store |
For example, let’s assume that the server certificate for www.example.com is signed by an intermediate CA, and that intermediate CA certificate leads to a root CA.
신뢰된 루트 CA
└── 중간 CA
└── www.example.com 서버 인증서The browser verifies the certificate chain sent by the server to confirm that it connects to a root that the browser trusts. This is called certificate path validation or Chain of Trust validation.
It’s important to note that the root certificate list contains the Certificate Authority’s public key and identity information. The Certificate Authority’s private key is not stored in the browser. The root CA’s private key is protected separately by the Certificate Authority, and the browser verifies the signature’s validity using the public key.
A Root Store is Not Just a Collection of Certificate Files
A Root Store is fundamentally a collection of root certificates to be used as trust anchors. However, in actual products, various policies are applied alongside the certificates.
- Whether a specific root CA is trusted
- Whether it can be used for TLS server authentication
- Restrictions on DNS names or issuance times to which the certificate applies
- Blocked CAs and certificates
- Certificate Transparency requirements
- Allowed key sizes and signature algorithms
- Maximum validity period for server certificates
- Certificate revocation information
Therefore, simply having the same root certificate does not mean all browsers will produce exactly the same results. This is because the method of constructing the certificate path, intermediate certificate selection, revocation checking, local policies, and browser-specific additional security rules can differ.
It’s easier to understand a Root Store as follows:
A Root Store is not a list that says “unconditionally trust this Certificate Authority,” but rather a collection of trust anchors from which certificate validation can begin, along with the policies to apply to that trust.
Chrome Now Uses Its Own Root Store
In the past, Chrome heavily relied on the certificate stores and validation functions of operating systems like Windows and macOS. With this approach, certificate validation results could vary depending on the operating system, even for the same Chrome version.
Currently, Chrome uses the Chrome Root Store and Chrome Certificate Verifier on supported major platforms. Google manages the public CA list based on its publicly operated root program, and Chrome validates certificate paths in a consistent manner.
The characteristics of the Chrome Root Store are as follows:
- Google manages the public root CAs that Chrome trusts by default.
- The Root Store is included in the Chrome binary.
- Changed lists can be distributed separately from full browser updates via the Component Updater.
- Typical Root Store updates can occur approximately quarterly.
- In case of urgent security issues, changes can be made outside of the regular schedule.
- Chrome applies additional policies such as Certificate Transparency and certificate validity periods, in addition to RFC 5280-based validation.
The Chrome Root Program defines the minimum requirements for a CA to be included in the public root list. Compliance with CA/Browser Forum’s Baseline Requirements, public disclosure of information in CCADB, regular audits, and incident response are important evaluation factors.
Will a company’s private CA be ignored if Chrome uses its own Root Store?
No, it will not.
The Chrome Certificate Verifier, separate from the Chrome Root Store for the public web, also considers trust decisions configured locally by users or organization administrators. For example, if a company has deployed an internal root CA via Windows Group Policy or macOS management profiles, Chrome can use it when validating certificates for internal sites.
However, public roots and local roots do not have the same meaning.
| Item | Public Root CA | Local/Private Root CA |
|---|---|---|
| Primary Use | Public internet sites | Internal systems, development environments, security proxies |
| Inclusion Authority | Browser/OS Root Program | User or organization administrator |
| Scope of Application | Many users using that Root Store | Devices and accounts where the certificate is installed |
| Validation Criteria | Public policies, audits, CCADB, industry requirements | Internal organizational policies |
| Impact of incorrect trust | Risk of global certificate misissuance | Risk of HTTPS interception within the managed scope |
Chrome’s official documentation also explains a detailed difference: local trust decisions are considered for adding and removing trust in TCP-based TLS connections, while for QUIC connections, only trust removal from local decisions is considered. Therefore, in environments using private PKI, the behavior of TCP and QUIC, browser policies, and actual deployment methods must be tested together.
How to check the list in Chrome
To check the contents of the Chrome Root Store actually used by Chrome, you can use the following internal page:
chrome://systemOn the page, expanding the chromerootstore item allows you to view the Root Store information currently recognized by Chrome.
Certificate management can be accessed from the following page:
chrome://certificate-managerThe screen configuration and available features may vary depending on the Chrome version and operating system. It is important not to interpret the public root list, locally added certificates, and OS-managed certificates as the same thing.
Firefox Operates Centered on the Mozilla Root Store
Firefox has long used its own list of root certificates managed by Mozilla. CAs to be included in the Mozilla Root Store must comply with the requirements of the Mozilla Root Store Policy and the CA Certificate Program.
Because of this, there have been cases where Chrome works fine on the same computer, but Firefox shows a SECERRORUNKNOWN_ISSUER error. A typical scenario is an environment where a company’s private CA is registered in the operating system, but Firefox does not use it.
Recently, Firefox has started to automatically find and trust third-party root certificates added to the operating system on Windows, macOS, and Android. This behavior has been enabled by default for general users since Firefox 120.
In settings, it can be managed with the following item:
설정
└── 개인정보 및 보안
└── 인증서
└── 설치한 제3자 루트 인증서를 Firefox가 자동으로 신뢰하도록 허용In enterprise environments, the security.enterprise_roots.enabled setting or Firefox Enterprise Policy can be used. On Linux, the PKI structure of the distribution and p11-kit integration must be checked separately.
Firefox’s behavior can be summarized as follows:
- The primary trust anchor for the public web is the Mozilla Root Store.
- Third-party CAs added by the operating system or organization can also be used depending on settings and platform.
- Separate CAs can also be imported in Firefox’s certificate manager.
- The public Root Store and an organization’s private CA are different sources of trust.
Safari Uses Apple Operating System’s Trust Store
Safari uses the Apple platform’s Root Store and certificate validation system. Apple manages and publishes the list of root certificates to be used on iOS, iPadOS, macOS, tvOS, visionOS, and watchOS.
Apple operating systems use a shared Root Store, and trusted roots and blocked certificates for each OS version can be found in Apple support documentation.
On macOS, certificates can be viewed via Keychain Access or System Settings.
응용 프로그램
└── 유틸리티
└── 키체인 접근
└── 시스템 루트 / 시스템 / 로그인These three keychains have different meanings:
- System Roots: Root certificates provided by Apple by default
- System: Organization/administrator certificates installed across the entire device
- Login: Certificates installed for the current user
Organizations can deploy private root CAs via MDM configuration profiles. Certificates manually installed by users may require additional trust settings depending on platform policies.
Chrome for iOS is no exception. Due to Apple’s platform policies, Chrome for iOS cannot use the Chrome Root Store and Chrome Certificate Verifier, and relies on Apple’s certificate validation system. Therefore, even though it’s called Chrome, its Root Store behavior should not be assumed to be the same as desktop Chrome.
How do Windows Root Store and Edge differ?
Windows distributes trusted roots and untrusted certificate lists through the Microsoft Trusted Root Certificate Program. Windows and applications use the Certificate Trust List, or CTL, to determine certificate trust.
Windows generally has the following certificate storage scopes:
- Local Computer
- Current User
- Group Policy
- Enterprise
- Trusted Root Certification Authorities
- Untrusted Certificates
Management tools are divided as follows:
certmgr.msc # Current user certificate
certlm.msc # Local computer certificateWindows can update Trusted CTLs and Untrusted CTLs through an automatic mechanism based on Windows Update. According to Microsoft documentation, automatic updates can be disabled, but this is not recommended for security reasons.
It’s important to note that not all public roots visible in the Windows certificate management screen are necessarily pre-installed as files. Trust information and certificates can be supplied when needed through CTLs and the automatic root update mechanism.
Although Edge is also Chromium-based, it should not be assumed to be entirely identical to Chrome in terms of product policies and platform integration points. Especially in enterprise environments, Edge policies, Windows certificate stores, and the application of public Root Stores and local CAs must be verified on the actual target version.
Reasons Why Trust Results Differ Across Browsers
The same site might work normally in one browser but trigger a warning in another.
| Cause | Explanation |
|---|---|
| Root Store differences | One program might have a root CA while another does not |
| Missing intermediate certificate | Server not sending a complete chain leads to different browser-specific completion results |
| Path construction differences | Different paths chosen when multiple cross-signed certificates exist |
| Local CA integration differences | Different ways of reading private CAs added to the operating system |
| Revocation information differences | Different application methods for CRL, OCSP, and browser-specific blocklists |
| Additional security policies | Different application of CT, algorithms, certificate lifetime, and name constraints |
| Product/OS version | Different update timings for Root Store and validation logic |
When an error occurs, immediately installing a root certificate is not a good first response. First, you should verify that the server is providing a correct certificate chain.
It is safer to investigate in the following order:
- Check if the connected hostname matches the certificate’s SAN.
- Check the validity period of the server certificate.
- Check if the server sends all necessary intermediate certificates.
- Determine which root CA the chain connects to.
- Verify if that root is in the browser’s public Root Store or an approved local store.
- Check if a security proxy or antivirus is re-signing HTTPS in the middle.
- Check the update status of the browser, operating system, and Root Store.
Reasons for Adding Private Root CAs to Company PCs
In enterprise environments, there are cases where public CAs alone are insufficient.
- Issuing certificates for internal domains and services
- Applying TLS in development/testing environments
- Device authentication and mutual TLS
- HTTPS inspection by security proxies
- DLP, malware analysis, and access control
HTTPS inspection devices, in particular, split the TLS connection into two between the client and the external site.
브라우저 ← TLS 1 → 보안 프록시 ← TLS 2 → 외부 웹사이트The security proxy verifies the external site’s certificate, then dynamically creates a new certificate for the accessed domain and provides it to the browser. For the browser to accept this certificate without warning, the security proxy’s root CA must be installed in the client’s trust store.
This can be a necessary operational control, but it grants very strong authority. A system possessing the private key of such a root CA can generate certificates for various HTTPS sites on managed devices.
When deploying a private root CA, at least the following controls are necessary:
- Protect the root CA private key in an HSM or offline environment
- Actual issuance performed by a restricted intermediate CA
- Audit certificate issuance and administrator actions
- Minimize target devices and usage purposes
- Revoke certificates and policies for departing employees, lost devices, and decommissioned devices
- Establish expiration and replacement plans
- Define TLS inspection exclusions and personal data processing standards
- Jointly review Root Store and proxy policies in case of failure
Process for a Root CA to be Included in the List
A public CA sending a single certificate to a browser company does not immediately result in trust.
Generally, the following procedures and ongoing obligations are required:
- Fulfill the inclusion requirements of the Root Program.
- Publish the Certificate Policy (CP) and Certification Practice Statement (CPS).
- Undergo independent audits from WebTrust or ETSI families.
- Disclose root and intermediate CA information in CCADB.
- Respond to public reviews and inquiries.
- Comply with CA/Browser Forum Baseline Requirements.
- Report and respond to certificate misissuance and security incidents.
- Continue regular audits and policy compliance even after inclusion.
Trust is not a permanent right. If policy violations, certificate misissuance, audit failures, private key compromise, or insufficient incident response occur, a root may be restricted or removed.
Even if a root CA is removed, not all already issued certificates will fail simultaneously in the same way. Results can vary depending on browser version, Root Store update status, cross-signing paths, certificate issuance time constraints, and local policies.
Why Root Store Updates Are Security Updates
Changes to the Root Store are not merely a reorganization of certificate lists.
Adding a new CA means that certificates issued by that CA can be trusted by default. Conversely, removing a problematic CA can prevent browsers from trusting certificates even if an attacker has improperly obtained them.
Browsers or operating systems that have stopped receiving updates may encounter the following issues:
- Failure to access legitimate sites using new root CAs
- Continued trust in removed CAs
- Non-application of new certificate restrictions and blocking policies
- Use of outdated algorithms and validation logic
- Inconsistencies with private PKI changes
In isolated networks, browser automatic updates and Windows CTL updates are often blocked. In such cases, it’s necessary to separately verify whether distributing only the browser executable is sufficient, or if the Root Store components and untrusted certificate lists are also being updated.
Key Questions for Operators to Check
When dealing with Root Store issues, simply asking “Is the certificate installed?” is insufficient.
| Question to Check | Reason |
|---|---|
| Who manages this browser’s public trust list? | Chrome, Mozilla, Apple, Microsoft programs differ |
| On the current platform, which is used: its own Store or the OS Store? | The same browser can have platform-specific differences |
| To what extent is the local CA added by the organization installed? | User, device, and group policy application scopes differ |
| Is this CA trusted for TLS server authentication purposes? | Even if a certificate exists, it can fail due to usage restrictions |
| How are the Root Store and blocklists updated? | Important in isolated networks and update-blocked environments |
| Is the server sending intermediate certificates correctly? | One of the most common chain errors |
| Is the HTTPS inspection device re-signing certificates? | The issuer seen by the browser might differ from the original CA |
| Are the root CA private key and issuance system secure? | Private CA compromise affects the entire organization’s TLS trust |
## Conclusion: The Browser’s Padlock is the Result of Trust Lists and Policies
Browsers do not know all certificates in the world in advance. They validate a chain extending from a trusted root CA to the server certificate.
Chrome uses its own Chrome Root Store and certificate verifier, while also considering local trust deployed by organizations. Firefox operates centered on the Mozilla Root Store but can also utilize third-party roots added to the operating system. Safari and Chrome for iOS rely on Apple’s platform trust store and validation system. Windows manages system trust information through the Microsoft Root Certificate Program and CTL update mechanism.
Ultimately, the HTTPS padlock is not created by a single encryption algorithm alone.
It is the result of the Root Program that determines which Certificate Authorities to trust, the Root Store deployed on the device, the certificate chain provided by the server, the browser’s validation policies, and the organization’s local trust decisions, all working together.
When resolving certificate errors, rather than blindly installing a root certificate, you should first determine which Root Store is being used and why the chain is not trusted. Especially in environments with private CAs and HTTPS inspection, the scope of authority granted by trust added for convenience must be managed carefully.
Leave a Reply