SSL error - ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: velonames.com

I ran this command: No. Command/ Using Lovable.

It produced this output:

My web server is (include version): N/A

The operating system my web server runs on is (include version): N/A

My hosting provider, if applicable, is: Registrars is Porkbun, Hosting on Lovable

I can login to a root shell on my machine (yes or no, or I don't know): N/A

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Lovable has an integration via Entri as far as I know

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): N/A

My project was deployed and working great.

Then after a random question about robots.txt , the AI suggested I remove and re-add my custom domain.

This is where it all went pair-shaped.

Since then my site has been inaccessible and nothing I try (or have been asked to try) has worked.

I'm very familiar with hosting control panels, so removing and adding NDS records is not an issue.

I've since tried to

  1. remove the A records
  2. remove the domain from Lovable project
  3. WAITED a considerable time
  4. re-added domain + records

even going as far as trying to renew the SSL on the Registrar (Porkbun) side.

I suspect the SSL issue is between Lovable, Entri and Let's Encrypt but not getting any joy from Lovabel support.

I have now removed all A records from Porkbun and the custom domain from Lovable.

Is there a possibility that the issues was created when the original domain was removed and re-added and a new cert was created but there's still a link to the original cert ?

FYI, I added a second custom domain and that's working fine. So it certainly points to the removing and re-addition of the original domains causing some snafu..

2

Hmmm, I hope lovable support starts to learn about these problems so they can better instruct and support their customers.

Another person posted recently with a similar sounding problem. See: Www. not working using Lovable.dev - #11 by NDX

3 Likes
3

Thanks but it's deeper than a propagation issue.
I suspect the SSL was not revoked when I removed the domain. Then when it was re-added something broke between Lovable and Let's Encrypt.

This is a new venture I am launching and in the 2nd of the website not being accessible..yay

4

There is no need to revoke a prior cert to get a new one. You can see your recent cert history from https://crt.sh below

If you read that other thread you'll see that Lovable uses Cloudflare as part of its infrastructure. There are apparently some startup problems when adding extra domain names. These are worsened when the DNS is modified in hopes of resolving it.

There does seem to be some kind of "syncing" problem but that is likely between Cloudflare and whatever other infra Lovable has.

Let's Encrypt doesn't have to "sync" with anything. It issues certs which are just files. It is up to the system that uses it to apply them correctly.

image
image1851×705 182 KB

PS: I think you meant pear-shaped :slight_smile:

5 Likes
5

:pear: shaped, yep #typo.....really frustrated at this issue

I've has no issues adding custom domains (the first time). This issue arose when it was removed and re-added :-/

Fair enough..another piece of the puzzle solved.

So I'm stuck waiting for Lovable support. Which will probably never bother to reply. :pensive_face:

3 Likes
6

Finally found a solution:

Use Cloudflare as dns management. After creating cloudflare account, change thee name servers to Cloudflare and then you can enable https always and wait for your universal ssl certificate to populate. It took 10min wait time and now both root domain and www work.

7

When you proxied your domain at Cloudflare which encryption mode did you choose?

Because the "good" modes would have failed reaching your Origin same as before. Because they use HTTPS to your Origin same as anyone else.

3 Likes
8

I just changed the name servers from the original Registrar to Cloudflare. So the standard setup without doing anything specific on Cloudflare.
The only thing I've done since is activate always use https, but that was hours after everything was working from whatever device I checked from.

9

To use "always HTTPS" would mean you must have proxied your domain and are using Cloudflare CDN. Cloudflare cannot redirect traffic if it is only the DNS provider.

See: Always Use HTTPS · Cloudflare SSL/TLS docs

It says you can only enable "always" when SSL Encryption Method is not Off.

3 Likes
10

I would not be surprised if re-adding domains causes anything up to a 24 hrs delay in re-allocation of a certificate. I've see similar behavior in github pages and to a lesser extend Cloudflare, the reality is this is all batch automated and all support are likely to do is ask you to wait.

If you don't host it yourself, you don't control it.

The benefit of using Cloudflare in front of everything else is that regardless of what the lower layers do you can choose to proxy via them, which in turn means the entries point to their systems and they can control the http/https responses (they terminate TLS and control the browser facing certificates).

We've seen a couple of posts lamenting Lovable, but as far as I can see the only issue is the delay in automatically doing what's expected, not an actual terminal fault.

2 Likes
11

Yes, you can choose how to connect to the Origin server from their Edge. If you use Flex it always uses HTTP which may have avoided the startup problem at Lovable but then leaves all traffic unencrypted between CF Edge and the Origin. This is not a recommended config even per Cloudflare.

3 Likes
12

Good point

You can also use cloudflare workers to decide how origin requests are proxied (or even if the origin will be asked to handle them at all).

1 Like
13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.