Have you ever shared a link on Facebook or Twitter only to see a blank box where the preview image should be? It’s frustrating — especially when you’ve spent time designing the perfect Open Graph image. The culprit often isn’t your image at all, but your SSL certificate.
The problem with your website’s SSL certificate stemmed from an incomplete certificate chain. While your domain certificate was issued and active, browsers and tools like GTmetrix or Facebook’s Open Graph Debugger reported that the SSL certificate was not trusted, even though all pages returned a 200 status.
The Hidden Problem: Incomplete SSL Chains
In this case, the website’s SSL certificate looked fine at first glance. The domain certificate was active, and every page returned a 200 status. Yet browsers and tools like GTmetrix or Facebook’s Open Graph Debugger flagged the certificate as untrusted.
Why? Because the server was only presenting the domain certificate, not the full chain of trust. Browsers need the intermediate certificates that connect a domain certificate to a recognized root authority. Without them, the chain is broken — and social platforms refuse to load images.
This happens when the server presents only the domain certificate but does not provide the intermediate certificates that link it to a trusted root authority. Browsers rely on the full chain to verify authenticity, so missing intermediates trigger trust errors.
You were using a free SSL Starter Wildcard certificate powered by Sectigo, which comes with a domain certificate and a ZIP file containing two intermediate certificates. Your domain certificate file had the extension .cer, which is a standard format for certificates. Each intermediate certificate has a specific role: the immediate intermediate (3072-bit) issued your domain certificate, and the root certificate (4096-bit) is the top-level certificate recognized by browsers. Plesk requires the domain certificate (.cer), its corresponding private key, and the CA bundle (concatenated intermediates) to serve the full chain. Initially, the intermediate certificates were either not uploaded or misordered, leading to chain issues.
The Setup: Free SSL Starter Wildcard
The site was using a free SSL Starter Wildcard certificate from Sectigo. This included:
- A domain certificate (.cer file)
- Two intermediate certificates in a ZIP file
Each certificate plays a role:
- The immediate intermediate (3072‑bit) issues the domain certificate
- The root certificate (4096‑bit) is the top‑level authority trusted by browsers
Plesk requires all three elements — the domain certificate, its private key, and a CA bundle (the intermediates combined in the right order).
The Fix: Building the Full Chain
- Identifying the correct intermediate certificates and noting their bit sizes.
- Combining them in the proper order — immediate intermediate first, root second — to create a CA bundle.
- Uploading the domain certificate (.cer), private key, and CA bundle in Plesk.
- Assigning the certificate to the domain in Hosting Settings and enabling SSL/TLS support.
- Restarting web services to apply the changes.
- going to Facebook’s debugger to confirm its working:https://developers.facebook.com/
Once the full chain was uploaded correctly, browsers recognised the certificate as trusted, GTmetrix no longer reported SSL errors, and Open Graph images on Facebook loaded properly. The issue was not with the domain certificate itself, but with the missing or misordered intermediate certificates, which are essential for SSL chain validation.
The Result: Trusted Certificates, Working Previews
With the full chain in place, browsers immediately recognised the certificate as trusted. GTmetrix stopped reporting SSL errors, and Facebook began displaying Open Graph images correctly.
The lesson is clear: when link previews fail, the issue isn’t always your images or meta tags. Sometimes, it’s the unseen SSL chain that makes or breaks trust.
If you have any further issues, please do reach out to us. We maybe able to give some pointers that may help.
Leave a Comment