• 12

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191


File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

name Punditsdkoslkdosdkoskdo

Some clients can't connect to my website via SSL

I have a website with verified SSL. Everything is ok except one thing. In our country there is a mobile internet provider whose clients can't access our website. When they try to access my website through their mobile network, they can't. After their report I tried it myself, and same result. FTP, :80, SSL 10000 ports are OK. But only SSL 443 gives timeout. No access to my server. I have checked server logs, and found no log entries from those IP-s, so it means that their request doesn't reach my server. Just timeout after some seconds trying. I contacted the mobile provider's support, they investigated and assured me that they haven't blocked any port or hostname for my dedicated server. And one more strange fact: only 60-70% their clients can't connect to my ssl website, other 30-40% connect without any trouble. Is there any way to find the real reason of problem? telnet, ping, traceroute, dns and network structure checking didn't give any result. If the problem lies in the mobile provider's network, I have to prove it to them, else they reject their fault and advise me to check my server structure again.

Generalized Problems

The CRL specified in the trust chain is timing out. See SLL LABS. There is also an anchor problem. Some browser addons may block based on this. Both Mac OS X and IOS have options to block of the CRL/OCSP is not reachable.

You should reach out to Comodo or your SSL cert reseller and ask for help. Give them the SSL Labs link.

Mobile Provider Debugging

Mobile providers almost always go through their carriers proxy. This is usaully transparent to the mobile subscribers, as a cert is installed on their devices to trust the carrier's proxies. Their customers would have to contact that provider and ask for them to look into it. Their proxy logs will have more details. It is also possible the mobile provider has blocked access to your hosting provider, or vice versa.

  • 1
Reply Report
      • 1
    • 1. It can't be related to browser. As same browsers(tested with 3-4 different devices and OS-es) successfully load my webpages via wifi or via another mobile providers' connections. The problem is only with one mobile provider. 2. They assured me that they haven't blocked my server. 30-40% of their clients can open my website without any trouble. But another 60-70% can't. + ftp, http and even ssl with 10000 port load OK. Only 443 is problematic. And in my server there is not any blacklist or blocking firewall.
      • 1
    • At this point I believe you would need to debug the issue with a few of the people that can reproduce the problem. There are too many rabbit holes for us to venture down without more information, in my opinion.

You may try to pinpoint the problem using tcptraceroute or tracetcp which will trace the route using TCP connection attempts on a given port, so they'll be sensitive to problems affecting only one port.

Also check whether the mobile provider in question has a mandatory or transparent web proxy in place. Some providers use this to compress graphics in order to reduce bandwidth consumption on the mobile network.

  • 0
Reply Report
    • This is a "regular" traceroute which works through UDP and as such is frequently blocked. The screenshot also shows that this mobile provider is employing CGNAT. So my advice stands: try tcptraceroute or tracetcp, and try to find out whether the mobile provider has a proxy in place.
    • They said me that "You can't use such tools as your mobile provider IP is dynamic. You should buy static IP to monitor traces." i am not sure if they are right or not. So, here is 2 results, first one is the result with my normal eth0 internet, second one is one with mobile internet. 1st one took 2-3 seconds, 2nd took 2-3 MINUTES(!). dropbox.com/s/iltac81alb3ivm8/…
      • 2
    • Well, "you can't use such tools" is obviously incorrect since you just did. :-) How to interpret the results is of course another matter. Unfortunately you didn't use tcptraceroute correctly. -p sets the source port but you need to set the destination port. Please repeat the test with destination port 443, ie. tcptraceroute bilikli.net 443. (without -p)

Trending Tags