Technology
A certificate can install successfully and still be wrong
The control panel reported the SSL certificate installed successfully. The browser still showed a security warning. Both were telling the truth, and the gap between them is worth understanding if you host anything yourself.
by Patrick Albert
We were moving a site between servers. Files copied, DNS pointed at the new machine, certificate requested and issued. The control panel logged the domain validation as successful and finished with the word Success.
Loading the site over HTTPS produced a full browser interstitial warning about a self-signed certificate.
Why both were correct
The certificate really had been issued and really had been written to disk. That is what the control panel was reporting, and it was accurate.
What it does not report is whether the web server has read that file yet. Apache loads its certificate configuration when it starts. Writing a new certificate to disk does not make a running server notice. Until it reloads, it keeps serving whatever it had before.
What it had before was the machine's own default certificate, issued for the server's hostname rather than for the site. A browser asking for one domain and receiving a certificate for another is exactly the condition that triggers the warning. The certificate was not really self-signed. It was simply the wrong one.
The fix
Rebuild the web server configuration, then restart the service. Then, and this matters, check with an actual request from outside rather than trusting the success message.
Verify with a request, not with a status message. The status message is describing a different step than the one you care about.
A diagnostic that lied to us
Along the way we used a common trick for inspecting which certificate a server is presenting: connect to the machine's own loopback address and ask for a specific domain by name.
On that server it returned the hostname certificate no matter which domain we asked about, because the site configurations are bound to the public address and a loopback connection falls through to the default. It happened to agree with the real problem that day, which made it look like a good diagnostic. It was not. It would have given the same answer on a perfectly healthy site.
We record that because a tool giving the right answer for the wrong reason is more dangerous than one that is obviously broken. You trust it the next time and it misleads you.
Two smaller traps from the same afternoon
- Ordering matters. A certificate validation run before the new site configuration is live will fail, because the challenge request lands on whatever configuration is currently answering. The failure looks like a permissions or DNS problem and is neither.
- Silencing a command hides the failure you are looking for. Running the request in quiet mode returned nothing at all, which we briefly read as a network problem. It was suppressing the certificate error that was the entire answer.
If you host your own sites
Automatic certificate renewal is one of the genuinely good things about modern hosting, and it is close to invisible when it works. The failure mode is that it can report success at every step and still leave visitors looking at a security warning, because issuing a certificate and serving a certificate are two different operations.
Build the habit of checking the live site from outside after any certificate change. It takes ten seconds and it is the only step that tests what your customers actually experience.