Accessing letsencrypt ssl sites from Iran through Apple devices

Server
41

update the config with
ssl_ecdh_curve auto;
instead of
ssl_ecdh_curve sect571r1:secp521r1:sect409r1:secp384r1:sect283r1:prime256v1;

Or test with just one:
ssl_ecdh_curve secp384r1;

42

This also seems weird:
Session resumption (caching) No (IDs assigned but not accepted)

Try adding:
# Enable session tickets
ssl_session_tickets on;

43

hey, sorry, i passed the max number of replies I’m allowed as a new user on my first day, so the system said I had to wait for 14 hours to reply…so I had to create a new account :stuck_out_tongue: Maybe that’s a strategy to increase the site’s registered users? lol

Anyway, I added ssl_ecdh_curve auto; to the config.

44

placed under ssl_ecdh_curve auto;

45

Zero change - no different…
Be sure you reloaded nginx:
systemctl reload nginx
or
service nginx restart
or
/bin/systemctl restart nginx.service
[or do ALL 3 - just in case]

Also try with:
ssl_ecdh_curve secp384r1;
instead of
ssl_ecdh_curve auto;

46

did everything up there

47

if nginx -t doesn’t show any problems and it still doesn’t want to do what you command it…
I can only assume there is a similar system ahead of yours that is terminating the TLS connections…
Perhaps deep HTTPS inspection from your firewall/IPS?

48

I haven’t applied any firewalls to this server. No clue how to do a deep inspection. Everything I did so far was pretty new to me.

49

I’m talking about another inline device that may be acting as a MITM.

50

Can we see what that has in it?

51

sure...if you can tell me how to show you. I don't even see that path in my server root

52

find /etc/nginx -name forge-conf
That should show you where the path starts.

54

Yes, we are trying to understand what line #2 is doing.

55

contains "ssl_redirect.conf"

56

@rg305 It’s an empty file. Just opened it with sudo nano through the terminal.

EDIT:
Actually, now I’m not even sure if i managed to open it properly. This is what I got when i ran the sudo nano command. Notice how it says “Directory…does not exist” at the bottom?

26%20AM
Screen Shot 2018-12-16 at 1.58.26 AM.png968×682 91.2 KB

57

@rg305
Anyway, it’s way past my bedtime here. I’m very grateful for your time and assistance. Hope I can continue bugging you guys for a solution tomorrow.

Respect :pray:

1 Like
58

I would like to suggest that the packet capture could be very valuable.

Also maybe look at OCSP and at whether you can reproduce this with other DigitalOcean-hosted sites and/or with other sites that use Let’s Encrypt certificates. For example, this forum uses a Let’s Encrypt certificate. Can those devices access this forum from Iran? If so, the problem is presumably not specific to Let’s Encrypt certificates; maybe you could find some other factor that it appears to be specific to.

59

Hello and tnx for your response.

Yes, I can access this forum just fine from here. I’m not saying that the problem is LE, per say. But since it only happens after applying the LE certificate to the server, my assumption is that the root cause is some change that is made to the server config after the installation of the certificate, which Apple doesn’t seem to like.

That’s why I decided to seek help from this forum to start cuz I figured that comparing my server config with that of a working domain might help narrow down and debug the issue.

And the problem is not specific to this domain. This is my test domain. My actual domain has the same issue. I installed the LE certificate on both domains through the Laravel Forge panel. So it might be due to the specific config that is applied by LF?

As for packet captures, I’m a major networking dummy…I installed Wireshark yesterday, but don’t even see any http requests on the panel when I hit the prospective domain from any of my browsers. Or maybe I’m doing something totally wrong? Is there a good tutorial that you know of that shows exactly what I’m supposed to be testing with Wireshark?

60

  1. Close all your browsers.

  2. Open Wireshark on macOS. Select your main network interface and set your capture filter to:

    host 2604:a880:400:d0::e0:5001 or host 162.243.165.63

  3. Start Wireshark capture. Make your request in macOS using a browser that succeeds (such as Chrome).

  4. Press the red "STOP" button and then File->Save the packet capture somewhere. Call it working.pcap.

  5. Start again. Close all your browsers, open Wireshark, same network interface, same capture filter.

  6. Try to connect using macOS Safari to the website. Assuming it fails, press the red "STOP" button, and File->Save the capture. Call it "broken.pcap".

  7. Upload the two packet captures somewhere and link it here.

1 Like
61

@_az tnx for your guidance. I did the capture using the host IP (162…)

working (through FireFox):

broken (through Safari):