How to Fix the ERR_SSL_SERVER_CERT_BAD_FORMAT Error

ERR_SSL_SERVER_CERT_BAD_FORMAT is the error Chrome shows when the certificate a website sent could not be read at all. The page fails with the heading “This site can’t provide a secure connection” and a line saying the site doesn’t adhere to security standards. There is no Advanced link, no button, and no way to continue.

That missing bypass is the clue to what is really happening. Chrome is not telling you it distrusts the certificate. It is telling you it could not decode the certificate into anything it can examine, so there is nothing to show you and nothing to override.

Quick answer: ERR_SSL_SERVER_CERT_BAD_FORMAT means Chrome could not decode the certificate the server presented, so it is fixed on the server, not in the browser. Open a terminal on the server and run openssl x509 -in certificate.crt -noout -text against the installed file. If the command fails, the file is truncated, corrupted, in the wrong format, or is not a certificate at all (a private key or a CSR installed by mistake). If it succeeds, check that it reports Version: 3 (0x2), because Chrome rejects a certificate that carries extensions without declaring version 3, and one that spells version 1 out instead of leaving the field off. Install a clean copy of the certificate and restart the web server.

This guide explains what the error means, why it is different from every other certificate error in Chrome, what actually causes it, how to fix it on the server, and which widely repeated steps cannot help.

Table of Contents

1. What Is the ERR_SSL_SERVER_CERT_BAD_FORMAT Error?
2. What Causes the ERR_SSL_SERVER_CERT_BAD_FORMAT Error?
3. How to Fix the ERR_SSL_SERVER_CERT_BAD_FORMAT Error
4. What to Do If You Are a Visitor, Not the Site Owner
5. What Does Not Fix This Error
6. Frequently Asked Questions

What Is the ERR_SSL_SERVER_CERT_BAD_FORMAT Error?

ERR_SSL_SERVER_CERT_BAD_FORMAT is network error -167 in Chromium, the engine behind Chrome, Edge, Brave, Opera and Vivaldi. Chromium’s own error list describes it as a certificate “which could not be decoded”, and adds that no certificate object is available and that the error is fatal.

Both of those details matter, and they follow from how a browser handles an SSL certificate. The work happens in two stages, and the two stages fail in different ways:

1. Decoding. The browser takes the bytes the server sent and tries to turn them into a certificate structure: a serial number, an issuer, a subject, validity dates, a public key, and a list of extensions. This is pure parsing. Nothing has been judged yet.
2. Validating. Only once a certificate exists can the browser ask the questions people usually associate with SSL errors: does the name match the site, has it expired, does it chain up to a trusted root, has it been revoked.

ERR_SSL_SERVER_CERT_BAD_FORMAT is a failure at stage one. The browser never reaches stage two. It does not know who issued the certificate, what hostname it covers, or when it expires, because it could not read those fields in the first place.

This also explains why there is no link to proceed anyway. Chrome groups its certificate errors into a dedicated range of error codes, and only errors in that range get the familiar red interstitial with an Advanced section. Error -167 sits outside that range, so Chrome treats it as a connection failure rather than a certificate warning. Chromium’s error page configuration for this code offers no suggestions and no buttons at all, which is why the page looks unusually bare.

How This Error Differs From Chrome’s Certificate Errors

If you have been told this error is caused by a self-signed or untrusted certificate, that advice belongs to a different error code. Here is where each one actually lands:

• ERR_SSL_SERVER_CERT_BAD_FORMAT (-167): the certificate could not be decoded. No interstitial, no bypass.
• NET::ERR_CERT_AUTHORITY_INVALID (-202): the certificate decoded perfectly, but it does not chain to a root the browser trusts. Self-signed certificates and certificates from an unknown certificate authority produce this, not the bad format error.
• NET::ERR_CERT_COMMON_NAME_INVALID (-200): the certificate decoded, but it does not cover the hostname you visited.
• NET::ERR_CERT_DATE_INVALID (-201): the certificate decoded, but it has expired or is not valid yet.
• ERR_SSL_PROTOCOL_ERROR: the handshake broke down before or around the certificate exchange, often because the server is not speaking TLS on that port at all.

The practical consequence: trust, hostnames, expiry dates and the chain of trust are all irrelevant to ERR_SSL_SERVER_CERT_BAD_FORMAT. The file itself is the problem.

What Causes the ERR_SSL_SERVER_CERT_BAD_FORMAT Error?

Almost every case traces back to the certificate file that was installed on the server. Certificates are shipped as text, they get copied through email, tickets, chat windows and control panel text boxes, and every one of those steps can damage them. These are the causes worth checking, roughly in the order they turn up.

1. The Certificate File Is Truncated or Corrupted

An upload that stopped early, a copy that missed the last line, or a single altered character in the encoded body is enough. A certificate has no error correction: change one character and the whole structure becomes unreadable. Losing just the closing marker line makes the file unusable even though it still looks complete at a glance.

2. The BEGIN and END Marker Lines Are Wrong

A PEM certificate has to open and close with these exact lines, five hyphens on each side:

-----BEGIN CERTIFICATE-----
MIIDazCCAlOgAwIBAgIUJ9m0kQ2Yb7pQ1t4vXKZ0sT8cRfEwDQYJKoZIhvcNAQEL
BQAwRTELMAkGA1UEBhMCVVMxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoM
[ many more lines of encoded certificate data ]
-----END CERTIFICATE-----

Word processors, ticketing systems and some chat clients quietly turn a run of hyphens into a single long dash character. The file still looks right to a human and is completely unreadable to software. The same happens if the markers lose their line breaks and end up glued to the encoded body.

3. Certificates Concatenated Without a Line Break Between Them

Building a chain file by joining the certificate and its intermediates is normal practice, but it only works if every marker line sits on its own line. If the certificate file does not end with a newline, joining it to the next file runs the END line straight into the following BEGIN line. Neither block can be read after that, and the server sends something the browser cannot decode.

Note that joining certificates in the wrong order is a different problem. That produces a broken chain, which shows up as an authority or chain error, not as a format error.

4. The Wrong File Was Installed

A certificate, a private key and a CSR all look like a block of encoded text between marker lines, and they arrive together at the end of an order. Pasting the key or the CSR into the certificate field is easy to do and the marker line is the only visible difference. Some servers and appliances accept the file without complaint and only fail later, when a browser tries to read what was sent.

5. A Binary File Where the Server Expects Text

Certificates come in several formats. PEM is the text form used by Apache, Nginx and most Linux software. DER is the raw binary form, often carrying a .cer or .der extension. PKCS#7 (.p7b) and PKCS#12 (.pfx or .p12) are containers that bundle several items together. Handing a binary DER file or a .pfx bundle to a server that was configured to read a PEM certificate is a common source of this error, and the file extension is not a reliable guide because .cer is used for both text and binary files.

6. The Certificate Is Not a Valid X.509 Version 3 Certificate

This is the cause that catches people out, because the file opens fine in every tool they try. Chrome’s parser is stricter than OpenSSL’s, and it rejects certificates that OpenSSL prints without complaint. Two rules matter most:

• Only a version 3 certificate may carry extensions. A certificate that declares version 1 or version 2 and still includes an extensions block is rejected outright.
• A certificate must not spell out version 1 explicitly. Version 1 is the default and the field has to be left out entirely, so writing it in is treated as malformed.

Every certificate issued by a public CA is version 3, so this rarely affects a purchased certificate. It affects certificates generated by appliances, embedded devices, internal scripts, older tooling and development helpers. Malformed validity dates and malformed subject or issuer names fail in exactly the same way.

7. A Control Panel or Middlebox Rewrote the Certificate

Some hosting panels strip line breaks, re-wrap the encoded text, or convert characters when you paste into a form. Load balancers, WAFs and TLS-terminating appliances add another place where the certificate can be stored and re-served in a damaged state. If the file on disk is clean but the browser still complains, check what the front-facing device is serving rather than what you uploaded.

The one genuinely client-side variant of this cause is covered further down: security software that inspects TLS traffic replaces every certificate with one it generates itself, and a faulty generator produces this error on every site at once.

How to Fix the ERR_SSL_SERVER_CERT_BAD_FORMAT Error

Work through these checks on the server. They are ordered so that the fastest test comes first, and each one narrows down what is wrong with the file. Replace the example paths with the real path from your web server configuration.

1. Check Whether the Certificate File Can Be Read at All

This single command answers most cases in a second:

openssl x509 -in /etc/ssl/certs/certificate.crt -noout -text

If the file is a healthy certificate, OpenSSL prints its full contents. If it is damaged or not a certificate at all, OpenSSL refuses it. The wording depends on the build: OpenSSL 3.0 and 3.1 say “Could not read certificate from certificate.crt”, OpenSSL 3.5 says “Could not find certificate from certificate.crt”, and the LibreSSL build that macOS ships as openssl says “unable to load certificate”. Either way, that refusal is the confirmation you are looking for: the file your web server was pointed at is not a readable certificate.

Read a successful result carefully, though. OpenSSL 3.x also accepts a binary DER file here and prints it just like a PEM one, so output that looks healthy does not prove the file is in the text format your server expects. Step 2 settles that question in one line.

For a shorter summary once the file does parse:

openssl x509 -in /etc/ssl/certs/certificate.crt -noout -subject -issuer -dates

2. Confirm You Installed the Certificate and Not the Key or the CSR

The first line of the file tells you what it is:

head -1 /etc/ssl/certs/certificate.crt

A certificate opens with BEGIN CERTIFICATE. A private key opens with BEGIN PRIVATE KEY or BEGIN RSA PRIVATE KEY. A signing request opens with BEGIN CERTIFICATE REQUEST. If you see one of those last two, you have found the problem: swap in the file the CA issued and leave the private key where it belongs, in the key setting, never in the certificate setting. If the line comes back as unreadable characters rather than any marker at all, the file is binary rather than text, and step 4 converts it.

3. Count the Marker Lines

These two counts must match, and neither may be zero:

grep -c -- "-----BEGIN CERTIFICATE-----" /etc/ssl/certs/certificate.crt
grep -c -- "-----END CERTIFICATE-----" /etc/ssl/certs/certificate.crt

The double hyphen after -c is required, otherwise grep reads the leading hyphens of the marker as its own options. A count of zero means the marker lines are not intact: they may be missing, misspelled, glued to the encoded body, or written with a dash character instead of five separate hyphens. A BEGIN count that is higher than the END count means the file was cut short.

If a count comes back as zero, do not try to repair the markers by hand. Download a fresh copy of the certificate from your CA account and install that instead.

4. Check PEM Against DER and Convert If Needed

If step 2 showed unreadable characters instead of a marker line, or the file will not read at all, test whether it is binary DER:

openssl x509 -in certificate.cer -inform der -noout -subject

If that works, the file is a valid certificate in the wrong encoding for your server. Convert it to PEM:

openssl x509 -in certificate.cer -inform der -out certificate.crt -outform pem

For .pfx and .p12 bundles, or if you would rather not run commands, the SSL Converter converts between formats in the browser, and our guide to SSL certificate conversion covers each direction.

5. Rebuild the Chain File Safely

If your server expects the certificate and its intermediates in one file, build it in a way that cannot glue two marker lines together. This version adds the missing line break automatically:

awk 1 certificate.crt intermediate.crt > bundle.crt

A plain cat of the same two files produces a broken bundle whenever the first file has no trailing newline, which is a frequent state for a certificate downloaded through a browser. Use a single angle bracket, as above: it creates the bundle fresh each time. Two angle brackets would append to whatever is already in the file and leave you with duplicated certificates.

Then confirm the bundle holds the number of certificates you expect and that the first block still reads:

grep -c -- "-----BEGIN CERTIFICATE-----" bundle.crt
openssl x509 -in bundle.crt -noout -subject

6. Confirm the Certificate Is Version 3

If the file reads perfectly and the error persists, check the version field:

openssl x509 -in /etc/ssl/certs/certificate.crt -noout -text | grep -A 1 "Data:"

The output should read Version: 3 (0x2). If it reads Version: 1 (0x0) or Version: 2 (0x1), the certificate cannot be used with modern browsers. A version 1 certificate has no extensions block, which means it has no Subject Alternative Name and no browser will accept it for a hostname. A version 1 or version 2 certificate that does contain extensions is malformed, and so is a certificate that writes the version field out as version 1 rather than leaving it off. Either one triggers ERR_SSL_SERVER_CERT_BAD_FORMAT while OpenSSL still prints the file happily.

If a device or script produced the certificate, regenerate it with the tool’s option for X.509 version 3 and a Subject Alternative Name. If a CA issued it, request a reissue.

7. Look at What the Server Is Actually Sending

The file on disk and the certificate on the wire are not always the same thing, especially behind a load balancer, a CDN or a reverse proxy. Fetch the live certificate and read it back:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Compare the subject and the dates with the certificate you installed. If they differ, the request is being answered by something other than the server you were editing. To question the origin server directly, put its IP address after -connect and keep your domain in -servername, which is how you find out whether the broken certificate lives on the origin or on the layer in front of it. To see the full chain the server offers, add -showcerts:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

One caution about reading this output. On its own, s_client reports “Verify return code: 0 (ok)” even when the certificate does not cover the hostname you asked for, because it checks the chain and not the name. Add -verify_hostname when you want the name checked too:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com </dev/null

On macOS, note that the bundled openssl is LibreSSL, which rejects this flag with unknown option -verify_hostname and prints its usage block instead of running. Install OpenSSL through Homebrew and run that binary instead. Confirm which one you are calling with openssl version, because /usr/bin comes first on the default PATH and plain openssl still reaches LibreSSL after the install. Call the Homebrew build by its full path, /opt/homebrew/bin/openssl on Apple silicon.

Remember that OpenSSL is more forgiving than Chrome. A certificate that s_client accepts can still be rejected by the browser, which is why the version check in step 6 is worth running even when everything here looks fine.

8. Reinstall the Certificate and Restart the Server

Once you know which file is at fault, replace it with a fresh copy rather than editing the damaged one:

1. Download the certificate again from your CA account or the issuance email, and keep it as a file. Do not paste it through a word processor, a spreadsheet or a chat window.
2. Upload it to the server as a file where the panel allows it, instead of pasting into a text box.
3. Point the web server configuration at the new file, along with the matching private key and the intermediate bundle.
4. Test the configuration before restarting. Nginx uses nginx -t, Apache uses apachectl configtest, and IIS reports binding problems in the site’s bindings dialog.
5. Restart or reload the web server so the new certificate is loaded into memory. A certificate replaced on disk has no effect until the running server reads it again.

Our step by step guides cover the details for each platform, including Nginx, Apache and IIS, and you can browse all our SSL installation guides for other servers.

When the site loads again, run a scan with our free SSL Checker to confirm the certificate, the chain and the expiry date are all reported correctly from the outside.

What to Do If You Are a Visitor, Not the Site Owner

If one particular site shows this error and everything else works, the certificate on that site is broken and nothing on your device can repair it. Report it to the site owner and move on. There is no setting to change and no way to continue past the page.

One situation is worth ruling out first: if you get the error on many unrelated sites, or on every HTTPS site, the certificates reaching your browser are probably not the real ones. Security software with HTTPS or SSL scanning, and corporate proxies that inspect encrypted traffic, work by generating a substitute certificate for every site you visit. If that generator is faulty or misconfigured, Chrome rejects everything it produces.

Two safe tests will tell you whether that is what is happening:

• Open the same site on a different network, for example a phone on mobile data instead of the office Wi-Fi. If it loads there, the problem is on the network you were using.
• Open the same site on another device on the same network. If only one machine is affected, the software on that machine is responsible.

If the tests point at your own machine, turn off only the HTTPS scanning, web shield or SSL inspection feature inside your security product, then reload the page. Leave the rest of the protection running. On a managed or company device, pass the findings to your IT team instead of changing the configuration yourself, because the inspection is usually there on purpose and the fix belongs on the proxy.

What Does Not Fix This Error

ERR_SSL_SERVER_CERT_BAD_FORMAT attracts a lot of generic browser troubleshooting that cannot apply to it. The reason is always the same: the verdict is decided entirely by the bytes the server sent, before your browser consults anything stored on your computer. The steps below are worth knowing about, so you can stop working through them and go to the server instead.

• Adding the site to Trusted Sites in Windows Internet Options. That list controls Internet Explorer security zones. It does not grant certificate trust, Chrome does not read it for that purpose, and no option to proceed anyway exists for this error because Chrome does not classify it as a certificate warning.
• Clearing the SSL state or the browser cache. A connection that failed to decode leaves nothing cached to clear. Clearing the SSL state is a genuine fix for other situations, such as a remembered client certificate choice after a certificate is replaced, but it has no bearing on this one.
• Disabling browser extensions. Extensions run above the network layer and cannot see or alter a TLS handshake. None of them can change the certificate a server sends or how Chrome decodes it.
• Updating the Windows root certificate store. Root certificates decide which issuers are trusted, and trust is never evaluated here. Chrome has also used its own Chrome Root Store as the source of public trust on Windows and macOS since Chrome 108, so the Windows store is not what Chrome consults for public certificates in the first place. If you do need that command for another reason, note that it takes a destination folder, as in certutil -syncWithWU C:\rootstore, and that it downloads the root files into that folder rather than installing them.
• Resetting Chrome to its defaults. Nothing in a Chrome profile influences certificate decoding, so this loses your settings without changing the outcome.
• Turning off your antivirus or firewall completely. A firewall either allows a connection or blocks it, it never rewrites a certificate. The only part of a security product that is relevant is HTTPS inspection, and that can be switched off on its own, as described in the previous section. Leaving your protection disabled is not a fix.
• Correcting the clock on your computer. Dates are read during validation, which this error never reaches. A wrong clock produces a date error instead.
• Updating Chrome. Keeping the browser current is good practice, but Chrome has enforced these certificate rules for years and a newer version is not more permissive. If a site works in an older browser and fails in a current one, the certificate still needs replacing.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.