SSL Certificate Hosting Guide: Installation, Renewal, and Mixed-Content Fixes

Overview

An SSL certificate enables encrypted communication between a visitor’s browser and your website. The encryption itself is provided through TLS, but “SSL” remains the term commonly used in hosting dashboards and website documentation. A certificate also helps a browser verify that the website is serving the domain named in the certificate.

A valid certificate does not automatically mean that HTTPS is correctly configured. Security warnings can still appear when the certificate does not cover the requested hostname, the server sends an incomplete certificate chain, the certificate has expired, or the page loads images, scripts, stylesheets, fonts, or other resources over HTTP. Redirects, DNS changes, reverse proxies, content delivery networks, and application settings can also affect the final result.

Before changing anything, record the current setup:

• Which hostnames need HTTPS, such as the root domain, www, an application subdomain, or an administrative subdomain?
• Where is DNS managed: the registrar, the hosting provider, a CDN, or another DNS platform?
• Where does TLS terminate: the origin server, a load balancer, a reverse proxy, or a CDN?
• Is the certificate managed automatically by the hosting platform or installed manually?
• Are there separate staging, testing, and production environments?

If your domain and hosting are controlled by different providers, use the DNS records and hosting details together. The DNS records guide can help clarify how A, CNAME, AAAA, and validation-related TXT records fit into the setup.

Checklist by scenario

Installing a certificate on a new website

1. Confirm the exact hostnames the website will use. A certificate for one hostname may not cover another unless that hostname is included.
2. Point DNS to the intended hosting endpoint and allow time for the change to become visible across DNS resolvers.
3. Use the hosting panel’s automated certificate option when it is available and appropriate for the environment.
4. If installing manually, obtain the certificate, private key, and required intermediate certificate chain from the certificate provider. Keep the private key restricted and do not place it in public web directories.
5. Install the certificate at the TLS termination point. Installing it only on an origin server will not resolve a certificate problem if a proxy or CDN serves HTTPS to visitors.
6. Test both the root domain and every required subdomain over HTTPS.
7. Configure one canonical HTTPS version and redirect the corresponding HTTP URLs to it.
8. Update application settings, canonical URLs, sitemap URLs, and internal links so they use HTTPS consistently.

Renewing an automatically managed certificate

• Check that the renewal method still has access to the required DNS or HTTP validation path.
• Confirm that the account, hosting plan, proxy, firewall, and DNS configuration have not changed since the last successful renewal.
• Review the certificate’s current expiration date and the provider’s renewal status in the hosting panel.
• Verify that automated renewal notifications reach a monitored mailbox or alerting system.
• Test renewal in a non-production environment when the platform supports it.
• After renewal, inspect the certificate actually served to visitors rather than relying only on the control panel status.

Automated renewal reduces routine work, but it is not a substitute for monitoring. A certificate may fail to renew because a domain changed, a validation record was removed, a server became unreachable, or a proxy altered the validation request.

Installing or renewing a manually managed certificate

• Store the certificate, private key, and chain with appropriate permissions.
• Track the expiration date in a calendar or monitoring system with more than one reminder.
• Install the renewed certificate at every endpoint that serves the hostname.
• Reload or restart the relevant web server, proxy, load balancer, or application gateway according to its documented workflow.
• Remove obsolete certificates only after confirming that no service still depends on them.
• Record who performed the change, which hostnames were affected, and how the result was verified.

Fixing mixed-content errors

Mixed content occurs when an HTTPS page requests a resource over HTTP. Browsers may block active content such as scripts or frames and may warn about or upgrade some other requests. To fix it:

1. Use the browser’s developer tools to identify the exact HTTP URL.
2. Search the application database, templates, theme files, CSS, JavaScript, and configuration for the insecure URL.
3. Change absolute HTTP links to HTTPS or use suitable relative or protocol-independent application logic where appropriate.
4. Check third-party resources, embedded media, fonts, analytics, payment components, and API endpoints.
5. Clear application, page, CDN, and browser caches before testing again.
6. Retest the page in a private browsing window and inspect the browser console for remaining requests.

Do not solve mixed content by blindly redirecting every external resource. Confirm that the external provider supports HTTPS and that the resource remains compatible with your application.

What to double-check

Hostname coverage

Compare the hostname in the browser address bar with the names listed in the certificate. Check the root domain and www separately, as well as subdomains used for applications, APIs, stores, or control panels. A redirect can hide an unsupported hostname during one test while another hostname remains misconfigured.

Certificate chain and server response

The server generally needs to send the certificate together with the appropriate intermediate certificates. If the chain is incomplete, some clients may report trust problems even when the certificate itself has not expired. Validate the complete server response from outside the hosting server and test with more than one client where practical.

HTTP-to-HTTPS redirects

Check that HTTP requests redirect to the intended HTTPS URL, preserve the correct path, and do not create a loop. Review redirects at every layer: web server rules, application settings, reverse proxies, CDN settings, and load balancers. If a proxy terminates TLS before forwarding traffic, confirm that the application understands the original request was HTTPS.

TLS configuration

Use the hosting provider’s maintained TLS defaults where possible, and remove obsolete protocols or algorithms only with a clear compatibility plan. Configuration changes should be tested against the browsers, devices, APIs, and integrations your visitors actually use. Avoid copying a configuration designed for a different server, operating system, or proxy.

Command-line verification

For technical teams, command-line checks can supplement browser testing. For example, this command requests the HTTPS headers and follows redirects:

curl -I -L https://example.com

To inspect the certificate and chain presented by a server, a team may use a TLS client such as:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Replace the example hostname and interpret the output in the context of your server and certificate setup. These commands do not replace application testing: they will not reveal every insecure URL embedded in page content.

Common mistakes

• Installing the certificate on the wrong layer: A CDN or load balancer may be the public TLS endpoint, even when the website files live on a separate server.
• Forgetting alternate hostnames: The root domain, www, and subdomains can have different DNS and certificate requirements.
• Relying on the padlock alone: A browser indicator does not confirm that every application route, API call, redirect, or asset is configured as intended.
• Removing validation records too early: DNS-based validation may require a record to remain available for future renewals, depending on the certificate workflow.
• Testing only from inside the server network: Internal DNS or proxy behavior can differ from what public visitors receive.
• Changing several layers at once: Record DNS, certificate, proxy, redirect, and application changes separately so failures are easier to isolate.
• Ignoring expiry alerts: An alert that goes to an unattended address is not an operational control. Route it to a monitored mailbox or incident system.

For broader protection, pair certificate management with backups, access controls, software updates, and server hardening. The website hosting security checklist covers those complementary controls. If HTTPS is being configured during a move, use the cloud hosting migration checklist to include DNS and rollback checks in the same change plan.

When to revisit

Review this checklist before a certificate’s expected renewal window, before changing hosting or DNS providers, after adding a hostname, and whenever a CDN, proxy, load balancer, or web server is replaced. Revisit it after a domain migration, major application release, redirect change, or browser-reported security warning.

As a practical maintenance routine, schedule a periodic HTTPS check that confirms certificate expiry, hostname coverage, redirect behavior, chain delivery, and the absence of mixed-content requests on key pages. Also review the renewal contact details and validation records before seasonal planning cycles or other periods when your team has limited change capacity.

Before closing an SSL change, complete this short sign-off:

1. List every public hostname and confirm its DNS destination.
2. Inspect the certificate served from each hostname, including its expiration and name coverage.
3. Test HTTP redirects, HTTPS pages, important forms, APIs, and third-party integrations.
4. Check browser developer tools for mixed content and blocked resources.
5. Confirm automated renewal or document the manual renewal owner and reminders.
6. Record the result, configuration location, rollback step, and date for the next review.

Keeping this record current turns HTTPS from a one-time installation task into a manageable reliability control. For related domain ownership and renewal checks, see the domain renewal and expiration checklist.