Troubleshooting areaReviewed 2026-08-13By HostWithShery technical editorial

SSL & HTTPS

Check certificates, expiry, hostname coverage, TLS behavior and mixed-content problems.

Start with evidence from your own domain before changing DNS, SSL or mail settings.
Check your own configuration

SSL Certificate Checker

This page is preconfigured with the SSL Certificate Checker that best matches this problem.

No accountPublic evidence only
Live public check
No account · Public configuration only
On this page
Browse this section

Choose the focused diagnostic

Every important page in this area is linked here with a normal crawlable link, so you can choose by task instead of searching through a long generic list.

SSL & HTTPS: what this section covers

SSL & HTTPS focuses on the TLS handshake that occurs before a browser can receive an application response or redirect. It checks certificate dates, SAN hostname coverage, root/www differences, supported TLS behavior, HSTS and insecure resource references that can remain after a certificate itself is valid.

Signals that matter for SSL and HTTPS

The pages here interpret TLS, certificate and HTTPS evidence through the following search tasks and configuration concepts. They are included because they help separate causes, not to repeat a keyword a fixed number of times.

  • Ssl toolsTest the hostname actually requested, its certificate dates and SAN coverage, and the TLS handshake. Root and www can serve different certificates.
  • Https checkerRecord the public status, final URL and relevant response headers. A working DNS answer does not prove that the application is serving a genuine website response.
  • Certificate troubleshootingTest the hostname actually requested, its certificate dates and SAN coverage, and the TLS handshake. Root and www can serve different certificates.

Which SSL & HTTPS check to start with

Use Certificate Checker for identity/chain/hostname problems, Expiry Checker for renewal monitoring, and Mixed-Content Checker when the page loads over HTTPS but the browser still warns about insecure subresources. If HTTP works and HTTPS does not, test TLS before changing DNS.

Diagnosis first, raw evidence second

The interface surfaces the highest-impact explanation and its confidence before raw protocol output. For SSL and HTTPS, that means a visitor can see what probably failed and what to change while an advanced user can still inspect the DNS, certificate, header, resolver or provider evidence behind the conclusion.

What a repaired SSL and HTTPS problem should look like

Verify the exact failing hostname. A certificate for example.com does not automatically cover www.example.com, and a redirect from www cannot happen safely until www itself completes TLS. Repair certificate/service binding first, then enforce canonical HTTPS redirects.

Validate the TLS, certificate and HTTPS change

HTTPS should complete for the exact hostname, the certificate should be valid for that hostname, and root/www should follow the intended canonical redirect without a TLS error. Re-run the same focused tool that exposed the problem so a dashboard status, cache or unrelated healthy signal is not mistaken for proof of the repair.

Technical references

These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.