I am seeking help with a persistent issue connecting my custom domain, shiftur.site, to my project (shiftur-site). I have followed all the standard procedures, but I seem to be stuck in a loop.
Here is a summary of the steps I’ve taken and the results:
Initial Setup:
I have correctly pointed my DNS records (A record to 76.76.21.21 and CNAME for www) to Vercel via my DNS provider, Cloudflare.
My SSL/TLS mode in Cloudflare is set to “Full”.
Problem 1: With Cloudflare Proxy ON (Orange Cloud)
When Cloudflare’s proxy is active, my website shows a Cloudflare Error 525: SSL handshake failed. (I will attach a screenshot of this error below).
At the same time, my Vercel dashboard shows a “Failed to Generate Cert” error for the domain.
Troubleshooting Step Taken:
Based on troubleshooting guides, I then paused Cloudflare to allow Vercel to directly verify the domain and issue the certificate.
Problem 2: With Cloudflare Paused (DNS Only)
After pausing Cloudflare and waiting for some time, the error changed. Now, when I visit my site, I get a browser error: ERR_CONNECTION_CLOSED.
The Vercel dashboard still shows "Failed to Generate Cert.”
I have now resumed (un-paused) Cloudflare, and the error has gone back to the “SSL handshake failed” screen. It feels like I’m stuck in a loop.
I suspect this might be related to the “active incident affecting DNS record updates” that was mentioned on the support page.
Could anyone from the Vercel team please check from your end what is preventing the SSL certificate from being issued for my domain shiftur.site? It seems the verification process is failing on Vercel’s side.
Thank you to anyone looking into this. I wanted to provide a quick update on the troubleshooting steps I’ve taken on my end in Cloudflare to rule out any issues there:
DNS Records: Confirmed my A and CNAME records are pointing correctly to Vercel.
SSL/TLS Mode: I have tested with both “Full” and “Full (Strict)” modes.
Universal SSL: I have completely Disabled and then Re-enabled Universal SSL to force a new certificate issuance.
HSTS: Confirmed that HSTS is and has been disabled.
CAA Records: Confirmed that a CAA record for letsencrypt.org already exists.
Even after performing all these standard fixes, my Vercel dashboard still shows on my live site shows an SSL Handshake Failed (Error 525).
This now strongly confirms that the issue is not with my Cloudflare configuration but with a persistent problem on Vercel’s end in generating the certificate for my domain (shiftur.site).
Could a Vercel staff member please manually intervene and force a re-issuance of the SSL certificate for this domain? It appears to be permanently stuck.
At this point, since the SSL certificate seems to be stuck on Vercel’s end (and Error 525 usually points to the origin certificate issue), the best path is to open a support ticket with Vercel. Try here: https://vercel.com/help
Thank you for the suggestion to create a support case.
I have just tried to do that, but unfortunately, I’ve hit a complete dead end, and I’m hoping a Vercel staff member can see this.
Here’s the problem I’m facing with the support system:
When I go to the “Submit a case” form, I select my problem area as “SSL Certificates”.
The form then automatically locks the Severity Level to “Severity 1 (Active production downtime)”. It does not give me any other option to choose from.
Because “Severity 1” is selected, the form then tells me that dedicated support is only for paid plans and does not provide any fields to enter a subject or description.
I also tried to “trick” the system by choosing a different problem area like “Build and Deployment,” but the Severity Level remains locked to “Severity 1” for that as well, so I still cannot submit a case.
I am now completely stuck in a support loop. I cannot get help because my problem is automatically classified as too urgent for a free plan, and I cannot submit a less urgent ticket because the form will not let me change the severity.
My domain shiftur.site is still down..!
Could a Vercel staff member please see this and create a support ticket on my behalf? It seems the support system itself is preventing me from getting help. If this SSL issue requires a paid plan to be resolved, please advise on which specific plan I would need..
Thank you so much for the quick and insightful response. I really appreciate your help.
Following your advice, I have just performed a thorough check of all the TXT records in my Cloudflare DNS for shiftur.site.
I can confirm that there are no existing _acme-challenge records interfering with the certificate generation. (I have attached a screenshot of my TXT records for your reference).
This confirms that the issue is not with my DNS configuration. It seems my case is indeed related to the ongoing internal issue at Vercel regarding certificate generation for custom domains.
Could you please escalate this internally to have the SSL certificate for shiftur.site manually pushed or re-issued? My site has been down for a while now, and this is the only remaining blocker.
I tried to manually renew the cert, but that ran into the same issues that prevented the automatic cert. Either way I see the error message We could not generate a cert for www.shiftur.site because the required http-01 challenge failed.
Let’s Debug HTTP-01 check shows Sending an ACME HTTP validation request to shiftur.site results in unexpected HTTP response 403 Forbidden. This indicates that the webserver is misconfigured or misbehaving.
Thank you again for your continued guidance. I am posting a final update as the issue unfortunately still persists even after trying every possible fix.
I am now certain the problem is an internal issue on Vercel’s end that requires manual intervention.
Here is a complete summary of every troubleshooting step I have taken:
DNS Records:Confirmed my A and CNAME records are correctly pointing to Vercel.
CAA Record: Confirmed a CAA record for letsencrypt.org exists.
ACME Challenge Record: Confirmed there are no old _acme-challenge TXT records in my DNS.
WAF Bypass Rule: I have successfully created and activated a WAF rule in Cloudflare to Skip all security for the path /.well-known/acme-challenge/.
Cloudflare SSL/TLS Mode: I have tested thoroughly with both “Full” and “Full (Strict)” modes, purging the cache each time. The issue persists on both.
Universal SSL Reset: I have completely “Disabled and then Re-enabled” Universal SSL in Cloudflare and waited over 30 minutes before purging the cache.
HSTS: Confirmed that HSTS is and has always been “disabled” .
The Result:
Even after all these steps, my Vercel dashboard shows a valid configuration (blue tick) , but my live site shiftur.site is still showing the “Error 525: SSL handshake failed” .
I am attaching screenshots of my active WAF rule, my “valid” Vercel dashboard, and the persistent handshake error on the live site. This now confirms that the issue is not with my Cloudflare configuration. The problem seems to be permanently stuck on Vercel’s side.
Could a Vercel engineer please manually intervene and force a re-issuance of the SSL certificate for my domain? My site is still down, and I have now exhausted all possible troubleshooting steps.
As I mentioned before, I already tried to manually force the cert. The challenge failed even when attempting to manually force it the same way the automatic process failed. Looks like one of your changes worked and you just needed to give it some time to propagate.
Thank you so much for your help. The SSL certificate is now valid and the “handshake” error is gone! I really appreciate your support in getting that resolved.
However, I’ve immediately run into a new, very strange issue with how the site is being served, and I’m hoping you can provide some final insight.
Here is the behavior I am consistently seeing:
On Desktop Browsers:
When I visit shiftur.site for the first time in any desktop browser (Chrome, Firefox, including Incognito mode), the page fails to load. I receive a blank white page with an HTTP ERROR 405 (Method Not Allowed) .
If I then immediately refresh the page , the site loads perfectly and works as expected.
On Mobile Browsers:
On any mobile browser (e.g., Safari or Chrome on iOS), the site never loads . It just shows a blank white page, even after multiple refreshes.
This behavior (working only after a refresh on desktop, and never on mobile) suggests that this is not a DNS propagation or local cache issue. It feels like there is a server-side or edge configuration problem within Vercel that is incorrectly handling the initial request to my domain.
Could you or your team please check the server logs for shiftur.site to see why the initial GET request is being rejected with a 405 error? It seems the server might be misconfigured for the first visit from a new session.
Thank you again for your incredible support in helping me get this last issue sorted out
Since a 405 error is related to allowed request methods, it’s most often caused by something within project code/configuration. The runtime logs may have more info. I found a few instances of others with a similar problem and they’ve shared ways to fix it. Sharing in case it’s useful to you.
For what it’s worth, I wasn’t able to replicate the 405 issue you saw. But I can share this thread with the team in case there’s something we need to adjust
First, I want to clarify that the links you provided (specifically the one referencing the @walosha solution for an ejs.renderFile path issue) are not applicable to my project. I have downloaded the full repository to VS Code and can confirm that my project does not use EJS templates. Instead, all my forms are powered by the Resend API for sending emails.
Here is a complete summary of the actions I’ve taken since your last message:
Confirmed Resend is Working: My contact forms are indeed functional. When the site loads after a refresh, form submissions work perfectly, and emails are being received via Resend. This confirms that my RESEND_API_KEY is working correctly.
Added All Environment Variables: Even though Resend was working, I took the precaution of adding all other necessary environment variables to my Vercel project. I have now added the following three keys and redeployed:
VITE_SUPABASE_PROJECT_ID
VITE_SUPABASE_PUBLISHABLE_KEY
VITE_SUPABASE_URL
(These were required for my Supabase backend connection, which I thought might be related).
Purged Cache: After redeploying with the new variables, I performed a full cache purge on Cloudflare (“Purge Everything”).
The Result:
Unfortunately, the exact same issue persists:
On Desktop: Visiting shiftur.site for the first time results in a blank page with an HTTP ERROR 405 . A simple refresh then loads the site perfectly.
On Mobile: The site never loads , showing only a blank white screen, even after refreshing.
My Final Questions:
I have now confirmed that the issue is not related to the ejs path, and it is not a missing API key. It is a persistent bug in how Vercel’s production environment handles the very first request to my site.
Is this strange behavior (405 on first load, works on refresh) a known limitation or bug related to the Hobby (Free) plan?
My site was built with Loveable.ai , an AI code generator. The code is now in my own VS Code. Could there be a known incompatibility between Loveable-generated code and Vercel’s edge functions that would cause this?
At this point, I have exhausted all possible user-side fixes. I am completely stuck. Could you please escalate this to an engineer to check the runtime logs and diagnose this 405 error?
A 405 on first load is not expected behavior on any plan. Your plan type, Hobby or otherwise, does not appear to be a relevant variable. The 405 status code is a client error response telling you the requested resource doesn’t support the method used (e.g. GET, POST).
I’m not aware of a known incompatibility between LLM-generated code and Vercel. But it does appear there’s something misconfigured in your project. I’m not able to replicate the behavior you’ve seen though, so I’d recommend clearing your browser cache or trying from a different browser in case something was previously cached and has continued to show you the error code.
If the issue persists, you don’t need to wait on an engineer to check the runtime logs. You can access them yourself from your project dashboard
You should also take a look at any errors or warnings logged in the dev tools console and network inspector. Client side issues will be logged there.
