TLS certificate problems

Fix common TLS/SSL certificate issues on TurboStack - certificates that won't issue, renewal failures, and browser security warnings.

TurboStack issues and renews Let's Encrypt certificates automatically, so most HTTPS problems are caused by Domain Name System (DNS) issues or by how the site links to its own resources. This page covers the common cases - a certificate that never issues, a renewal that fails, and browser warnings - and how to fix each one safely.

Symptoms

  • The site loads over http:// but https:// fails to connect or shows no certificate.
  • The browser shows a padlock warning, "Not secure", or "Your connection is not private".
  • A previously working certificate has expired or stopped renewing.
  • The page is HTTPS but elements (images, scripts) fail to load with mixed-content warnings.

Diagnose it on TurboStack

  1. Check the certificate status. Open the host's Applications tab and review the application's Hostnames / Transport Layer Security (TLS) settings - confirm cert_type is letsencrypt and that every hostname the site answers to is listed in server_name. See TLS certificates.

  2. Check DNS. A certificate cannot be issued until the domain resolves to the host. Confirm the A/AAAA records point at the server's public IPs - see Connecting your domain.

  3. Check what the browser reports. Click the padlock to see the certificate's domains and expiry date. The error message usually names the exact problem (wrong domain, expired, self-signed).

  4. Check recent changes. If HTTPS broke after a change, review the host's History to see whether a recent publish changed server_name, cert_type, or cert_challenge.

Common causes and fixes

Certificate not issued - DNS isn't pointing at the host yet

This is the most common cause. With the default HTTP challenge, Let's Encrypt validates ownership by connecting to your domain over HTTP and expecting to reach this server. If the domain doesn't resolve to the host - or still points at an old server - validation fails and no certificate is issued.

Fix:

  1. Point the domain at the host's public IPv4 (and IPv6) addresses, then wait for DNS to propagate - see Connecting your domain.

  2. Make sure every name in server_name resolves to the host, including www.

  3. Publish again so TurboStack re-requests the certificate.

Renewal failed

Renewal is automatic, but it can still fail if the conditions that allowed issuance have since changed. Common examples: DNS was repointed elsewhere, a hostname was added to server_name that does not resolve, or a redirect now blocks the Let's Encrypt validation path.

Fix:

  1. Confirm DNS for every hostname still points at this host.

  2. Make sure plain HTTP on the validation path is reachable. A blanket force-HTTPS redirect is fine on TurboStack, because the platform handles the ACME challenge. However, a custom redirect or rule that returns errors for all HTTP requests can block validation.

  3. Re-trigger by publishing the host; TurboStack will attempt issuance again.

If renewal keeps failing after DNS and reachability are confirmed, contact support.

Browser warning: wrong or missing domain

If you reach the site by a hostname that is not listed on the certificate, the browser reports a name mismatch. This happens with a bare subdomain, or www when only the apex domain was added.

Fix: add every hostname the site serves to server_name (space-separated) so they're all covered by one certificate, then publish. See TLS certificates.

Browser warning: certificate expired

A managed Let's Encrypt certificate should never expire on its own. If a browser reports an expired certificate, it usually means renewal has been failing for some time (see Renewal failed above) or the browser cached an old certificate. Reload after fixing renewal; if it persists, publish to force a fresh issuance.

Browser warning: not trusted / self-signed

A "not trusted" warning where you expected a public certificate usually means the application is still set to cert_type: selfsigned (intended for internal or test sites). Switch it to letsencrypt and publish - see TLS certificates.

Mixed content - padlock shows a warning

The page itself is served over HTTPS, but it links to some resources (images, CSS, scripts) using hard-coded http:// URLs. Browsers block or flag this insecure content.

Fix: update the application so it generates HTTPS (or protocol-relative) URLs. In most CMS and e-commerce apps this means setting the site's base/secure URL to https://. Use the browser's developer console to find which resources are still requested over HTTP.

HTTPS works but HTTP isn't redirected

If both http:// and https:// serve the site, force all traffic onto HTTPS so visitors always get the secure version - see How to force HTTPS. On TurboStack this is the recommended setup; the platform still allows Let's Encrypt's validation requests through.

Prevent it

  • Point DNS at the host before requesting a certificate, and keep records current when you migrate (Connecting your domain).

  • Keep cert_type: letsencrypt and list every hostname in server_name.

  • Force HTTPS site-wide and fix mixed content at the source (Force HTTPS).

  • Follow the Security hardening checklist for TLS best practices.

When to contact support

If DNS resolves correctly, the HTTP validation path is reachable, and a certificate still won't issue or renew, contact support. Include the host, the affected domain(s), the exact browser error, and what changed recently (DNS move, new hostname, redirect rule).

© 2026 Hosted Power — TurboStack