Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteCertificate authorities (CAs) help secure the web by checking certificate requests, issuing certificates that bind public keys to domain names, protecting the systems and keys used to issue them, and responding when certificates must be revoked. But a CA is only one part of the trust system: browsers and operating systems choose which CA roots they trust, while audits and Certificate Transparency logs make some CA activity inspectable.
What a certificate authority does in a secure connection
A public TLS certificate associates a public key with a domain name and other information. The server uses the corresponding private key during a TLS connection to prove possession of that key. The certificate helps the client decide whether the public key is authorized for the site name it is visiting; it does not, by itself, prove that the site is honest or safe in every other respect.
- The site requests a certificate. It supplies a certificate request and agrees to the CA’s subscriber terms.
- The CA checks the request. It verifies the domain authorization and any additional identity information required for the certificate type.
- The CA issues and manages the certificate. It signs the certificate using CA-controlled systems and handles later lifecycle events such as renewal, re-keying, and revocation.
- The client evaluates the certificate. The browser or operating system checks the certificate and its chain, including the site name, validity period, applicable constraints, and whether the chain reaches a trust anchor it accepts.
The CA/Browser Forum describes its TLS Baseline Requirements as an integrated set of technologies, protocols, identity-proofing, lifecycle-management, and auditing requirements for publicly trusted TLS certificates. They are a minimum framework, not a complete guarantee of security. Their effect depends on adoption and enforcement by the software suppliers whose products rely on certificates. CA/Browser Forum TLS Baseline Requirements
Who decides which certificate authorities are trusted?
Issuing a certificate does not automatically make it trusted by every browser, device, or application. The relevant software supplier controls the roots included in its trust store and sets the conditions for their inclusion and continued recognition. For example, Google’s Chrome Root Program publishes its own admission and ongoing-inclusion requirements. Those are Chrome program policies, not universal rules for every browser. Chrome Root Program: Apply for Inclusion
#1 Best Overall
During a connection, a client evaluates the certificate chain toward a trust anchor in its own store. A certificate can therefore be accepted in one software environment and rejected in another if their trust stores or policies differ. A lock icon indicates that the connection meets the browser’s applicable checks; it is not a general endorsement of the site’s ownership, conduct, or content.
Public web PKI and internal company certificates are different
The public TLS Baseline Requirements apply to publicly trusted certificates in chains whose root certificates are distributed by widely available application software. A company can instead install its own root certificate on managed devices and use it to secure internal services. Such an internal PKI is not automatically governed by the public TLS requirements if its root is not distributed by application software suppliers. CA/Browser Forum: About the Baseline Requirements
| Trust environment | Who controls the relevant root | What determines client acceptance |
|---|---|---|
| Public browser-trusted TLS | The software supplier controls inclusion of roots in its trust store; CA/Browser Forum requirements apply to publicly trusted chains when adopted and enforced by relying-party software suppliers. CA/Browser Forum TLS Baseline Requirements | The client’s trust store and applicable software policies, along with the certificate and chain checks. |
| Internal enterprise PKI | The organization installs or manages its own root for its managed environment. | Whether the organization has provisioned that root to the client device. Public TLS Baseline Requirements exclude enterprise roots not distributed by application software suppliers. CA/Browser Forum scope explanation |
How CAs validate certificate requests
Before issuance, a CA must receive a certificate request and a subscriber agreement or terms of use. It then verifies the claims needed for the requested certificate. Domain validation establishes that the requester is authorized to use or control the requested domain through an approved method. Organizational validation adds checks about the organization. These are different forms of assurance: not every certificate verifies the same facts about the person or business behind a site. TLS Baseline Requirements and CA/Browser Forum FAQ
Validation information also has a limited useful life. Under the CA/Browser Forum TLS Baseline Requirements version 2.3.0, dated 7 September 2026, domain-name and IP-address validation data may be reused for no more than 200 days effective 15 March 2026. The same version sets a maximum 200-day validity period for subscriber certificates effective 15 March 2026. These are normative limits for certificates within the requirements’ scope, not measurements of typical CA practice; consult the current requirements for details and later changes. Current TLS Baseline Requirements
Free tools Windows power users keep installed
One-click scans. No signup required.
How CAs protect their signing keys and systems
A CA’s signing keys are high-value assets: if an attacker compromises a key or the systems authorized to use it, the attacker could undermine certificates issued under that authority. The TLS requirements therefore address key generation, backup, storage, recovery, archival, and destruction, as well as lifecycle controls for cryptographic devices. They also require security programs covering certificate systems, certificate-management systems, and root CA systems. TLS Baseline Requirements
Hardware security modules (HSMs) are a category of cryptographic device used in institutional key management. Their relevance here is at the CA operations level: the cited requirements address cryptographic-device lifecycle and key controls but do not endorse a particular vendor or model. An enterprise HSM is not the same thing as a consumer USB authentication key, and running an ordinary small website does not by itself mean the site operator needs an HSM.
Rank #3
Separate CA/Browser Forum network and certificate-system security requirements add operational monitoring controls. They call for monitoring and logging capable of detecting critical security events and unauthorized changes, continuous log-integrity monitoring or personnel review at least monthly, automated log processing, and alerts through multiple channels. Personnel must begin an initial response within 24 hours of an alert. That is a response requirement for specified alerts, not a promise that every attack will be prevented or detected. Network and Certificate System Security Requirements
How certificates are managed and revoked
Issuance is not the end of a CA’s responsibility. CAs manage certificates through renewal and re-keying, and revoke them when specified problems make continued reliance unsafe. The TLS requirements include triggers such as private-key compromise, misuse, inaccurate certificate information, or evidence that the domain validation should not be relied on. For specified subscriber-certificate events, the CA must revoke within five days; the requirements recommend action within 24 hours. CAs must also maintain a continuous 24/7 process for receiving and responding to revocation requests and certificate problem reports. The precise trigger and deadline depend on the circumstances set out in the current requirements. TLS Baseline Requirements
Recommended Free Tools
Two mechanisms help clients and other relying parties learn that a certificate has been revoked:
- Certificate Revocation Lists (CRLs) are signed lists published by a CA that identify revoked certificates.
- Online Certificate Status Protocol (OCSP) provides certificate-status information in response to a query.
The standards specify publication and update behavior for these mechanisms, but they do not make revocation instantaneous across every client. Whether and when a browser or other client checks or enforces status can vary; revocation is not a guarantee that every connection will immediately reject a certificate after the CA acts. TLS Baseline Requirements
How audits and logs make CA activity accountable
CAs create records of certificate requests, validation activity, approvals and rejections, issuance, revocation, key events, security events, and relevant network or facility events. The TLS requirements specify minimum retention periods for certain records and require that records be available to qualified auditors. The separate network-security requirements add log integrity monitoring, automated processing, alerting, and response controls. Audits provide evidence about whether defined requirements were met; they cannot guarantee that no error or security failure has occurred. TLS Baseline Requirements and Network and Certificate System Security Requirements
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What Certificate Transparency reveals—and what it does not
Certificate Transparency (CT), specified in IETF RFC 9162, is a public logging system for TLS server certificates. A CT log returns a Signed Certificate Timestamp (SCT) for an accepted submission and retains certificate chains so that issuance can be audited. Public inspection makes it possible to spot certificates that appear suspicious or unexpected. IETF RFC 9162: Certificate Transparency Version 2.0
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Best Value
CT is visibility, not domain validation: a logged certificate does not prove that the CA correctly established the requester’s domain rights. Nor does CT decide which CA roots a browser trusts or replace revocation. Browser-specific CT policies determine when CT evidence is required for validation. Chrome, for example, publishes its own policy and recognized-log rules; a certificate that fails the applicable Chrome CT conditions can fail validation in Chrome versions enforcing those conditions. These rules are specific to Chrome and can change. Chrome Certificate Transparency Policy
How to interpret the browser’s trust signal
A secure connection depends on several controls working together: the CA’s validation and issuance process, protection of CA keys and systems, certificate lifecycle management, the relevant software trust store and its policies, and mechanisms for oversight such as audits and CT. The browser’s successful certificate check means the connection passed the checks that browser applies; it does not certify every aspect of the site. The CA/Browser Forum FAQ explains why its Baseline Requirements matter, while the current requirements page is the better reference for operative rules and dates. CA/Browser Forum FAQ
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
