TLS error with Stripe webhook

Questions / Help
,
1

I have a Phoenix project using stripity_stripe to connect to Stripe. It’s deployed to fly.io.

Everything works well locally but, in production, the Stripe webhook is failing with a TLS error. It doesn’t provide further details. It just says it returned a TLS error:

Stripe webhook screenshot
Stripe webhook screenshot1182×662 27.4 KB

The certificate seems to be working fine when I visit the website, though. They also show up on the dashboard:

fly certificates dashboard
fly certificates dashboard2440×564 63.3 KB

Stripe has a support page that asks us to use a tool to check for TLS issues. It shows the following results:

TLS check screenshot
TLS check screenshot2130×556 43.7 KB

Clicking on that link says this: Unable to connect to server - failed to connect to the server, it usually happens due to firewall restrictions.

I have no idea what’s going on here. Did anyone have this issue in the past?

2

I just did another check and seems fine now.

Can I ask you if that stripe event happened 11 hours ago as in 2023-12-28 10PM UTC ish? Im currently on-call (yay on-call in new years) and I saw some alerts for a few edges having network issues for around 5~10 minutes, that could be it.

Fun fact: we also run Stripe webhook on a Fly app hosted here :slight_smile:

1 Like
3

The first event happened in 2023-12-28 10:03:54PM UTC. But I’ve tried to resend that event a few times (just did it again now) and the error is still happening.

I initially thought I could be an issue with my certificates because I had generated one for wikaro.io, then I created another one for *.wikaro.io but I realized the wildcard one is also valid for wikaro.io. So, I deleted it and kept only the wildcard one but it didn’t work, the error is still happening on Stripe.

I’ve contacted Stripe support to see if they can provide more information. The dashboard logs just show the “TLS error”, no further data. I’ll update this thread after I hear back from them.

1 Like
4

I’ve updated my webhook endpoint to use www.wikaro.io instead of just wikaro.io and it worked now. Maybe there’s an issue with the wildcard certificate not working properly with wikaro.io in certain cases? No idea if that’s the case but it’s working now.

1 Like
5

I don’t think wildcards work with shared IPv4s. We should improve this by documentation and probably preventing a user from adding a wildcard hostname if they’re using a shared IPv4.

I’m looking at the code to see if there’s an “easy” fix for it in our proxy.

Edit: nevermind, seems like you’re not using a shared IPv4! I got confused.

Edit 2: Bypassing Cloudflare makes it work for me.

1 Like
6

Yeah, the UI actually prevented me from creating a wildcard certificate until I removed the shared IPv4. So, the UX was good there (it would be great if there was a button to do it in the UI while adding the certificate, though. It took me a few minutes of reading the docs to learn what I had to do).

For example:

  • Error: You cannot have a shared IPv4 for wildcard certificates.
  • Action button: Add a dedicated IPv4 for $2/month.

Bypassing Cloudflare makes it work for me.

Do you recommend disabling Cloudflare protection on Fly? I remember reading something about it a sometime ago.

7

I do think it’s better to reduce the number of layers if you don’t need the features from the upper layers. So, it depends on what you need.

We’ve had some TLS issues with our users going through Cloudflare. Usually, you’d see a Cloudflare error, not just a connection reset.

1 Like
8

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