For most nonprofit publishers, SSL certificates are something you set once and forget. They renew automatically, they keep your visitors safe, and they quietly do their job in the background. Until they don’t.
This week, one of our team members ran into a problem that looked simple on the surface — an SSL certificate refusing to install — but the real cause turned out to be a perfect storm of old settings, new domains, and a forgotten DNS security feature from years ago.
The lesson?
Sometimes the thing that breaks your website isn’t what you changed yesterday…
It’s what you configured years ago and forgot existed.
The Symptom: SSL Wouldn’t Install No Matter What
The domain thewalloffame.net suddenly lost its SSL certificate. Browsers showed warnings, AutoSSL refused to issue a new certificate, and WHM locked the SSL toggle in the “OFF” position.
Even after:
- Deleting the entire cPanel account
- Recreating it from scratch
- Clearing AutoSSL caches
- Rebuilding Apache
- Removing dozens of parked domains
…the SSL still refused to install.
AutoSSL logs showed this ominous message:
CAA records forbid the CA from issuing
DNSSEC: DNSKEY Missing: validation failure
That was the clue that cracked the case.
The Hidden Culprit: Old DNSSEC Settings From Years Ago
Years earlier, a third‑party tool recommended enabling DNSSEC and adding DS records for “domain handshake verification.”
It worked fine at the time.
But when the domain was reorganized recently — with multiple parked domains removed, DNS zones rebuilt, and AutoSSL forced to revalidate everything — Let’s Encrypt performed a deeper DNS check.
That’s when the problem surfaced:
DNSSEC was still enabled at the registrar… but the DS records were gone.
This created a broken chain of trust, and Let’s Encrypt refuses to issue certificates to domains with invalid DNSSEC.
In other words:
- DNSSEC ON
- No DS record
- No DNSKEY
- = SSL failure every time
AutoSSL wasn’t the problem.
Parked domains weren’t the problem.
Apache wasn’t the problem.
It was DNSSEC — quietly blocking SSL behind the scenes.
The Fix: Remove the DS Records and Disable DNSSEC
Once the DS records were removed at the registrar, everything snapped back into place.
Steps to fix the issue:
1. Log into your domain registrar
Find the DNSSEC section for the affected domain.
2. Remove all DS records
This immediately disables DNSSEC validation for that domain.
3. Save changes and wait 1–3 minutes
DNSSEC clears quickly once DS is removed, but give it a moment to propagate.
4. Re-run AutoSSL
On WHM servers, run:
/usr/local/cpanel/bin/autossl_check --user USERNAME
Replace USERNAME with the cPanel username for the domain.
5. Watch the certificate install successfully
No more DNSSEC errors.
No more CAA failures.
No more SSL toggle stuck OFF.
Why This Matters for Nonprofits and Small Publishers
Many nonprofits inherit domains, migrate hosting providers, or rely on volunteers and third‑party tools to configure DNS. Over time, settings like DNSSEC can be forgotten — until they break something critical.
This incident highlights three important lessons:
1. DNSSEC is powerful, but unforgiving
If you enable it, you must maintain it.
If you don’t need it, disable it.
2. SSL failures aren’t always caused by what you changed today
Sometimes the root cause is buried in old DNS configurations.
3. AutoSSL errors are often symptoms, not causes
When Let’s Encrypt refuses to issue a certificate, it’s usually because DNS validation failed — not because the server is misconfigured.
Final Thoughts
This wasn’t just a technical hiccup — it was a reminder that the internet is built on layers of trust. When one layer breaks, everything above it can collapse in unexpected ways.
If your SSL certificate suddenly refuses to install, don’t panic.
Check your DNSSEC settings.
You might discover, like we did, that the real problem isn’t new at all — it’s a ghost from years past.
