I applied for the free SSL certificate in Cafe24 but issuance keeps failing. Why?

Cafe24's free certificate is issued by Let's Encrypt, and Let's Encrypt proves you control the domain by fetching a file over plain HTTP from the domain itself (the ACME HTTP-01 challenge). That has two hard prerequisites: the domain's nameservers must already be delegated to Cafe24, and the domain must actually resolve and answer on port 80 *before* you ask for the certificate. If you request the cert while the nameserver change is still propagating, or while the domain doesn't load yet, the challenge fetch fails and issuance fails with it. The certificate is the last step, not the first — get the domain connecting over plain HTTP, then issue.

HTTPS works on example.com but shows a certificate warning on www.example.com (or vice versa). Is the cert broken?

The certificate isn't broken — it just doesn't cover the name you typed. A TLS certificate is only valid for the exact hostnames listed in its SAN field, and example.com and www.example.com are two different names. Cafe24's free certificate is single-domain (no wildcard), so if it was issued for the root but you visit www — or the reverse — the browser sees a name that isn't on the certificate and throws ERR_CERT_COMMON_NAME_INVALID. Make sure every hostname you actually serve (root, www, and the m. mobile host if you use one) resolves and has coverage, then re-check.

I fixed the certificate but visitors still see the old error. Did it not apply?

Two things linger. First, browsers and intermediate caches hold TLS sessions and pages for a while, so an old error can survive a fix on a client that hasn't reconnected — test in a private window or a second device. Second, and more common on Cafe24: if your nameservers aren't fully delegated yet, some resolvers still send visitors to an old host or a default endpoint that serves a different (or no) certificate via SNI. If different networks disagree — fine here, broken there — you're mid-propagation, not mis-issued. Confirm the certificate from outside your own browser before assuming it failed.

Views: 29

Cafe24 SSL Certificate Error: Why HTTPS Fails

Cafe24 SSL certificate error or HTTPS not working? Check nameserver delegation, issuance readiness, and www coverage. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your Cafe24 site won’t load over HTTPS. Either the browser throws a certificate warning (“Your connection is not private,” NET::ERR_CERT_COMMON_NAME_INVALID or ERR_CERT_AUTHORITY_INVALID), or the free SSL certificate you requested in the Cafe24 panel simply refuses to issue. The domain clearly belongs to you and the site loads fine over plain HTTP — but the padlock never shows up.

Almost every Cafe24 SSL problem comes down to one thing: a certificate is the last step in connecting a domain, and people try to make it the first. Get the order right and the fix is usually obvious.

Symptoms

The browser blocks the site with a certificate warning; the name on the certificate doesn’t match the address you typed.
HTTPS works on the root domain but warns on www (or the reverse), or warns on the m. mobile host.
The free SSL request in Cafe24 fails, times out, or never completes.
HTTP (http://) loads the site fine, but https:// fails or serves the wrong certificate.
It works for you but a colleague on another network still sees the error.

The Two Stages People Collapse Into One

Putting a site on HTTPS through Cafe24 is really two separate jobs, and confusing them is where most of the pain comes from.

Stage 1 — the domain has to actually connect. The nameservers for your domain must be delegated to Cafe24 (or wherever the site is hosted), and the domain has to resolve to the Cafe24 server and answer over plain HTTP. This is ordinary DNS work, and a nameserver change can take up to 24–48 hours to propagate. Until it finishes, the domain doesn’t reliably point anywhere Cafe24 controls.

Stage 2 — the certificate gets issued. Cafe24’s free certificate comes from Let’s Encrypt, valid for 90 days and renewed automatically. Let’s Encrypt doesn’t take your word that you own the domain; it proves it with the ACME HTTP-01 challenge — it fetches a specific file from http://yourdomain/.well-known/acme-challenge/… over plain HTTP. That fetch only succeeds if Stage 1 is already done: the name resolves to Cafe24 and the server answers on port 80. Request the certificate before the domain connects, and the challenge has nowhere to land. Issuance fails, and the error rarely says “your DNS isn’t ready yet.”

So the certificate isn’t the thing that makes your domain work. It’s the thing that only works after your domain already does.

Top 3 Causes

Requesting the certificate before the domain connects. The nameservers aren’t delegated to Cafe24 yet, or the change is still propagating, so the Let’s Encrypt HTTP-01 challenge can’t reach the domain. The tell: plain http:// doesn’t cleanly load from Cafe24 either, or a DNS check shows the domain still delegated elsewhere.
A name the certificate doesn’t cover. Cafe24’s free certificate is single-domain — no wildcard. It was issued for one hostname (say the root), but visitors reach another (www, or the m. mobile host) that isn’t in the certificate’s SAN list. The tell: HTTPS is fine on one hostname and throws a name-mismatch error on a sibling.
Stale delegation serving the wrong certificate over SNI. The domain is mid-propagation, so some resolvers still send visitors to an old host or a shared default endpoint. The server picks which certificate to present based on the SNI hostname, and a default endpoint hands back a certificate for some other name — or none. The tell: the error appears on some networks and not others.

Diagnose with DechoNet

SSL Check shows the certificate the server actually presents for a hostname — the exact names in its SAN, its issuer, its validity dates, and whether the chain is complete. Run it on both the root and the www host: a name-mismatch or a “no certificate” result tells you immediately whether the problem is coverage or issuance.
DNS Lookup confirms whether the domain is delegated to Cafe24 and what its A/CNAME records return — the fastest way to catch a Stage 1 problem masquerading as a certificate error.
HTTP Check verifies the domain answers over plain HTTP, which is the precondition the Let’s Encrypt challenge depends on.

Resolution Checklist

Run DNS Lookup and confirm the domain’s nameservers are delegated to Cafe24 and the A record points at the Cafe24 server. If you just changed nameservers, expect up to 24–48 hours before issuance will succeed.
Confirm the site loads over plain http:// first. Let’s Encrypt’s HTTP-01 challenge can’t complete if the domain doesn’t resolve and answer on port 80 — HTTPS cannot come before HTTP works.
Only then request the free SSL certificate in Cafe24. Issuance failures before the domain connects are expected, not a bug.
Use SSL Check on every hostname you serve — root, www, and m. if you use it. Because the certificate is single-domain, each name needs its own coverage; a warning on www means that name wasn’t included.
If issuance succeeded but a warning persists, test from a second device or network. A per-network difference is stale delegation (wait out the TTL), not a mis-issued certificate.

When to Escalate

If DNS is fully delegated to Cafe24, the domain loads over HTTP, and issuance still fails repeatedly, it’s on Cafe24’s issuance pipeline — contact Cafe24 support with the exact hostnames and the failure message rather than retrying blindly.
If you need to cover the root, www, and multiple subdomains from one certificate, the single-domain free certificate isn’t the right tool — that’s a wildcard or multi-SAN certificate, which is a different product, not a misconfiguration to debug.