How to Fix SEC_ERROR_UNKNOWN_ISSUER in Firefox

Firefox blocks a page with SEC_ERROR_UNKNOWN_ISSUER when it cannot work out who issued the certificate a site presented, or cannot connect that issuer back to a root certificate it trusts. The certificate itself is often perfectly valid: issued by a real Certificate Authority, matching the domain, and nowhere near its expiry date. What failed is the chain between them.

Quick answer:

SEC_ERROR_UNKNOWN_ISSUER means Firefox could not build a chain of trust from the certificate a website presented back to a root certificate it trusts. It is not an expiry error, Firefox reports expiry separately as SEC_ERROR_EXPIRED_CERTIFICATE.

The most common cause is a server that sends only its own certificate and omits the intermediate certificate, so the fix belongs on the server: build a chain file with the leaf certificate first and the intermediate after it, point the web server at that file, test the configuration, reload, and re-check from outside your network.

When the error appears on one device or one network only, the usual cause is antivirus HTTPS scanning or a TLS-inspecting proxy re-signing traffic with a root Firefox does not trust. Do not delete cert9.db: that file holds the CA certificates and client certificates you imported into Firefox, so removing it can cause this error on internal sites rather than clear it, and it does not stop interception.

What SEC_ERROR_UNKNOWN_ISSUER Actually Means

Browsers do not trust certificates one at a time. They trust a small set of root certificates shipped in a trust store, and every other certificate has to link back to one of them. A normal HTTPS certificate is validated across three links:

1. The leaf certificate, issued for your domain, is the one your server presents.
2. The intermediate certificate signed that leaf. Certificate Authorities issue from intermediates rather than straight from their roots, so this link is present in practically every real chain.
3. The root certificate signed the intermediate, and the browser already holds it.

SEC_ERROR_UNKNOWN_ISSUER is what Firefox reports when it runs out of links before reaching a root. Either the certificate that signed the leaf was never sent and Firefox has no copy of it, or it was sent but leads to a root Firefox does not trust. You can read more about how those links fit together in our guide to the SSL chain of trust.

Notice what is missing from that description: nothing about expiry dates, nothing about the visitor’s browser cache, and nothing about the clock on the visitor’s computer. Firefox has separate codes for those. The only question behind this one is whether Firefox can identify the issuer and follow it up to a trusted root.

The codes that get mistaken for this one

When chain building fails, Firefox’s verifier runs two further checks and swaps in a more specific code if either matches. The neighboring codes are mutually exclusive with this one rather than variants of it, and each points at a different repair.

• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT replaces it when the issuer field equals the subject field and the signature verifies against the certificate’s own public key. A leaf issued by a real CA fails that test, so a missing intermediate cannot produce the self-signed code. Follow our guide to fixing MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT if that is your code.
• MOZILLA_PKIX_ERROR_MITM_DETECTED replaces it only in one narrow situation, described later on this page. Most interception surfaces as plain SEC_ERROR_UNKNOWN_ISSUER instead.
• SEC_ERROR_EXPIRED_CERTIFICATE means the certificate is past its validity period, a date problem rather than a trust problem. Renewing a certificate will not clear an unknown-issuer error.
• ERROR_SELF_SIGNED_CERT is not a code Firefox displays at all. Troubleshooting advice that quotes it is describing MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT.

What the same failure is called in other browsers

Every browser runs its own certificate verifier and names the result in its own way. If you support users across browsers, these are the equivalents worth recognizing:

• Chrome, Edge, Brave and Opera, all built on Chromium, report NET::ERR_CERT_AUTHORITY_INVALID under the Your connection is not private headline.
• Safari prints no code and says instead that it cannot verify the identity of the website.

Because the underlying condition is the same, a server-side fix resolves all of them at once. A fix that works in only one browser treated a symptom rather than the cause.

Why Firefox Shows It When Other Browsers Do Not

A large share of these reports come with the same complaint attached: the site loads fine in Chrome or Edge, and only Firefox refuses it. Or the reverse, it loads in Firefox and breaks everywhere else. A few design decisions in Firefox explain almost all of those cases.

1. Firefox maintains its own trust store

Chrome, Edge and Safari validate certificates against the store built into Windows or macOS. Chrome has since added a curated root list of its own, but it still honors roots that a user or an administrator installed locally on the machine. Firefox took a different route from the start: it ships Mozilla’s own root list, maintained through the Mozilla CA Certificate Program, and validates with its own engine, so a root that Windows trusts has never been automatically a root that Firefox trusts.

That single difference is why security software and corporate networks break Firefox specifically. Both work by re-signing your HTTPS traffic with a root certificate of their own, then installing that root in the operating system’s store during setup. Every browser that reads the system store accepts it silently. Firefox, reading its own list, sees a certificate signed by an authority it has never heard of, which is exactly this error.

Since Firefox 120, released in November 2023, that gap is closed by default. Mozilla’s release notes for that version state that Firefox now imports user-added TLS trust anchors from the operating system root store, enabled by default on Windows, macOS and Android, and switchable in Settings, Privacy & Security, Certificates. The preference behind it, security.enterprise_roots.enabled, ships set to true, so the older advice to flip it manually in about:config describes a version of Firefox from before that release.

Two limits are worth knowing. It covers only roots that a user or an administrator added, not the platform’s own built-in list, and it does not apply on Linux, where a root still has to be added to Firefox itself. So on a Linux desktop behind a filtering proxy, this error can persist long after every other browser on the machine has stopped complaining.

2. Firefox does not chase missing intermediates, it preloads them

Certificates carry an Authority Information Access extension holding a URL where the issuing intermediate can be downloaded. Chrome on desktop, Edge and Safari follow that URL and fetch a missing intermediate on demand, repairing a broken chain while the page loads.

Firefox deliberately does not do this. Mozilla rejected on-demand fetching because it delays the handshake and tells the Certificate Authority which site you are visiting. Instead, Firefox downloads the intermediates that CAs have disclosed to the Common CA Database in advance, through Mozilla’s Remote Settings service, and keeps them in your profile, so a chain can be completed even on your first visit to a site that uses one. They land in Firefox’s own certificate storage, the security_state folder of your profile, a separate store from the NSS certificate database in cert9.db that holds certificates you imported yourself.

Both mechanisms paper over the same server misconfiguration, and each fails in different circumstances, which turns a confusing inconsistency into a diagnosis:

• A chain that works in Chrome and fails in Firefox usually means the intermediate is missing from the server and was never disclosed to the Common CA Database, or has not synced to that profile yet. Chrome fetched it, Firefox had no copy.
• A chain that works in Firefox and fails elsewhere means Firefox preloaded the intermediate and hid the problem, while clients with a weaker repair mechanism were blocked. Command-line tools, API clients and Java applications typically have none at all. Android is a middle case: the platform validator that native apps use does not fetch a missing intermediate, while Chrome and WebView on Android do attempt it on a best-effort basis. That is why a broken chain can work in a phone’s browser and still fail inside a native app on the same phone.

Neither mechanism is a fix, and many clients implement no fallback at all. If a browser is repairing your chain, the server is still misconfigured, and payment callbacks, webhooks and mobile apps will keep failing on it.

3. Do not delete cert9.db

Advice to delete cert9.db circulates widely as a cure for this error. That file is the NSS certificate database in your Firefox profile, holding the CA certificates and client certificates you or an administrator imported. The preloaded intermediates described above are not in it, they sit in separate certificate storage in the same profile.

Deleting it can therefore make things worse. If you reach an intranet site, a staging server or an appliance whose private root you imported, throwing the database away throws that root away with it, and the site starts failing with this very error. Client certificates go too, which can lock you out of services that require one. Nor does it stop interception: antivirus HTTPS scanning and inspecting proxies re-sign each connection as it happens, so the warning returns on the next page load. Deleting cert9.db can cause this error and cannot cure it.

Why interception rarely says MITM_DETECTED

It is reasonable to expect that a proxy or antivirus intercepting your traffic would produce MOZILLA_PKIX_ERROR_MITM_DETECTED. In practice it usually does not, and the reason is a narrow condition in Firefox’s verifier.

Firefox only substitutes that code when the failing certificate’s issuer matches a stored canary value. The canary is populated from Firefox’s own update check: if that connection itself fails with an unknown-issuer result, Firefox records the issuer name it saw there. Later, when a website fails the same way, Firefox compares the two issuer names and swaps in the MITM code only on a match. If the canary was never set, or the interceptor’s issuer name differs from the one recorded, the error you get is plain SEC_ERROR_UNKNOWN_ISSUER.

The practical consequence: the absence of a MITM code does not rule out interception. That is why the local causes are covered fully on this page rather than pushed onto the MITM error’s page.

Diagnose It First: What Is the Server Actually Sending?

Each cause leaves a different fingerprint in the Issuer field of the certificate Firefox received. Two minutes of checking tells you which branch to take, and saves you from rewriting server configuration to fix something installed on your own laptop.

1. Read the issuer from the warning page

Firefox still hands you the certificate it rejected. On the warning page:

1. Click Advanced to expand the panel and confirm the code printed there really is SEC_ERROR_UNKNOWN_ISSUER.
2. Click View Certificate, which opens Firefox’s certificate viewer.
3. Compare the Issuer Name block against the Subject Name block, and check how many certificates the viewer lists in its tabs across the top.

What you read there maps straight onto a cause:

• A public CA you recognize (Sectigo, DigiCert, Let’s Encrypt, GlobalSign, Google Trust Services), a single certificate listed, and the chain still fails: the server is almost certainly not sending the intermediate certificate.
• The issuer name is identical to the subject name: the certificate is self-signed, and Firefox would normally report the self-signed code rather than this one.
• Your antivirus vendor, your firewall vendor, or a product name you recognize from your own machine: local HTTPS scanning is re-signing the traffic.
• Your employer’s or school’s name: a TLS-inspecting proxy on the network whose root Firefox does not trust.
• An internal CA name belonging to the organization that runs the site: a private CA whose root was never distributed to this machine.

2. Ask the server directly with OpenSSL

The browser view can mislead you, because Firefox may already hold a preloaded copy of the intermediate the server failed to send. To see exactly what your server transmits, query it from the command line:

openssl s_client -connect example.com:443 -servername example.com -showcerts

The -servername flag sends your hostname via SNI, as a browser does. Since OpenSSL 1.1.1 the tool fills SNI in automatically from the hostname in -connect, so it matters mainly when you point -connect at a raw IP address and still need to name the site. At the top of the output, the chain lists every certificate the server sent, with s: for subject and i: for issuer. A healthy chain is continuous:

Certificate chain
 0 s:CN=example.com
   i:C=US, O=Google Trust Services, CN=WE1
 1 s:C=US, O=Google Trust Services, CN=WE1
   i:C=US, O=Google Trust Services LLC, CN=GTS Root R4

Verify return code: 0 (ok)

Each certificate’s issuer is the subject of the next one down. A server missing its intermediate sends only certificate 0, and the last line names the problem:

depth=0 CN=*.badssl.com
verify error:num=20:unable to get local issuer certificate

Certificate chain
 0 s:CN=*.badssl.com
   i:C=US, O=Let's Encrypt, CN=R13

Verify return code: 21 (unable to verify the first certificate)

Verify return code: 21 is the signature of an incomplete chain and the fastest confirmation that the fix belongs on the server. The output above comes from incomplete-chain.badssl.com, a public test host you can query yourself. To read just that line without the command waiting for input:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep "Verify return code"

A handful of return codes cover nearly every case here. 21 (unable to verify the first certificate) means the intermediate is missing. 18 (self-signed certificate) means the certificate signed itself, a different error and a different repair. 10 (certificate has expired) at depth 1 or higher means an intermediate is past its expiry date, the second cause covered below. 0 (ok) means OpenSSL built a complete chain and trusted it, so the server is probably not the problem.

Read that last one carefully, because it proves less than it appears to. It is a verdict on the certificate chain and nothing else. It does not tell you the certificate covers the hostname you asked for, a separate check you request with -verify_hostname, and it is measured against whatever trust store your copy of OpenSSL was built with: usually the system CA store on Linux, and on macOS and Windows a bundle shipped with the OpenSSL build itself, so it is neither the list Firefox uses nor the list the operating system uses.

One note before you act on that line: the openssl command that ships with macOS is LibreSSL rather than OpenSSL. It reports a missing intermediate as 21 just as OpenSSL does, but its chain diagnostics diverge elsewhere: an intermediate that is present and expired stops it at depth 0 with that same 21, where OpenSSL names the failing certificate and returns 10, so a Mac result can send you after the wrong fault. Check which build you are running, and confirm anything surprising with an external scan:

openssl version

3. Confirm with an external scan

Run the domain through our free SSL Checker. It connects from outside your network, shows the chain your server presents, and flags a missing intermediate. That outside view matters: a chain often looks complete when tested on the server itself, where the intermediate already sits in the local certificate store, and is still incomplete for everyone else because the server never puts it on the wire.

How to Fix SEC_ERROR_UNKNOWN_ISSUER as a Website Owner

The causes below are ordered by how often they turn out to be the answer. If your diagnostic returned Verify return code: 21, start at the first one.

1. A missing or misordered intermediate certificate

This is the dominant cause, and the one most often missed, because nothing looks wrong. Your certificate is genuine, unexpired and issued for the right domain. The server simply never sends the intermediate that connects it to the CA’s root, so Firefox receives a certificate whose issuer it cannot locate.

It usually happens at installation time. Some CAs deliver everything in a single file, others send the leaf and the intermediates as separate downloads, often named as a CA bundle or chain file. When only the leaf gets installed, the chain breaks in exactly this way.

Build the full chain file

Concatenate your certificate and the intermediate into one file. The order is not optional: the leaf comes first, then each intermediate, working upward toward the root. The root itself can be left out, because clients that trust it already hold a copy.

cat example_com.crt example_com.ca-bundle > fullchain.crt

Verify the order before you deploy it. A reversed file is a common reason a fix appears to change nothing:

openssl crl2pkcs7 -nocrl -certfile fullchain.crt | openssl pkcs7 -print_certs -noout

Your domain must be listed first, and each certificate’s issuer must match the subject of the certificate printed after it. If the file starts with a CA name instead of your domain, rebuild it the other way around.

Point nginx at the full chain

Nginx has no separate directive for the chain. The file you give to ssl_certificate must already contain the leaf and the intermediates:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/certs/fullchain.crt;
    ssl_certificate_key /etc/ssl/private/example_com.key;
}

Test the configuration before applying it, then reload:

sudo nginx -t
sudo systemctl reload nginx

Point Apache at the full chain

On Apache 2.4.8 and later, SSLCertificateFile reads the intermediates from the same file, and the old SSLCertificateChainFile directive is obsolete. If your configuration still uses it, move the intermediates into the chain file and remove the directive:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on

    SSLCertificateFile    /etc/ssl/certs/fullchain.crt
    SSLCertificateKeyFile /etc/ssl/private/example_com.key
</VirtualHost>

Test and reload:

sudo apachectl configtest
sudo systemctl reload apache2

Point IIS at the intermediate

On Windows the chain is not configured in the site binding at all. IIS builds it from the machine’s certificate stores, so the intermediate has to be imported into the local computer’s Intermediate Certification Authorities store. Do it through the Certificates snap-in in MMC, choosing Computer account rather than the current user, or from an elevated command prompt:

certutil -addstore -f CA intermediate.crt

Restart the site afterwards so IIS rebuilds the chain it serves. On a load balancer, CDN or reverse proxy, the certificate and its chain belong on whichever device terminates TLS, which is frequently not the origin web server at all. Our installation tutorials cover the equivalent step on control panels, appliances and the platforms not listed here.

Re-verify from outside

After reloading, run the OpenSSL command again from a machine outside your network, or scan the domain with the SSL Checker. Certificate 1 should now appear in the chain and the verify code should read 0. Check in a fresh Firefox profile or a private window, so you are looking at the new chain rather than a page Firefox already decided about.

2. An expired intermediate certificate

The intermediate can be present in the chain and still break it, because intermediates have their own validity period and expire on their own schedule. A chain that worked for a year can fail overnight without anyone touching the server. Firefox sometimes names this case directly, as SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE, in which case you already have your diagnosis. It also surfaces as an unknown-issuer error, because a client that discards the expired intermediate is then left unable to build a path at all. Check the dates on the file you installed:

openssl x509 -in intermediate.crt -noout -subject -issuer -dates

If notAfter is in the past, download the current intermediate from your CA’s repository, rebuild the chain file with it, and reload. Your own certificate does not need reissuing. Our guide to the expired intermediate SSL certificate covers the case in detail.

Because an intermediate expires on a schedule nobody on your side controls, ACME certificate automation is worth having here: it replaces the certificate together with its chain, so a stale intermediate does not survive a renewal.

3. A self-signed certificate

Listed here only so you can rule it out quickly, because it normally produces a different code. A self-signed certificate is unmistakable in the certificate viewer, where the issuer and the subject carry the same name and OpenSSL returns verify code 18. Firefox reports that case as MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT rather than as an unknown-issuer error, so if this is what you are looking at, follow the guide to MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT instead.

4. A private or internal CA whose root was never distributed

Organizations often run their own CA for intranet sites, staging environments and internal APIs. That works only on devices where the organization’s root certificate has been installed. Any device without it receives a certificate signed by an authority it has never encountered, which produces this error.

The symptom is a site that loads for staff on managed laptops and fails on personal phones, contractor machines or a freshly imaged workstation. The fix is distribution rather than certificate replacement: push the internal root to managed devices through Group Policy on Windows, or through your MDM profile on macOS, iOS and Android. Firefox picks a properly deployed enterprise root up from those stores automatically, with the Linux exception noted earlier.

If the service also has to be reachable by people outside the organization, an internal CA is the wrong tool for it. Anything the public touches needs a publicly trusted SSL certificate.

5. Your CA was distrusted or removed from the root store

A certificate that worked yesterday can fail today with nothing changed on your server, because the trust decision lives in the browser rather than in your configuration. When a CA stops meeting root program requirements, browsers remove or restrict it, and every certificate chaining to the affected root starts failing.

Because Mozilla runs its own root program on its own timetable, Firefox and Chromium browsers rarely act on the same day. Two signals point here: the error appeared without any deployment on your side, and it appeared in one browser before the others. There is no server-side workaround. Reissue the certificate through a CA in good standing, install the new chain, and reload. A CA whose roots are being distrusted will normally reissue at no charge.

6. The wrong virtual host is answering the request

One IP address can host many sites, and the server picks which certificate to present from the hostname the client sends via SNI. When that lookup misses, the server falls back to its default virtual host and serves whatever certificate is configured there.

On a fresh install that default is often the self-signed placeholder shipped with the distribution or the control panel, which is why this error can appear on a domain whose certificate is installed and valid. You are not seeing your certificate at all. Confirm it by comparing the subject OpenSSL returns against the domain you requested, then check that a virtual host block exists for the exact hostname, including the www and non-www forms you serve, that it listens on port 443, and that it points at the correct chain file.

How to Fix SEC_ERROR_UNKNOWN_ISSUER as a Visitor

If the server is sending a broken chain, only the site operator can repair it. But a significant share of these errors are not the server’s fault, and those you can fix yourself. Rule out the local half before you report anything.

1. Work out whether it is only you

Open the same site on a phone using mobile data rather than Wi-Fi. That one test splits the problem cleanly:

• It fails there too, on a completely different device and network: the server is at fault, and the sections above are what needs to happen. Report it to the site.
• It loads there and fails on your computer: something on that computer or that network is intercepting the connection, and the checks below apply.
• It fails on most sites at once rather than on one: that is interception almost by definition. A single misconfigured server cannot break unrelated websites.

2. Turn off your security software’s HTTPS scanning

Many antivirus and internet security products include a feature called HTTPS scanning, SSL/TLS filtering, encrypted web scan or web shield. To inspect encrypted traffic, the product terminates the TLS connection itself, decrypts and scans the content, then re-encrypts it with a root certificate it installed on your machine at setup. Firefox is no longer looking at the website’s certificate, it is looking at one your antivirus generated seconds ago.

Usually the installer registers that root correctly and nothing looks unusual. The error shows up when the installation was incomplete, a cleanup tool removed the root, or you are on Linux where Firefox does not read the system store. Confirm it in the certificate viewer: if the issuer names your security product rather than a public CA, this is your cause.

Turn off only the HTTPS or SSL scanning component, not the antivirus itself. The setting lives under the web or network protection area of the product, and switching it off leaves file, email and behavioral protection running. Reload the page afterwards. If the error clears, either leave HTTPS scanning off or reinstall the product so its root registers properly.

Read the result the right way around, because this advice is often given backwards. If the error disappears while HTTPS scanning is off, the antivirus was the cause. If the error persists, the antivirus has been ruled out and you should move on to the next check.

3. Check whether you are behind a TLS-inspecting proxy

Corporate, school and guest networks routinely route traffic through a proxy or firewall that inspects HTTPS the same way antivirus software does, by re-signing every connection with the organization’s own root. Managed devices receive that root automatically, so most employees notice nothing. A personal laptop or a visitor’s phone on the same network has never seen it and gets blocked on nearly every HTTPS site.

The signature is an issuer named after the organization or its security vendor, plus errors on many sites at once. On a device your employer manages, ask IT to deploy the root certificate to the machine. Firefox will pick it up from the system store automatically, except on Linux, where it has to be imported into Firefox itself using Mozilla’s guide to setting Certificate Authorities in Firefox.

On a personal device, use a different network or mobile data instead of installing a corporate root yourself. Installing one gives whoever controls it the ability to read your encrypted traffic on that machine, including your own accounts, on that network and any other.

4. Rule out malware that installed its own root

Adware and malware use the same interception technique, with none of the consent. They install a root certificate on the victim’s machine and re-sign traffic through it, usually to inject advertising or harvest credentials. This has nothing to do with the SSL configuration of the site you were trying to reach: the interception happens entirely on your computer.

Suspect it when the issuer in the certificate viewer is a name you do not recognize and cannot account for, when the error started without you installing anything deliberately, or when it appears on banking and shopping sites in particular. Run a full malware scan, and work through Mozilla’s guide to Firefox issues caused by malware. Do not click through the warning while you are investigating.

5. Update Firefox and your operating system

Firefox’s root list ships with the browser and changes over time as CAs add new roots and retire old ones. A copy of Firefox that has not been updated for years carries a stale trust store, so certificates chaining to a newer root fail even though the site is configured correctly. Firefox also needs to be running to sync its preloaded intermediates, which is why a profile that has just been created, or one restored from a backup, can throw this error briefly on sites with incomplete chains.

Install pending updates for Firefox and for the operating system, restart, and try again. If the device cannot be updated any further, its trust store cannot be refreshed either, and it will keep failing on a growing number of sites.

While you are checking, confirm the clock on the device is correct. A badly wrong system time does not produce this error, it produces a date error instead, but the two warning pages look almost identical and it costs nothing to eliminate.

6. Steps that do not fix this error

Several widely repeated suggestions target the wrong system entirely, and one of them is actively harmful:

• Deleting cert9.db. The most harmful item on this list, for the reasons set out earlier: it discards roots and client certificates you imported, and it stops no interception.
• Clearing the cache, cookies or history. Firefox fetches and validates the certificate on every connection. There is no stored verdict to clear.
• Removing extensions. An extension cannot change which certificate a server presents or which roots Firefox trusts.
• Clearing the SSL state in Windows Internet Options. That flushes a cache belonging to Schannel, the Windows TLS stack. Firefox does not use it.
• Importing the site’s own certificate into the Authorities tab. That tab is for Certificate Authorities, and a website certificate is not one. The supported route for a single host is the per-site exception described below.

7. When to stop instead of clicking through

Firefox treats this error as overridable, so the warning page offers Advanced and then Proceed to (hostname) (Risky), a button Firefox renamed when it redesigned this page in version 149 and which older releases and the current Extended Support Release still label Accept the Risk and Continue. On a development server or an appliance on your own network, using it is reasonable, and the exception applies to that host only.

Anywhere else, pause. This is the error Firefox raises when a connection may be intercepted, and accepting it sends your traffic to whoever presented the certificate. If a bank, a mail service or a shop triggers it and you cannot explain the issuer, do not proceed and do not enter credentials. Reach the site over a different network and report the problem to its operator instead.

To remove an exception later, open Settings, then Privacy & Security, scroll to Certificates, click View Certificates, open the Servers tab, select the entry and click Delete.

Frequently Asked Questions

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