9 min read
SSL TLS Settings in Chrome and How to Configure Them
Chrome has no single SSL/TLS settings page. The controls are spread across chrome://settings/security (HTTPS-First Mode, secure DNS, certificate manager), chrome://settings/certificates (trusted roots), chrome://flags (experimental TLS features) and the DevTools Security panel (inspect a live connection). Chrome 152, the current stable release in August 2026, supports only TLS 1.2 and TLS 1.3, enables post-quantum key exchange by default, and will turn on “Always Use Secure Connections” for every user in Chrome 154 this October.
SSL and TLS are the encryption protocols that protect data between your browser and a website. SSL is the old name; every modern connection uses TLS, but the term “SSL” has stuck in error messages and certificate products. Chrome enforces current standards aggressively, so an expired certificate, a server stuck on TLS 1.0 or a wrong system clock will block the page with a full-screen warning.
This guide covers where each setting lives, what Chrome’s security indicators mean now that the padlock is gone, the errors you will actually see, and how to fix them on both the browser and the server side.
How SSL/TLS Works in Chrome
When you open an HTTPS site, Chrome and the server run a TLS handshake. Chrome checks the server’s certificate against its own root store (the Chrome Root Program, not the operating system’s list), agrees a cipher suite, and exchanges keys to encrypt the session. Since Chrome 131 that key exchange defaults to X25519MLKEM768, a hybrid that adds a post-quantum algorithm alongside the classic one.
If any step fails, Chrome refuses to load the page. Common failure points are an expired or mis-issued certificate, a hostname mismatch, a server that only offers TLS 1.0 or 1.1 (removed from Chrome in version 84), or a middlebox such as antivirus software rewriting the connection.
The handshake does two jobs: it proves you are talking to the real site, and it keeps the data private and unaltered in transit. That is why Chrome treats a broken handshake as a hard stop rather than a soft warning.
SSL/TLS Indicators in the Chrome Interface
Chrome retired the padlock icon in version 117. The current indicators are:
- Tune (sliders) icon: the connection is secure. Click it for site permissions and “Connection is secure”, then “Certificate is valid” to open the certificate viewer.
- “Not secure” label: the page is plain HTTP, or it is HTTPS with mixed content. Chrome blocks insecure scripts and auto-upgrades insecure images where it can.
- Red warning triangle with “Not secure” or “Dangerous”: the certificate failed validation, or Safe Browsing has flagged the site.
The certificate viewer shows the issuer, validity dates, subject alternative names and the full chain. The TLS version and cipher are not in that dialog; use the DevTools Security panel described below.
How to Access SSL TLS Settings in Chrome
There is no dedicated SSL/TLS screen, but four places between them cover everything a user or developer needs.
chrome://settings/security
This is the main page. It holds Safe Browsing level, Always use secure connections (HTTPS-First Mode), secure DNS, and the link to Manage certificates. HTTPS-First Mode is already on for users with Enhanced Safe Browsing since Chrome 147 (April 2026) and becomes the default for everyone in Chrome 154 (October 2026). It warns before loading a public HTTP site but skips private addresses such as 192.168.x.x and intranet hosts.
chrome://settings/certificates
Chrome’s own certificate manager. On Windows and macOS it shows the Chrome Root Store, any roots imported from the operating system, and a section for custom certificates. This is where you add a trusted root for a local development CA or an enterprise proxy, and where you can see which roots Chrome has distrusted.
chrome://flags
Experimental features live here and can change or vanish between releases. Search for “TLS” or “Encrypted” to find items such as:
- Encrypted Client Hello (ECH)
- TLS 1.3 Early Data
- Post-quantum key agreement toggles
Leave these alone unless you are debugging. A flag that makes one site work will break others, and Chrome resets flags on major updates.
chrome://net-export
The old chrome://net-internals#events viewer was removed years ago. For a full handshake log, open chrome://net-export, start logging, reproduce the failure, stop, and load the JSON file in the NetLog viewer. It records certificate verification steps, negotiated protocol and error codes, which is what you need for enterprise or hosting support tickets.
Common SSL TLS Errors in Chrome
Chrome’s error codes are specific, which helps. These are the ones you will meet most often.
ERR_SSL_PROTOCOL_ERROR
Chrome could not complete the handshake at all. Typical causes:
- The server only offers TLS 1.0 or 1.1, which Chrome no longer speaks
- Antivirus or corporate HTTPS inspection is rewriting the connection
- A proxy, VPN or misbehaving extension is interfering
- The server is sending HTTP on port 443
NET::ERR_CERT_DATE_INVALID
The certificate has expired or is not yet valid, or your device clock is wrong. This error is about to get more common: since 15 March 2026 public TLS certificates can be valid for at most 200 days, dropping to 100 days in March 2027 and 47 days in March 2029 under the CA/Browser Forum’s SC-081 schedule. Sites without automated renewal will expire more often.
NET::ERR_CERT_AUTHORITY_INVALID
The certificate was not issued by a root in the Chrome Root Store. Self-signed certificates on local dev sites and internal tools trigger this, as do certificates from CAs that Chrome has distrusted.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Chrome and the server share no acceptable TLS version or cipher suite. Almost always an outdated server configuration, or a certificate using a weak signature algorithm such as SHA-1 or RSA keys under 2048 bits.
NET::ERR_CERT_COMMON_NAME_INVALID
The certificate is valid but not for this hostname. Usually a missing www or subdomain in the certificate’s subject alternative names.
Fixing SSL TLS Issues in Chrome
Work through these in order. The first three fix most user-side problems; the rest are for developers and site owners.
Keep Chrome Updated
Open chrome://settings/help. Chrome updates every four weeks and each release carries root store changes and TLS fixes. A browser more than two versions behind will start failing on sites that have moved to newer certificates.
Correct System Time and Date
Certificate validity is checked against your device clock. A few minutes of drift is enough for Chrome to reject a freshly issued certificate. Turn on automatic time sync and reload.
Clear SSL State and Cached Data
On Windows, open Internet Options (search “inetcpl.cpl”), go to Content and click Clear SSL state. Chrome uses this Windows store for client certificates and session data. On any OS, also clear cached images and files for the site in chrome://settings/clearBrowserData, and check chrome://net-internals/#hsts if you need to remove a stale HSTS entry for a development domain.
Temporarily Disable Antivirus HTTPS Scanning
Security suites that inspect HTTPS traffic act as a man-in-the-middle with their own certificate. If the error disappears with HTTPS scanning off, update or reconfigure the security software rather than leaving it disabled.
Test the Server, Not Just the Browser
If other people see the same error, the problem is on the server. Run the site through Qualys SSL Labs or openssl s_client -connect example.com:443 and look for: an incomplete certificate chain (missing intermediate), TLS 1.2 and 1.3 not both enabled, or an expired certificate that the auto-renewal cron did not replace. On WordPress hosts, a plugin or CDN layer can also serve the wrong certificate for the bare domain versus www.
Trusting Self-Signed Certificates
For local development, do not click through the warning every time. Create a local CA with mkcert, which installs its root into Chrome’s store automatically, or import your root manually:
- Export the root certificate from your dev tool (Local, DDEV, Laravel Valet and similar all provide one)
- Open
chrome://settings/certificates, choose Custom, and import it as a trusted root - Restart Chrome and reload the site
Managing TLS Versions in Chrome
Chrome supports TLS 1.2 and TLS 1.3 and nothing else. TLS 1.0 and 1.1 were removed in Chrome 84 and there is no flag or policy to bring them back. If an internal system still needs them, the fix is on that system.
What you can still influence:
- Post-quantum key exchange: on by default; enterprises can set the
PostQuantumKeyAgreementEnabledpolicy to false if a legacy middlebox breaks on the larger ClientHello. - Encrypted Client Hello: controlled by the
EncryptedClientHelloEnabledpolicy. - HTTPS-First Mode: the
HttpsOnlyModepolicy can force it on, allow users to choose, or disable it for managed devices.
Policies are applied through Group Policy on Windows, configuration profiles on macOS, or the Chrome Enterprise admin console. Check the result at chrome://policy.
Using Chrome DevTools to Inspect SSL/TLS
The Security panel is the fastest way to confirm what a live connection negotiated:
- Open DevTools (F12, or Cmd+Option+I on Mac)
- Click the Security tab (use the » menu if it is hidden)
- Read the overview: certificate validity, connection (for example “TLS 1.3, X25519MLKEM768, and AES_128_GCM”), and resources (mixed content)
The left pane lists every origin the page loaded from, so you can spot a CDN or embed that is dragging the page down to “Not secure”. This is the panel to check after an HTTPS migration or before launching a new site.
Best Practices for SSL TLS Security in Chrome
For users:
- Turn on Always use secure connections now rather than waiting for Chrome 154 to do it for you
- Use Enhanced Safe Browsing if you are comfortable with the data it sends to Google
- Do not click “Proceed” on a certificate warning for any site that handles a login or payment
- Keep Chrome and your operating system updated; both ship root store changes
For site owners and developers:
- Automate certificate renewal. With 200-day maximum validity and 47 days coming in 2029, manual renewal is no longer workable
- Enable TLS 1.2 and 1.3 only, serve the full chain, and redirect all HTTP to HTTPS
- Add an HSTS header once you are sure every subdomain is on HTTPS
- Fix mixed content at the source; Chrome’s auto-upgrade helps with images but not scripts or iframes
- Re-test after every CDN, hosting or plugin change
If you run a WordPress site and want this checked properly, our WordPress security hardening service covers TLS configuration, HSTS, mixed content cleanup and renewal automation, and our care plans keep it monitored afterwards. If you suspect a certificate error is a symptom of something worse, read 5 signs your WordPress site has been hacked first.
Frequently asked questions
Where is the padlock in Chrome?
Gone since Chrome 117. A secure connection shows the tune (sliders) icon to the left of the address. Click it, then “Connection is secure”, to reach the certificate details.
Can I enable TLS 1.0 or 1.1 in Chrome?
No. Support was removed in Chrome 84 and there is no flag or enterprise policy that restores it. Upgrade the server, or use a reverse proxy that terminates TLS with a modern version.
Why does a valid certificate show NET::ERR_CERT_DATE_INVALID?
Check the device clock first. If the clock is right, the certificate has probably expired; with 200-day lifetimes now the maximum, sites without auto-renewal expire more often than they used to.
How do I see which TLS version a site uses?
Open DevTools, go to the Security tab, and read the Connection line. It shows the protocol, key exchange and cipher for the main document and every loaded origin.
Will HTTPS-First Mode break my intranet sites?
No. Chrome’s “Always use secure connections” warns only for public HTTP sites and exempts private IP ranges and single-label intranet hostnames. Enterprises can fine-tune it with the HttpsOnlyMode policy.
Where to start
If you are a user seeing an error, update Chrome, fix the clock, and try another device. If the error follows the site across devices, it is the server. If you are a developer, open the DevTools Security tab before anything else; it tells you in one screen whether the problem is the certificate, the protocol or mixed content. Sources for the dates above: Google’s HTTPS by default announcement and the CA/Browser Forum’s SC-081 ballot.
Interesting Reads:
Hardening Your WordPress Site: Effective Measures to Improve Security
Related reading