HostBible-managed DV SSL certificates are issued and renewed using ACME-based domain validation. When issuance or renewal fails, it almost always means the Certificate Authority (CA) could not validate control of your domain at the time it tried the check.
This article covers
Why HostBible-managed DV SSL can fail to issue or fail to renew
Validation blockers:
DNS resolution (NXDOMAIN/SERVFAIL, wrong IP/target, propagation, DNSSEC issues)
CAA records blocking issuance
Proxy/CDN / reverse proxy interference
Hostname coverage (apex vs
www, wrong hostname)Reachability (port 80/443 blocked, redirects, WAF/firewall)
This article does not cover
SSL/TLS basics (DV/OV/EV, wildcard, SAN)
Forcing HTTPS / redirect setup (covered elsewhere)
Switching nameservers step-by-step (your DNS article covers that)
How HostBible-managed DV SSL validation works (the part that matters for troubleshooting)
For the CA to issue/renew a DV certificate, it must be able to confirm that your domain is under your control. In practice, that means:
Your domain must resolve publicly in DNS
The CA must be able to reach your domain over the network
The validation request must reach the correct origin (your HostBible site/service)
Nothing (CAA policies, proxies, firewalls, redirects) can block or alter the validation in a way that breaks the expected response
Renewals repeat these checks periodically (before expiration). A certificate that issued successfully last month can still fail to renew later if DNS/proxy/firewall settings changed.
Quick triage checklist (fastest path to the cause)
1) Confirm the domain resolves publicly (A/AAAA/CNAME)
From any machine with terminal access, run:
# Replace example.com with your domain dig +short example.com A dig +short example.com AAAA dig +short www.example.com A dig +short www.example.com AAAA
What you want to see:
Your domain returns records (not blank)
The returned IP/target matches where your HostBible site is actually hosted
Red flags:
No records returned (often NXDOMAIN)
SERVFAIL (commonly DNSSEC/zone issues)
Records point to an old server, wrong provider, or a parked/default destination
AAAA exists but points somewhere unreachable (IPv6 pitfalls—see below)
2) Check for a CAA record that blocks issuance
dig +short example.com CAA dig +short www.example.com CAA
If you see CAA records and they only authorize a CA that isn’t the one being used for your HostBible-managed DV SSL, issuance/renewal can fail.
3) Identify whether a proxy/CDN is enabled in front of the domain
If your DNS points to a proxy/CDN or reverse proxy rather than directly to HostBible, validation can fail when:
the proxy blocks the validation request,
the proxy rewrites responses,
the proxy forces redirects in a way the CA can’t follow,
or the proxy routes to the wrong origin.
4) Confirm reachability (port 80 matters even if you “only use HTTPS”)
Many DV validations still require the CA to access your domain on port 80 (HTTP), even if your site uses HTTPS. Check:
curl -I http://example.com/ curl -I http://www.example.com/
Red flags:
timeout / no response
connection refused
403/401 from a firewall/WAF
redirects to a different domain, or endless redirect loops
5) Confirm you’re requesting the right hostnames
Common mismatch:
You expect SSL on both
example.comandwww.example.com, but only one hostname is actually attached to the HostBible site or included in the certificate order.
Common failure patterns and how to fix them
Issue A: DNS does not resolve (NXDOMAIN) or returns no usable record
Symptoms
SSL stays “pending,” “failed,” or renewal fails
digreturns nothing for A/AAAA/CNAMEUsers may see “site can’t be reached” intermittently
Why it breaks ACME
If the CA can’t resolve your hostname in public DNS, it has nowhere to send the validation request.
Fix
Ensure the hostname(s) you want secured have valid records:
Apex (
example.com): usually an A record (and optionally AAAA)www: usually CNAME to the apex or an A record
Confirm you edited the authoritative DNS zone (the one your nameservers actually serve)
Allow time for propagation if you just changed DNS
Extra DNS edge cases
SERVFAIL often indicates a DNS configuration problem (commonly DNSSEC/DS mismatch). Fix DNS errors first—ACME will not validate through a broken zone.
Split-horizon DNS (different answers internally vs externally) can fool local tests. Always test using public resolvers.
Issue B: DNS points to the wrong place (validation hits the wrong server/site)
Symptoms
Your domain resolves, but SSL still fails
curl -I http://example.com/shows a different website, a default page, or a redirect to somewhere elseThe CA fetches the challenge from a location that is not your HostBible site
Why it breaks ACME
The CA validates the hostname you requested. If DNS routes that hostname somewhere else, the validation response will not match what HostBible expects to present.
Fix
Update the A/AAAA/CNAME records so the hostname points to the correct HostBible destination
If you host multiple sites, confirm the domain is attached to the correct site/application inside HostBible (so the platform knows where to answer validation for that hostname)
Issue C: IPv6 (AAAA) record exists but is unreachable or misrouted
Symptoms
Some networks can reach your site, others cannot
SSL issuance/renewal fails even though IPv4 looks correct
DNS shows an AAAA record, but your server/proxy isn’t actually serving IPv6 properly
Why it breaks ACME
Some validators prefer IPv6 when AAAA exists. If the IPv6 address is broken, the CA may fail validation even though IPv4 is fine.
Fix
If you don’t intentionally serve IPv6, remove the AAAA record
If you do serve IPv6, ensure the IPv6 address is correct and your server/proxy listens properly
Issue D: CAA record blocks the CA from issuing the certificate
Symptoms
Error messages mentioning CAA, “forbidden,” or “not permitted by policy”
dig … CAAreturns one or more CAA records
Why it breaks ACME
CAA records tell certificate authorities whether they are allowed to issue certificates for your domain. If your domain has CAA records that don’t allow the CA used by HostBible-managed DV SSL, issuance and renewals can be blocked.
Fix options
Temporarily remove the CAA record(s), wait for DNS propagation, then retry issuance/renewal.
Update the CAA record(s) to authorize the CA used by HostBible-managed DV SSL.
Important notes about CAA
CAA can be set at the apex and affect subdomains depending on lookups up the DNS tree.
Multiple CAA records can exist; conflicting or incomplete sets can block issuance.
If you’re not sure what CAA value to use, contact HostBible Support with your domain and a screenshot/output of your current CAA lookup.
Issue E: Proxy/CDN/reverse proxy interferes with validation
Symptoms
You are using a proxy/CDN in front of your domain
curl -I http://example.com/returns:403/401
a challenge/JS page
a bot-check page
or caching headers that suggest edge content is being served
The
.well-knownpath is blocked or rewritten
Why it breaks ACME
ACME validation requires the CA to fetch a specific response. Proxies/CDNs can block bots, require browser checks, rewrite redirects, cache the wrong thing, or send requests to the wrong origin.
Fix
Temporarily disable proxying (set DNS to “DNS only” / direct to origin) during issuance/renewal, then re-enable afterward
Ensure your proxy/CDN allows requests to:
http://YOURDOMAIN/.well-known/acme-challenge/...
Disable or bypass:
“bot protection” rules that block automated validation
WAF rules that block unknown user agents
rules that force authentication or return a 403 for
.well-known/*
Tip for testing
A random challenge URL will usually return 404 (that’s okay). What you don’t want is a 403, a browser-check page, or a redirect to another domain:
curl -I http://example.com/.well-known/acme-challenge/test
Issue F: Port 80 is blocked or the domain is not reachable from the public internet
Symptoms
curl -I http://example.com/times out or can’t connectFirewalls/security plugins block unknown traffic
Geo/IP restrictions block external validators
Why it breaks ACME
If the CA can’t connect to your domain reliably, it cannot validate.
Fix
Allow inbound traffic on:
port 80 (HTTP) for validation, and
port 443 (HTTPS) for normal secure access
Remove or relax firewall/WAF rules that block automated validation requests
If you have IP allowlists, ensure they’re not preventing public access during issuance/renewal
Issue G: Redirects break validation (loops, cross-domain redirects, forced rewrites)
Symptoms
“Too many redirects”
Redirects to a different hostname (e.g.,
example.com→www.example.net)Redirects to a login page or application route that never serves the expected validation response
Why it breaks ACME
Most validators can follow simple redirects, but validation can fail if:
the redirect chain loops,
the redirect jumps to a different domain/hostname,
the redirected destination is blocked, or
the application returns a generic page instead of the validation response.
Fix
Remove redirect loops
Avoid cross-domain redirects for the hostname you’re validating
Ensure the validation path can be served normally (not sent to auth/login routes)
(Redirect/HTTPS-forcing “how to set it up” is covered in a separate HostBible article; the key point here is to avoid redirects that prevent validation from completing.)
Issue H: Hostname coverage mismatch (the certificate request doesn’t match the hostname you’re visiting)
Symptoms
SSL works for
www.example.combut notexample.com(or vice versa)Browser shows certificate name mismatch
Only one hostname shows as protected in your dashboard
Why it breaks issuance/renewal
HostBible can only issue/renew for hostnames that are properly added to your site and included in the managed SSL order. If www isn’t configured, it won’t validate (and won’t renew later).
Fix
Decide which hostnames you need covered (commonly both
example.comandwww.example.com)Ensure each hostname:
resolves in DNS to the correct destination, and
is added/assigned to the correct HostBible site/service
Renewal-specific causes (why it used to work but fails now)
Renewal failures usually happen after a change like:
DNS updated to point elsewhere
A proxy/CDN was enabled or tightened (WAF/bot protection)
CAA records were added/modified
Port 80 was blocked (firewall/security hardening)
AAAA (IPv6) was added and is not working
The domain was moved to a different site/account but the old SSL order remains
The fix is the same: restore validation prerequisites, then retry.
After you fix the blocker: re-issue / retry renewal in HostBible
Once DNS/proxy/CAA/reachability is corrected:
Use your HostBible dashboard/tools to retry SSL issuance or re-run certificate provisioning for the affected domain.
If the system queues an automated recheck, allow time for DNS propagation and then retry again.
If you still see a failure after you’ve confirmed DNS + reachability are correct, collect the diagnostics below and contact support.
What to send HostBible Support (so we can resolve it faster)
Include:
The domain and the hostname(s):
example.com,www.example.com, and any other affected subdomain(s)
Whether a proxy/CDN is enabled in DNS
Output of:
dig +short example.com Adig +short example.com AAAAdig +short example.com CAA
Output of:
curl -I http://example.com/curl -I http://example.com/.well-known/acme-challenge/test
The exact error text shown in HostBible (or a screenshot)
Summary (what “good” looks like)
HostBible-managed DV SSL can issue/renew when all of the following are true:
✅ Your hostname resolves publicly in DNS (no NXDOMAIN/SERVFAIL)
✅ DNS points to the correct HostBible destination (and not an old server)
✅ No CAA policies block issuance
✅ Proxy/CDN/WAF does not block or rewrite validation requests
✅ Port 80/443 are reachable from the public internet
✅ The requested hostname(s) are correctly attached to your HostBible site/service
If you want, paste your domain’s A/AAAA/CAA lookup outputs to Support team (with the domain redacted if needed), and they’ll tell you which blocker is most likely based on what you’re seeing.