Host My AI App

HTTPS and SSL certificates explained for non-developers

What HTTPS actually protects, what a certificate is and how it gets issued, why certificate lifetimes are shrinking from 398 days to 47 by 2029, and how to fix the usual causes of “Not secure” warnings on your app.

Floot ·

Key Takeaways

  • HTTPS does three jobs. It encrypts traffic so others on the network can’t read it, detects tampering, and proves the visitor reached the real domain. The certificate is what makes the third job possible.
  • Most apps don’t need to buy a certificate. Hosting platforms issue free domain-validated certificates automatically, often from Let’s Encrypt, once your DNS points at them.
  • Certificate lifetimes are getting much shorter. Industry rules cut the maximum from 398 days to 200 days in March 2026, then 100 days in March 2027 and 47 days in March 2029. Manual renewal stops being practical; automation is the answer.
  • Browsers are moving to HTTPS by default. Google planned to turn on Chrome’s “Always Use Secure Connections” setting for public sites by default with Chrome 154 in October 2026, which warns before loading sites without HTTPS.
  • Most warnings have boring causes. DNS not pointing at the host yet, a missing www version, a CAA record blocking issuance, or mixed content loaded over plain HTTP.

Quick-Start Prioritization Framework

What you seeLikely causeFirst thing to try
“Your connection is not private” on a new domainCertificate not issued yet, usually because DNS isn’t correctCheck DNS records with a lookup tool, then wait for the host to issue
Works on example.com, warning on www.example.comCertificate only covers one nameAdd both names to your host and redirect one to the other
Padlock missing or “Not secure” on some pagesMixed content: something loaded over http://Open the browser console and fix the http:// links
Certificate expiredAutomatic renewal failedCheck DNS still points at the host and nothing blocks validation
Endless redirect loop after adding a proxyProxy and host disagree about HTTPSSet the proxy to full, validated HTTPS to the origin

The padlock in the address bar is easy to take for granted until it disappears and your app shows a full-page warning instead. For anyone who has just put an app online, HTTPS raises practical questions: do I need to buy a certificate, why does my custom domain say “not secure” for the first hour, what is Let’s Encrypt, and why does everyone keep saying certificates will soon last only 47 days? This guide answers those in plain language. It covers what HTTPS does, how certificates are issued and renewed, the industry changes happening right now, and the handful of problems that cause nearly every certificate warning on small apps.

What HTTPS actually does

HTTP is the language browsers and servers use to exchange pages. HTTPS is the same language sent through an encrypted connection, using a protocol called TLS. (SSL is the older name for TLS’s predecessor; people still say “SSL certificate” out of habit, and it means the same thing.)

Privacy

Without HTTPS, anyone on the same network as your user, such as a café’s Wi-Fi or a compromised router, can read what is sent: passwords, session cookies, form contents. With HTTPS, they see only which domain is being visited and roughly how much data moves.

Integrity

Encryption also detects changes in transit. Without it, anything between your server and the visitor, such as a hostile Wi-Fi hotspot, can rewrite pages in transit, for example to add its own scripts or swap a download link.

Authentication

The certificate proves that the server answering for yourapp.com is authorized to do so. Without that proof, encryption alone could be a secure connection to the wrong server.

What a certificate is

A certificate is a small signed document that says “this public key belongs to yourapp.com” and is valid until a certain date. It is signed by a certificate authority (CA) that browsers already trust. When a visitor connects, the server presents its certificate, the browser checks the signature, the name and the dates, and only then shows the padlock.

Domain validation is what almost everyone uses

A domain-validated certificate proves control of the domain and nothing more. That is all a web app needs, and it is what hosting platforms issue automatically. Organization-validated and extended-validation certificates also check a company’s identity, cost money, and today show the same padlock in mainstream browsers, so most apps have no reason to buy one.

Names covered

Each certificate lists the names it covers. example.com and www.example.com are different names, and app.example.com is another. A wildcard certificate (*.example.com) covers one level of subdomains but not the bare domain. Your host handles this when you add each domain you want to use.

How a certificate gets issued

Let’s Encrypt, a nonprofit certificate authority, made free automated certificates standard. Most hosting platforms use it or a similar CA, through a protocol called ACME.

Proving you control the domain

Let’s Encrypt explains that the CA issues a challenge, such as placing a file at a specific address on the website (HTTP challenge) or adding a specific DNS record (DNS challenge). The CA checks the result from multiple network locations. If it passes, the requester is authorized to get certificates for that domain.

Why your new domain shows a warning for a while

Your host can only pass the HTTP challenge once your domain’s DNS points at it. Until the DNS change reaches the CA, issuance fails and visitors see a warning. That is why the order is always: add the domain on the host, add the DNS records, wait for the host to show the certificate as issued.

Every certificate is public

Let’s Encrypt submits each certificate to public Certificate Transparency logs. Anyone can search them, which is useful for spotting certificates you didn’t request, and a reason not to put secret project names in subdomains.

Certificates are getting shorter-lived

In 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules, voted to shrink the maximum validity of public TLS certificates in steps. Shorter lifetimes limit how long a stolen or wrongly issued certificate can be misused.

Certificates issuedMaximum validity
Before 15 March 2026398 days
15 March 2026 to 14 March 2027200 days
15 March 2027 to 14 March 2029100 days
From 15 March 202947 days

What Let’s Encrypt is doing

Let’s Encrypt currently issues 90-day certificates. It has announced that its default profile moves to 64-day certificates on 10 February 2027 and to 45-day certificates on 16 February 2028, with an opt-in 45-day profile available since 13 May 2026.

What it means for you

If your host issues and renews certificates automatically, nothing. If you bought a certificate and install it by hand each year, that routine is ending: you would be doing it several times a year by 2027. Let’s Encrypt recommends against manual renewal and suggests clients renew about two-thirds of the way through a certificate’s lifetime.

Browsers are moving to HTTPS by default

Google announced that Chrome would enable the “Always Use Secure Connections” setting by default for public sites with Chrome 154 in October 2026. With it on, Chrome tries HTTPS first and asks the user before loading a public site that doesn’t support it.

Plain HTTP is no longer an option for a real app

Between this change and features browsers only allow on secure pages (such as many device and payment APIs), an app without HTTPS will look broken to many users. Every mainstream host supports HTTPS, so the only work is making sure it is on for every name you use.

HSTS: telling browsers to never use HTTP

A site can send a Strict-Transport-Security header telling browsers to use only HTTPS for it for a set time, for example max-age=31536000 for one year. MDN notes two cautions: with HSTS on, users can’t click through certificate errors, and long max-age values can make the policy effectively permanent. Turn it on once HTTPS is reliable on all your names, starting with a short max-age.

The problems that cause most certificate warnings

When a small app shows a security warning, the cause is almost always one of these.

DNS not pointing at the host

The host can’t validate the domain, so it can’t issue a certificate. Check the A or CNAME record against the values your host shows, and remove old records for the same name.

Only one of www and bare domain added

Visitors who type the other version hit a name the certificate doesn’t cover. Add both on your host and redirect one to the other.

A CAA record blocking your host’s CA

A CAA DNS record lists which certificate authorities may issue for your domain. If it names a CA your host doesn’t use, issuance and renewal fail. Add your host’s CA or remove the record.

Mixed content

The page is HTTPS but loads something over http://. MDN explains that browsers upgrade some of these requests automatically (images, audio, video) and block others outright, including scripts, stylesheets, iframes and fetch requests. The result is a missing padlock or a broken feature. The browser console names each offending URL; change them to https:// or relative paths.

A proxy that doesn’t encrypt to the origin

If you put Cloudflare or another proxy in front of your host, check its mode. Cloudflare’s Flexible mode encrypts visitor-to-Cloudflare traffic but sends Cloudflare-to-origin traffic unencrypted; Cloudflare recommends Full or Full (strict) where possible. Mismatched settings between proxy and host are also a common cause of redirect loops.

How to check a certificate yourself

You don’t need tools beyond your browser for most checks.

In the browser

Click the icon left of the address, then the connection or certificate details. Check three things: the names it covers include the one you typed, the expiry date is in the future, and the issuer is a CA you expect (such as Let’s Encrypt or your host’s CA).

Check every name and a phone

Open https:// and http:// versions of both the bare domain and www, and confirm they all end up on one HTTPS address with no warning. Then try on a phone over mobile data, which uses a different DNS resolver than your home Wi-Fi.

Common mistakes

A few habits cause most of the trouble with certificates on small apps.

Buying a certificate you don’t need

If your host issues free certificates automatically, a purchased one adds a manual renewal job and no visible benefit.

Changing DNS records after launch without checking renewals

Moving DNS to a new provider or adding a proxy can break the validation your host uses to renew. Recheck the certificate status after any DNS change.

Hard-coding http:// links

Images, scripts and API URLs written with http:// cause mixed content. Use https:// or relative URLs everywhere.

Turning on HSTS preload too early

Preloading needs a max-age of at least one year and includeSubDomains, and it is hard to undo. Make sure every subdomain, including ones you might add later, can serve HTTPS first.

If you’d rather not do this yourself

If you’d rather not manage hosting details like these, Floot publishes apps for free on every plan at a floot.app address, and paid plans let you connect your own custom domain.

Frequently Asked Questions

Do I need to buy an SSL certificate for my app?

Usually not. Most hosting platforms issue free domain-validated certificates automatically and renew them. Paid certificates mainly add organization identity checks that don’t change what users see in mainstream browsers.

What is the difference between SSL and TLS?

TLS is the modern protocol that HTTPS uses; SSL is the name of its older predecessor. “SSL certificate” is the common name for what is technically a TLS certificate.

Why does my new custom domain say “not secure”?

The host usually can’t issue the certificate until your DNS points at it. Check the records, remove conflicting ones, and wait for the host to show the certificate as issued, typically minutes to an hour after DNS is correct.

How long do SSL certificates last now?

Certificates issued from 15 March 2026 can be valid for at most 200 days, dropping to 100 days in March 2027 and 47 days in March 2029. Let’s Encrypt currently issues 90-day certificates.

Is Let’s Encrypt safe to use for a business?

Yes. It is a widely used certificate authority whose certificates are trusted by mainstream browsers. It issues domain-validated certificates, which is the type most websites and apps use.

What does HSTS do?

It is a response header that tells browsers to use only HTTPS for your site for a set period. It protects against downgrade attacks but prevents users from clicking through certificate errors, so enable it once HTTPS is reliable everywhere.

Sources