Free SSL and CDN Setup Guide

HTTPS is standard now: browsers label uncertified sites “not secure,” search engines demote them, users won't pay. The good news is certificates and CDN both cost nothing: a free Let's Encrypt certificate plus Caddy's auto-renewal, and Cloudflare's free plan as the CDN. This walks the complete steps from DNS to seeing the lock to cache configuration, with a verification method for each step — finish one before moving to the next.

Step 1: Point DNS at the server

At your domain registrar, add an A record: hostname @ (or www), value your server IP. Wait a few minutes, ping the domain — if it returns your IP, it's live. This step is the foundation; everything after builds on “the domain reaches the server.” A bad foundation wastes everything after, so verify first, then continue.

Step 2: With Caddy, two lines of config for automatic HTTPS

Caddy is a reverse proxy that does the same job as Nginx, but HTTPS is fully automatic: you tell it the domain and the site's port, and it requests the certificate from Let's Encrypt itself and renews automatically — you do nothing. certbot plus Nginx works too, but needs a few more steps; beginners save hassle with Caddy. The config looks like this:

your-domain.com {
	reverse_proxy localhost:3000
}

Replace “your domain” with your own domain, and 3000 with your site's actual port. Start Caddy, open your domain in a browser, and seeing the lock means this step is done. No lock? Read Caddy's logs — they tell you which step failed. The most common is port 80 not open, so the certificate authority can't reach in to verify. Open ports 80 and 443 in the security group, restart Caddy, and try again.

Step 3: Auto-renewal — don't let it expire

Let's Encrypt certificates are valid 90 days. Caddy renews automatically — nothing for you to do; with certbot, installing it auto-adds a cron job that checks daily. Run a dry-run renewal after installing; success gives you peace of mind. An expired certificate is the most embarrassing outage: the site is fine, but the browser suddenly says “not secure” and users all leave. Put “glance each quarter that certificates renewed” on your ops checklist.

Step 4: Cloudflare as the CDN

Go to Cloudflare and add the site; change the domain's NS to theirs as prompted. Once DNS takes effect, turn on proxying for that A record (the orange cloud icon). From this moment, users hit Cloudflare's nodes, which fetch from your server: static files get cached, bandwidth pressure drops, and a wave of small attacks gets blocked along the way. All free, ten minutes to set up. Verify: open the site and look for cf-cache-status in the response headers — that means the CDN is in the path.

Pick Full mode for HTTPS, not Flexible. Flexible means “user-to-Cloudflare encrypted, Cloudflare-to-your-server not” — it shows a lock while the second half runs naked, and it easily causes redirect loops. Pick Full: your server has Caddy's certificate, the whole path is encrypted — that's real HTTPS. The option is in Cloudflare's SSL settings; one minute to change, don't pick wrong.

www vs. non-www: unify to one

Between example.com and www.example.com, pick one as primary and 301-redirect the other to it. Don't serve both: first, it splits authority — search engines don't know which is canonical; second, users' bookmarks and shared links scatter, and the data won't line up. One redirect rule in Caddy does it — five minutes of work; putting it off causes endless trouble later.

Don't cache dynamic content

CDN caching is a double-edged sword: cache a logged-in page and Zhang San sees Li Si's info. The rule is simple: cache images, CSS, JS aggressively; never cache logged-in pages, API endpoints, or admin panels. Use cache rules in Cloudflare to exclude /api/* and admin paths. When unsure, default to not caching — slower beats leaking data by a mile. One data leak costs more than speed: it costs user trust.

HSTS: tell browsers HTTPS only

Once site-wide HTTPS runs smoothly, you can turn on HSTS: it tells browsers “this site only does HTTPS from now on, don't try http.” Users typing http the first time get auto-upgraded to https, closing the man-in-the-middle hole. One response-header line in Caddy does it. But note: make sure site-wide HTTPS is solid before enabling — going back to http afterward isn't easy; browsers remember for a long time.

When things break, check here

• ·Certificate expired: first check the renewal job exists, then check port 80 is open
• ·No lock showing: click the address bar and see whether it's “invalid certificate” or “mixed content” — two completely different causes
• ·Mixed content: the page mixes http images or scripts — change them all to https; the browser dev tools console tells you each one
• ·Redirect loop: eight times out of ten Cloudflare is on Flexible — switch to Full
• ·Just changed and nothing happened: DNS and CDN both cache — wait a few minutes, try another browser or an incognito window

Once this setup runs, your site has: full-path encryption, CDN acceleration, auto-renewing certificates, and a wave of small attacks blocked. Cost: zero. Effect: full marks. What remains is periodic checks: glance each quarter that certificates renewed and at Cloudflare's cache hit rate; the rest of the time, do your thing.

DNS takes time to propagate: don't rush

After changing NS or adding A records, don't expect instant effect. Global DNS propagation takes minutes to hours, depending on TTL. Verify with dig for the authoritative answer — not ping, which uses the local cache and lies to you. Refreshing everywhere right after changing and yelling “it's not working” is the classic beginner move. Change it, go have some water, come back — it'll basically be fine.

Caddy auto-start on boot

Once Caddy is configured, don't run it as a bare command — make it a systemd service that starts on boot. Reload config changes with caddy reload — no restart needed, active users feel nothing. Verify: reboot the server once; it only counts if the site comes back up by itself. If the reverse proxy dies, the whole site dies — it deserves an auto-start.

Multiple domains: one Caddy manages all

With multiple domains, don't run multiple Caddies — one is enough: write one block per domain in the config file, each certificate auto-issued separately. Main site, blog, docs — throw them all at one Caddy; saves memory and hassle. Just don't mix up the proxy ports per domain — mixed up means site A opens site B's content; the logs show it at a glance.

Reverse proxy: don't expose the ports

The site process listens on localhost only; the security group opens only 80 and 443 — don't expose app ports like 3000. Users reach your site only through Caddy; connecting to ports directly shouldn't even be a thought. Database ports even more so — as covered before, localhost only. The fewer exposed ports, the fewer chances to be probed for vulnerabilities — that's security basics.

HTTP/2 and HTTP/3: Caddy enables them by default

Caddy enables HTTP/2 and HTTP/3 by default — nothing for you to configure. Cloudflare's side is also on by default. Multiplexing, header compression — the speed gains come along. Don't go looking for “how to enable HTTP/3” tutorials — yours is already on. Spend the time on content, not on fiddling with things that are already done.

Back up certificates? Don't bother

People ask whether to back up certificates: don't. Certificates auto-renew every 90 days; when you rebuild the server, just request a new one — faster than restoring a backup. Note Let's Encrypt has rate limits (50 per week) — normal use never hits them; just don't script a request loop. For certificates, re-getting beats keeping.

Cloudflare firewall: turn on basic protection

Cloudflare's free plan includes basic protection: turn on Bot Fight Mode and most small crawlers and attacks get blocked. Don't expect it to stop big traffic attacks — that's the paid plan's job; but for everyday nuisances the free plan is enough. Set the “security level” to medium in the security settings — it won't hurt normal users and still blocks the obvious bad guys.

Don't leak the origin IP

With Cloudflare proxying on, users see its IPs, but your origin IP can leak elsewhere: email headers, unproxied subdomains, historical DNS records. Check everything: all subdomains proxied, mail sent via a third party (don't send from the server — headers carry the IP). If it does leak, no panic — change the IP and re-resolve; a few minutes of work.

Migrating from HTTP: the checklist

Migrating an old site from http to https, walk this checklist: change all site resources to https (check for mixed content), 301-redirect http to https, change the site address to the https version in Search Console, update the sitemap. Watch rankings for a week after migrating — no big swings means success. Small short-term fluctuations are normal; search engines need to re-learn your site; don't panic.