What to Do If Your SSL Certificate Is Not Trusted

If your browser shows a warning that the SSL certificate is not trusted, it usually means the browser cannot verify the certificate chain, the certificate does not match the website name, or the certificate has expired, been replaced incorrectly, or is using a weak or incomplete configuration. In a hosting environment, this is often related to certificate installation, domain changes, mixed settings in a control panel such as Plesk, or a missing intermediate certificate.

This article explains how to identify the cause, fix the issue on an EU hosting platform, and confirm that HTTPS works correctly for visitors across Europe and beyond.

Why an SSL certificate may not be trusted

Browsers trust SSL certificates only when several checks pass at the same time. If one part is missing, the connection may still be encrypted, but the browser will warn that it is not trusted.

  • The certificate is expired or not yet valid.
  • The domain name does not match the certificate common name or SAN entries.
  • The certificate chain is incomplete, especially if an intermediate certificate is missing.
  • The certificate was installed on the wrong site or the wrong virtual host.
  • The site is using a self-signed certificate that browsers do not trust publicly.
  • The site is being accessed by IP address instead of the correct domain name.
  • There is a mixed setup after a migration, renewal, or reverse proxy change.
  • The browser, device, or operating system trust store is outdated.

How to identify the exact trust problem

Before changing anything, confirm what kind of certificate issue you are dealing with. This saves time and prevents unnecessary reinstallations.

Check the browser warning text

Different browser messages point to different causes:

  • “Not secure” or “Your connection is not private” often indicates chain, expiration, or hostname problems.
  • “Certificate name invalid” usually means the certificate does not include the domain you are visiting.
  • “Issuer not trusted” often means the intermediate chain is incomplete or the certificate is self-signed.
  • “Certificate expired” means renewal is required.

Inspect the certificate details in the browser

Open the certificate information from the warning page or the padlock area and check:

  • Issued to: the domain should match the website address.
  • Issued by: a publicly trusted certificate authority should appear for public websites.
  • Validity period: confirm the certificate is not expired.
  • Subject Alternative Names: verify all intended hostnames are included, such as www and non-www.

Test the site from another device or network

If the warning appears only on one browser or one device, the issue may be local. If it appears everywhere, the problem is likely on the server or DNS side.

  • Try a different browser.
  • Try a mobile connection and a different network.
  • Check whether the issue affects both www and the root domain.

Step 1: Confirm the certificate is installed for the correct domain

In managed hosting or a control panel, one of the most common causes is a certificate installed on the wrong subscription, domain, or virtual host. This happens after migrations, domain aliases, or changes in site configuration.

Make sure the certificate matches exactly the hostname visitors use:

  • example.com
  • www.example.com
  • Any additional subdomains you want protected, such as shop.example.com or mail.example.com

If your site uses multiple hostnames, the certificate must either cover them all or you must redirect traffic to a single canonical hostname with a certificate that includes it.

Step 2: Verify the certificate chain

Even if the certificate itself is valid, browsers may not trust it if the server does not send the full chain. This is especially common when a certificate is manually installed or when an intermediate certificate was not included during renewal.

In practice, the server should present:

  • The server certificate
  • One or more intermediate certificates
  • The trust path to a root certificate already present in the browser or operating system

What to check in a hosting control panel

If you use Plesk or a similar control panel, open the SSL/TLS settings for the domain and verify that the certificate entry is complete. If the provider issued a combined certificate file, make sure it was imported correctly. Some certificates require a separate CA bundle or intermediate chain file.

If the hosting platform offers automatic installation, reselect the certificate and apply it again to the domain so the correct chain is attached.

Step 3: Check expiration and renewal status

An expired certificate is one of the easiest problems to diagnose, but it can still happen if auto-renewal fails due to validation, DNS changes, suspended services, or billing issues with the certificate provider.

Check the following:

  • Certificate expiration date
  • Last renewal time
  • Whether the domain validation method is still valid
  • Whether DNS records point to the correct hosting service

For Let’s Encrypt and similar automated certificates, renewal can fail if the site is not reachable on the expected validation path, if port 80 is blocked, or if a redirect or rewrite rule interferes with the challenge request.

Common renewal blockers

  • Wrong A or AAAA records
  • Firewall rules blocking HTTP validation
  • Domain temporarily pointed elsewhere
  • Expired hosting subscription or disabled web service
  • Incorrect ownership or permission settings in the panel

Step 4: Confirm DNS points to the correct server

If DNS is still propagating or pointing to an older server, browsers may load the wrong certificate. This is common after migration to a new hosting platform in Europe, where the website may still resolve from some networks to the previous endpoint.

Check the domain’s DNS records and confirm:

  • The A record points to the correct IPv4 address
  • The AAAA record points to the correct IPv6 address, or is removed if unused
  • The www record matches the intended setup
  • No old proxy, CDN, or staging records are still active

If you recently changed DNS, allow for propagation time and retest after the records fully update.

Step 5: Fix hostname mismatch issues

Hostname mismatch means the browser is visiting one name, but the certificate was issued for another. For example, the site may be opened at example.com while the certificate only covers www.example.com.

To resolve this:

  • Install a certificate that includes all required hostnames.
  • Redirect all traffic to one preferred domain.
  • Update application settings, especially if the CMS stores a canonical URL.

This is particularly important after a site migration, when a CMS, e-commerce platform, or reverse proxy still points to the old domain structure.

Step 6: Reinstall the certificate in Plesk or the control panel

If the certificate appears valid but the browser still does not trust it, reinstalling it in the hosting control panel often solves the issue. This refreshes the domain assignment and chain handling.

Typical Plesk-style checks

  • Open the domain’s SSL/TLS settings.
  • Confirm the correct certificate is selected.
  • Verify that the private key belongs to that certificate.
  • Check whether the certificate is assigned to the main domain, subdomain, or both.
  • Enable permanent HTTPS if the site is ready for it.

If the certificate was imported manually, compare the certificate and private key pair. A mismatch can lead to failed SSL activation or an incomplete trust path.

Step 7: Look for mixed content after HTTPS migration

Sometimes the certificate itself is valid, but the browser still marks the site as unsafe because some resources load over HTTP. This is known as mixed content. While the SSL certificate may not be “not trusted” in the strict sense, users often see security warnings that look similar.

Mixed content usually comes from:

  • Images loaded with an http:// URL
  • CSS or JavaScript files called over insecure links
  • Embedded fonts, videos, or widgets using HTTP
  • Old URLs stored in the CMS database

How to correct mixed content

  • Update internal links to use HTTPS.
  • Replace hardcoded HTTP URLs in templates and content.
  • Run a search-and-replace in the database if your CMS stores absolute URLs.
  • Set up an HTTP to HTTPS redirect after the certificate is confirmed working.

After cleanup, clear the browser cache and retest the site on both desktop and mobile.

Step 8: Remove conflicting SSL configurations

On hosted servers, certificate issues can also be caused by duplicate or conflicting virtual host settings. This is common when Apache, Nginx, or a proxy layer is involved.

Check for:

  • Multiple certificates assigned to the same hostname
  • Old certificate files left in the web server configuration
  • Reverse proxy rules sending traffic to a backend with a different certificate
  • Stale configuration after domain rename or migration

If your hosting stack uses both Nginx and Apache, confirm which service terminates TLS and whether the correct certificate is attached at that layer.

Step 9: Consider local trust store issues

Sometimes the certificate is fine and the problem is on the client side. Older operating systems, outdated browsers, and enterprise security software can fail to trust certificates that modern systems accept.

This is more likely when:

  • The warning affects only one machine
  • The site works on modern devices but not on older ones
  • Security software performs HTTPS inspection
  • The device clock is incorrect

Ask the user to:

  • Check the system date and time
  • Update the browser and operating system
  • Temporarily disable SSL inspection in endpoint security tools, if permitted
  • Test from a different device

Step 10: Verify the certificate with external checks

After making changes, confirm the fix with an external SSL check tool or by opening the site in a private browser window. This helps rule out cached data or local overrides.

Good verification points include:

  • Certificate is issued to the correct domain
  • The chain is complete
  • No expiration warning appears
  • HTTPS loads without browser warnings
  • Both www and non-www versions behave as expected

Recommended fix order

If you are not sure where to start, use this order:

  1. Check the exact browser error message.
  2. Confirm the certificate domain and validity date.
  3. Verify DNS points to the right server.
  4. Check the certificate chain and intermediate bundle.
  5. Reassign or reinstall the certificate in the hosting panel.
  6. Check for mixed content and old HTTP links.
  7. Test from another device and network.

Examples of common scenarios

Scenario 1: The site was migrated to a new hosting platform

The certificate warning appears because DNS still points partly to the old server, which presents a different certificate. Update the DNS records, wait for propagation, and ensure the certificate is installed on the new domain configuration.

Scenario 2: The certificate renewed, but browsers still warn

The renewal succeeded, but the hosting panel is still serving the old chain or the wrong certificate file. Reassign the renewed certificate in the panel and restart or reload the web server configuration if needed.

Scenario 3: Only www works, but the root domain does not

The certificate includes www.example.com but not example.com. Issue a certificate that covers both names or redirect the root domain to www and verify the redirect happens after TLS is established.

Scenario 4: The browser reports the issuer is not trusted

The intermediate certificate is missing from the server configuration. Reinstall the full chain from the certificate provider or use the bundled certificate file recommended by your hosting platform.

How to prevent future SSL trust issues

Once the problem is solved, a few preventive steps reduce the chance of it happening again.

  • Enable automatic certificate renewal where available.
  • Keep DNS records documented and reviewed after migrations.
  • Use a single canonical domain for the website.
  • Audit mixed content after theme or plugin changes.
  • Check renewal notifications from the hosting panel or certificate provider.
  • Review SSL configuration after enabling CDN, proxy, or firewall services.

For managed hosting customers, it is also useful to keep a short internal note of the domain’s certificate source, renewal method, and expiration date so support can troubleshoot quickly if the site is affected again.

FAQ

Why does my browser say the SSL certificate is not trusted even though HTTPS is enabled?

HTTPS only means the connection is encrypted. The browser still needs to verify that the certificate is valid, matches the domain, and chains to a trusted authority. If any of these checks fail, the browser may warn that the certificate is not trusted.

Can a certificate be valid but still show a warning?

Yes. A certificate can be within its date range but still fail due to hostname mismatch, missing intermediate certificates, incorrect installation, or local trust-store problems on the visitor’s device.

What is the most common cause in hosting environments?

The most common causes are an incomplete certificate chain, the wrong certificate assigned in the control panel, expired renewal, or a hostname mismatch after a domain change or migration.

Do I need a new certificate if I changed hosting providers?

Not always. If the certificate and private key are still available and the certificate covers the correct domain names, you may be able to reinstall it on the new platform. However, many users simply issue a fresh certificate during migration to avoid chain or key issues.

Why does the warning appear only on one browser?

This may point to cached certificate data, a local trust-store issue, antivirus HTTPS inspection, or an outdated browser. Test the site on another device to determine whether the issue is server-side or local.

What should I do if Let’s Encrypt renewal fails?

Check that DNS is correct, port 80 is reachable for validation, the domain resolves to the current server, and the web root challenge path is accessible. Then trigger renewal again from the hosting panel or control panel.

Conclusion

An SSL certificate that is not trusted is usually the result of a specific configuration problem, not a permanent failure. In most hosting environments, the fix involves confirming the correct hostname, reinstalling the certificate with the full chain, renewing it if needed, checking DNS, and removing mixed content after HTTPS setup.

If you manage a website on a European hosting platform, it is worth reviewing SSL settings after every migration, domain change, or website cleanup task. A careful check in the hosting control panel and a quick browser test are often enough to restore trusted HTTPS access for your visitors.

  • 0 Users Found This Useful
Was this answer helpful?