SSL certificate problems can appear as browser warnings, failed renewals, mixed-content notices, or a certificate hostname mismatch. This guide gives you a repeatable way to diagnose HTTPS issues, verify fixes, and monitor certificates before they disrupt visitors, logins, payments, or email-related services.
Overview
An SSL certificate enables a browser to establish an encrypted HTTPS connection with your website. In current terminology, the underlying protocol is TLS, but “SSL certificate” remains the familiar phrase used in hosting panels and troubleshooting searches.
Most certificate incidents fall into a small number of categories:
- Expired certificate: The certificate is past its validity period.
- Hostname mismatch: The certificate does not cover the domain or subdomain being visited.
- Untrusted certificate: The browser cannot establish a trusted chain, or the certificate was issued by an authority it does not recognize.
- Failed validation or renewal: An automated certificate process cannot confirm control of the domain.
- Mixed content: The main page loads over HTTPS but requests images, scripts, stylesheets, fonts, or other resources over HTTP.
- Incorrect server configuration: The certificate exists, but the web server presents the wrong certificate, omits an intermediate certificate, or does not redirect HTTP traffic as intended.
Start with the exact browser message and the exact URL where it appears. Test the bare domain, the www version, and important subdomains separately. A certificate can be valid for one hostname while failing for another.
If you recently changed nameservers, hosting, or DNS records, first confirm which server answers for the domain. A certificate installed on the new host will not help if DNS still sends visitors to the old host. The DNS propagation checker guide can help you compare responses from different locations.
What to track
1. The certificate’s coverage and validity
Record the certificate’s expiration date, the hostnames it covers, and the server or hosting account where it is installed. Check every public HTTPS hostname, including subdomains used for applications, customer portals, staging previews, or APIs. Do not assume that securing example.com automatically secures www.example.com or app.example.com.
A hostname mismatch usually means one of three things: the requested hostname was omitted from the certificate, DNS points to a different server, or the server is presenting a default certificate instead of the intended one.
2. Renewal configuration
Identify who issues and renews the certificate: a hosting control panel, a reverse proxy, a web server automation tool, a managed WordPress host, or another ACME-compatible client. Then record whether renewal is automatic, where validation logs are stored, and which account or process performs the renewal.
For automated renewal, track the validation method. HTTP-based validation generally requires the validation path to be reachable on the expected hostname. DNS-based validation requires the automation to create or update a specific DNS record. A recent DNS change, restrictive firewall rule, redirect, proxy setting, or permission change can interrupt either method.
3. HTTPS behavior after installation
Track whether HTTP redirects to HTTPS, whether HTTPS works for every required hostname, and whether the application generates secure links. A certificate warning and a mixed-content error are different problems: the first concerns the connection’s certificate or trust chain, while the second concerns insecure resources embedded in an otherwise secure page.
For mixed content, inspect the browser’s developer console to identify the blocked resource. Update hard-coded http:// URLs in templates, content, scripts, stylesheets, database fields, and third-party integrations. Confirm that the resource’s own hostname supports HTTPS before changing the URL.
4. Operational signals
Keep a small certificate inventory with the hostname, expiration date, renewal owner, validation method, hosting environment, and last successful renewal test. A simple external HTTPS check can also alert you when a certificate is near expiration, changes unexpectedly, or becomes unavailable. Monitoring should supplement, not replace, a tested renewal process.
Cadence and checkpoints
Use a monthly or quarterly review for ordinary sites, with additional checks before planned hosting, DNS, or domain changes. The goal is to find configuration drift while there is still time to correct it.
Monthly check
- Open the main domain and key subdomains in a current browser.
- Confirm that the address uses HTTPS and that no certificate warning appears.
- Check the certificate’s expiration date and hostname coverage.
- Review monitoring alerts, renewal logs, and recent hosting changes.
- Test a representative page that includes forms, images, scripts, and embedded services.
Quarterly renewal test
Run the hosting provider’s documented renewal test or a dry run supported by your certificate automation. A test should confirm that the system can complete validation and install the resulting certificate without modifying production behavior unexpectedly. Do not rely only on the certificate’s current validity: a certificate may be valid today even though the next automated renewal will fail.
Before DNS or hosting changes
Lowering DNS time-to-live values may help plan a migration, but it does not transfer a certificate between servers. Before switching traffic, install and test the certificate on the destination host, verify every required hostname, and confirm that the application works over HTTPS. Keep the old environment available until DNS responses and HTTPS checks are stable.
For a broader migration review, use the website launch and migration checklist. If you are only changing where the domain points, review how to point a domain to hosting and check both DNS and certificate behavior afterward.
How to interpret changes
Use the browser error as a starting point rather than repeatedly reinstalling the certificate. This decision path helps narrow the cause:
- Expired: Check the renewal job, its logs, account permissions, validation records, and the system time on the relevant server. Renew the certificate, then confirm the new certificate is actually being served.
- Hostname mismatch: Compare the URL with the certificate’s listed names. Check whether the hostname points to the intended server and whether that server has the correct virtual-host or site binding.
- Not trusted or incomplete chain: Confirm that the server presents the certificate chain required by clients. Review the hosting provider’s installation instructions and test from more than one browser or network.
- Renewal validation failed: Check DNS records, HTTP challenge paths, firewall rules, redirects, proxies, and permissions. A successful website load does not prove that an automated validation request can reach the required location.
- Mixed content: Find the specific HTTP resource in the browser console, change it to a secure URL where supported, and retest pages that use cached or dynamically generated content.
After each correction, clear relevant caches or use a private browser session, then test from an independent network. Also verify that the server responds correctly over IPv4 and IPv6 if both DNS record types are published; different address paths can lead visitors to different configurations.
Document the before-and-after result. Useful evidence includes the tested URL, timestamp, certificate expiration date, hostname coverage, renewal log result, and whether HTTP redirects correctly. This record makes recurring SSL certificate troubleshooting faster and helps distinguish a local browser cache issue from a server-side failure.
When to revisit
Revisit this guide at least monthly or quarterly, depending on the importance and complexity of the site. Return immediately after changing a domain registrar, nameservers, DNS records, hosting provider, reverse proxy, firewall, web server configuration, WordPress security plugin, or automated deployment process. These changes can affect certificate validation or which server presents the certificate.
Set a reminder well before each certificate expiration date, even when renewal is automated. Use that checkpoint to confirm the renewal method still has access to DNS or the web root, the required hostnames remain in service, and the renewed certificate is installed on every relevant endpoint.
For a practical final pass, complete this short checklist:
- Test the bare domain,
www, and active subdomains. - Confirm certificate validity, hostname coverage, and trust.
- Review the latest renewal attempt and perform a renewal test when supported.
- Check for mixed content on important pages.
- Verify DNS answers and hosting endpoints after infrastructure changes.
- Record the result and assign an owner for the next review.
If the problem remains after these checks, preserve the exact browser error, hostname, DNS response, certificate details, server logs, and recent configuration changes before contacting your hosting or certificate provider. Clear evidence usually shortens the path to a safe fix.
