Project: dopamine-fanzine (team: mendesgrupocreativo-8778s-projects, Hobby plan)
Framework: Next.js 15 · DNS: Cloudflare, every record proxy-disabled (grey cloud)
Summary
Six domains are attached to one project. All six report verified: true and misconfigured: false, yet only one has a usable certificate. The other five have been without working TLS for more than 28 hours. There are two distinct failure modes, and I think the first one is the key to both.
A) A certificate was issued with an incomplete SAN and has never been retried
dopaminefanzine.com (apex) serves a valid certificate:
- Subject: CN=dopaminefanzine.com
- Issuer: Let's Encrypt CN=YR1)
- NotBefore: 2026-08-03 14:13:59
- SAN: DNS=dopaminefanzine.com ← apex only, no www
www.dopaminefanzine.com is served that exact same certificate, so browsers reject it: the certificate is valid, just for a different name. Vercel normally issues one certificate covering apex + www together.
The timing explains how it happened, but not why it hasn't self-healed. At 14:13 the apex already pointed at Vercel while www was still behind Cloudflare's proxy. Issuance appears to have been scoped to whatever validated at that instant. www has been pointing at Vercel for many hours since, and no re-issuance has occurred.
B) Four hostnames have no certificate at all
These close the TLS handshake without presenting anything:
What I have verified myself
- GET /v6/domains/{domain}/config returns misconfigured: false, conflicts: [ ], acceptedChallenges: ["http-01"] for the affected domains.
- All six return HTTP 308 on port 80. Requests reach Vercel and are correctly associated with the project. Only TLS is missing.
- http://{domain}/.well-known/acme-challenge/ returns 404, not 308, on every host. The 308 redirects on the five secondary domains are not intercepting the ACME challenge path, so HTTP-01 validation is not blocked.
- No CAA records on any of the three zones — nothing restricts Let's Encrypt.
- No AAAA records anywhere. A/CNAME only, all resolving to Vercel.
- Nothing is proxied through Cloudflare; every record is DNS-only.
- I have deliberately not removed or re-added any domain, to avoid resetting issuance or burning Let's Encrypt rate limits.
Current DNS
| Hostname | Role | DNS | TLS |
|---|---|---|---|
| dopaminefanzine.com | primary | A 76.76.21.21 | ✅ 200 |
| www.dopaminefanzine.com | 308 → apex | CNAME cname.vercel-dns.com | ❌ wrong SAN |
| dopaminefanzine.press | 308 → .com | A 216.198.79.1 + 64.29.17.1 | ❌ none |
| www.dopaminefanzine.press | 308 → .com | CNAME cname.vercel-dns.com | ❌ none |
| dopaminefanzine.eu | 308 → .com | A 76.76.21.21 | ❌ none |
| www.dopaminefanzine.eu | 308 → .com | CNAME cname.vercel-dns.com | ❌ none |
A hypothesis I tested and ruled out
ipStatus reports optional-change for the apex domains: rank 1 is 216.198.79.1 / 64.29.17.1, rank 2 is the legacy 76.76.21.21. I wondered whether the legacy IP was blocking issuance.
As a controlled test I migrated only the .press apex to the rank 1 pair and left everything else untouched. More than 8 hours later it still has no certificate, while the one apex that does work is still on the legacy IP. The IP value is not the cause. I'm reporting this so nobody spends time on that path.
What I'm asking
- Can a certificate re-issuance be triggered for these six domains? Specifically a certificate for dopaminefanzine.com that includes www in its SAN, plus initial issuance for the four .press / .eu hostnames.
- Is there a supported way to force renewal without removing and re-adding the domain?
- Is the incomplete-SAN certificate expected behaviour when a domain's DNS is only partially ready at issuance time? If so, is there a retry mechanism, and what triggers it? Right now it looks like issuance is a one-shot that captures whatever validated at that moment and never revisits it.
Happy to provide deployment IDs or run any diagnostic command you need.
