An SSL certificate enables encrypted HTTPS connections between a visitor’s browser and your website. This guide explains SSL certificate types, shows how to install and verify one, and provides practical checklists for renewal failures, mixed content, certificate mismatches, and other HTTPS errors.
Overview
Although people commonly say “SSL certificate,” modern websites generally use TLS, the successor to SSL. The certificate is the part that helps a browser verify a website’s domain and establish an encrypted connection. When installation is complete, visitors should be able to open the site over https:// without a browser security warning.
An SSL certificate does not replace secure application code, strong account authentication, backups, or careful server configuration. It protects data while it travels between the browser and the web server, but it cannot fix a compromised website or an insecure form handler. Treat HTTPS as one layer in a broader website security and performance plan.
SSL certificate types at a glance
| Type | What it validates | When to consider it |
|---|---|---|
| DV | Control of the domain | Most personal sites, blogs, documentation sites, and standard business websites |
| OV | Domain control and organization details | Organizations that want additional identity information associated with the certificate |
| EV | More extensive organization validation | Use only when the organization has a specific reason to meet the certificate authority’s validation requirements |
| Wildcard | A domain and eligible subdomains, depending on certificate scope | Sites that operate several subdomains and want one certificate to cover them |
For many websites, a domain-validated certificate is sufficient. The right choice depends on the domains and subdomains you operate, your hosting platform, your organization’s requirements, and how certificates will be renewed. Do not select a certificate solely because it sounds more advanced; first list the hostnames it must cover.
If you are setting up a new site, the SSL step belongs after the domain points to the correct hosting environment and before you force all traffic to HTTPS. For the wider sequence, see the website launch checklist and domain and hosting setup guide.
Checklist by scenario
When choosing a certificate
- List every hostname that needs HTTPS, including the main domain, the
wwwversion, and active subdomains. - Decide whether one certificate should cover multiple names or whether separate certificates are easier to manage.
- Confirm that the certificate type is supported by your hosting provider, control panel, reverse proxy, or CDN.
- Check who controls renewal: your host, a certificate management system, a CDN, or your technical team.
- Record the certificate’s covered names, renewal method, account owner, and expiry date in your operational documentation.
How to install an SSL certificate
- Point the domain correctly. Confirm that DNS records direct the hostname to the intended server or proxy. An SSL certificate cannot make an incorrectly routed domain reach the right site. The guide to DNS records explains the role of A, CNAME, and related records.
- Complete validation. The certificate provider may ask you to prove control of the domain through DNS, an uploaded file, or another supported method. Follow the provider’s exact instructions and avoid deleting a validation record until issuance is complete.
- Install the certificate and private key. Use your hosting panel or server configuration as directed by the provider. Protect the private key; it should not be posted in a public repository, sent through an unprotected channel, or reused without a clear reason.
- Install the intermediate certificate chain. If your provider supplies a chain or bundle, use the format required by your server. A missing chain can cause some browsers or devices to reject an otherwise valid certificate.
- Test both domain variants. Open the main hostname and any required alternate hostname over HTTPS. Check the certificate’s subject or covered names, validity period, and issuing authority.
- Redirect HTTP to HTTPS. After confirming HTTPS works, configure a permanent redirect from the HTTP version. Review application settings so canonical URLs, sitemap URLs, and internal links use HTTPS.
- Check the whole site. Test forms, login pages, APIs, images, scripts, stylesheets, downloads, webhooks, and third-party integrations. A homepage test alone is not enough.
When renewing a certificate
- Confirm the renewal process is enabled and that its account or automation token still works.
- Verify that DNS validation records remain available if automated renewal depends on them.
- Check that the new certificate includes every hostname covered by the previous one.
- Renew or deploy the certificate on every relevant server, load balancer, CDN, or staging-to-production path.
- Test the live endpoint after renewal and remove obsolete certificates only after the replacement is confirmed.
- Keep an alert or calendar reminder well before expiry rather than relying on a single notification.
When a website is moved
During a hosting migration, install and test the certificate on the new environment before changing all production traffic. Check DNS, firewall rules, proxy settings, application base URLs, and redirects together. A migration can expose a certificate that was previously managed automatically by the old host. Use the website migration checklist to coordinate the domain, DNS, hosting, and application steps.
What to double-check
Certificate names and coverage
A certificate mismatch occurs when the hostname in the browser address bar is not included in the certificate. Common examples include covering example.com but not www.example.com, or covering the main domain but not a newly created subdomain. Check the exact hostname, including spelling and subdomain level. A wildcard certificate also has a defined scope; it does not automatically cover every deeper subdomain.
Mixed content
A mixed content error appears when an HTTPS page requests a resource over HTTP. Images, JavaScript, CSS, fonts, embedded media, API calls, and tracking integrations can all be responsible. Use the browser’s developer tools to identify the blocked URL, then update the resource to HTTPS, replace an outdated integration, or remove it. Search your database and templates for hard-coded HTTP URLs, and check content stored in a CMS.
Redirects and canonical URLs
Confirm that HTTP redirects to the intended HTTPS URL without a loop. Review redirects at every layer: the web server, application, hosting panel, CDN, and proxy. Also update canonical tags, internal links, XML sitemaps, advertising destinations, and external service callbacks where appropriate. Redirecting the homepage while leaving assets or application endpoints on HTTP creates an incomplete migration.
Renewal and deployment
Certificate renewal has two separate stages: obtaining a replacement certificate and deploying it where visitors connect. Automation can succeed at the first stage while the old certificate remains active on a load balancer, CDN, or secondary server. Identify the public endpoint and inspect the certificate it actually serves. If several servers answer for one domain, check each path.
Common mistakes
- Forcing HTTPS too early: Enabling redirects before the certificate is installed and tested can make the site inaccessible or create a redirect loop.
- Ignoring DNS propagation: A newly changed record may not produce the same result everywhere immediately. Test from more than one network or resolver when troubleshooting.
- Installing only the leaf certificate: Some environments require the intermediate chain as well. Follow the server’s required certificate bundle format.
- Forgetting non-browser clients: Mobile apps, API consumers, monitoring systems, payment integrations, and webhooks may validate HTTPS differently from a normal browser.
- Leaving old HTTP URLs in a CMS: Updating the site address does not always rewrite image URLs, embedded media, or stored content.
- Relying on expiry notifications alone: Notifications can go to an inactive mailbox or fail when ownership changes. Assign a responsible owner and document the renewal path.
- Assuming a certificate fixes all security issues: HTTPS protects the connection in transit, but it does not replace software updates, access controls, backups, or application security testing.
For a focused diagnosis, start with the browser error and classify it: expired certificate, hostname mismatch, untrusted issuer, incomplete chain, protocol problem, mixed content, or redirect loop. Then inspect the public endpoint, DNS response, server configuration, and application-generated URLs in that order. This prevents changing several layers at once and losing the original cause.
When to revisit
Revisit this checklist before a certificate expires, whenever a domain or subdomain is added, and before moving a site to new web hosting, cloud hosting, a CDN, or a reverse proxy. It is also useful before seasonal planning cycles when traffic, campaigns, integrations, or support coverage may change.
Review the process after changing DNS providers, hosting control panels, certificate authorities, deployment pipelines, or account ownership. Workflows and browser behavior can change, so confirm that your documented commands and screenshots still match the tools your team uses. Recheck renewal alerts at least periodically, and run a live HTTPS test after significant infrastructure changes.
Final action list: inventory hostnames, confirm DNS, identify the certificate owner, record the renewal method, test issuance in a safe environment, deploy to every public endpoint, verify the certificate and chain, fix mixed content, enable HTTPS redirects, and document the result. Keeping this short record current makes the next renewal or website migration much less disruptive.
