2

We are experiencing an issue that is very similar to this:

SSL issues on a mobile website

There is a specific guy that is not able to access our platforms by using the network of his mobile carrier. The domains are these (not real ones):

api.example.co.uk
auth.example.co.uk
admin.example.co.uk

Initially, we thought that there is a DNS issue but debugging it by turning his phone as wifi hotspot we could ping the subdomains above and we were able to access the platforms on port 80 (we could see the redirection to port 443). When we've tried to access one of those by the IP (https://ip_address) we couldn't access it at all and there were no logs on the server which means that it is not a DNS issue and maybe it is something related to SSL. By the way, there are two other guys within the company that they've never experienced this issue and they use the same mobile carrier. Is this assumption correct?

We are using AWS classic load balancers and we've got the SSL certificate from GoDaddy. Is there someone else that experienced something similar?

UPDATE 1

Below you can find traceroute against port 443 and port 80 from a network that works and from the network that fails:

Broken network

~$ ping api.healthera.co.uk
PING api.healthera.co.uk (52.56.123.246): 56 data bytes
64 bytes from 52.56.123.246: icmp_seq=0 ttl=239 time=46.971 ms
64 bytes from 52.56.123.246: icmp_seq=1 ttl=239 time=54.086 ms
64 bytes from 52.56.123.246: icmp_seq=2 ttl=239 time=57.204 ms
64 bytes from 52.56.123.246: icmp_seq=3 ttl=239 time=48.198 ms
64 bytes from 52.56.123.246: icmp_seq=4 ttl=239 time=50.836 ms
64 bytes from 52.56.123.246: icmp_seq=5 ttl=239 time=53.873 ms
64 bytes from 52.56.123.246: icmp_seq=6 ttl=239 time=49.791 ms
64 bytes from 52.56.123.246: icmp_seq=7 ttl=239 time=56.326 ms
64 bytes from 52.56.123.246: icmp_seq=8 ttl=239 time=54.950 ms
64 bytes from 52.56.123.246: icmp_seq=9 ttl=239 time=49.581 ms
64 bytes from 52.56.123.246: icmp_seq=10 ttl=239 time=48.452 ms
64 bytes from 52.56.123.246: icmp_seq=11 ttl=239 time=51.344 ms
64 bytes from 52.56.123.246: icmp_seq=12 ttl=239 time=46.008 ms
64 bytes from 52.56.123.246: icmp_seq=13 ttl=239 time=61.893 ms
64 bytes from 52.56.123.246: icmp_seq=14 ttl=239 time=65.324 ms
64 bytes from 52.56.123.246: icmp_seq=15 ttl=239 time=72.197 ms
64 bytes from 52.56.123.246: icmp_seq=16 ttl=239 time=47.076 ms
64 bytes from 52.56.123.246: icmp_seq=17 ttl=239 time=55.336 ms
64 bytes from 52.56.123.246: icmp_seq=18 ttl=239 time=51.878 ms
^C
--- api.healthera.co.uk ping statistics ---
19 packets transmitted, 19 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 46.008/53.754/72.197/6.583 ms



~$ dig api.healthera.co.uk +trace
; <<>> DiG 9.8.3-P1 <<>> api.healthera.co.uk +trace
;; global options: +cmd
.           263795  IN  NS  f.root-servers.net.
.           263795  IN  NS  j.root-servers.net.
.           263795  IN  NS  k.root-servers.net.
.           263795  IN  NS  b.root-servers.net.
.           263795  IN  NS  c.root-servers.net.
.           263795  IN  NS  e.root-servers.net.
.           263795  IN  NS  d.root-servers.net.
.           263795  IN  NS  a.root-servers.net.
.           263795  IN  NS  h.root-servers.net.
.           263795  IN  NS  m.root-servers.net.
.           263795  IN  NS  i.root-servers.net.
.           263795  IN  NS  l.root-servers.net.
.           263795  IN  NS  g.root-servers.net.
;; Received 228 bytes from 172.20.10.1#53(172.20.10.1) in 12 ms
uk.         172800  IN  NS  nsa.nic.uk.
uk.         172800  IN  NS  nsb.nic.uk.
uk.         172800  IN  NS  nsc.nic.uk.
uk.         172800  IN  NS  nsd.nic.uk.
uk.         172800  IN  NS  dns1.nic.uk.
uk.         172800  IN  NS  dns2.nic.uk.
uk.         172800  IN  NS  dns3.nic.uk.
uk.         172800  IN  NS  dns4.nic.uk.
;; Received 457 bytes from 192.58.128.30#53(192.58.128.30) in 200 ms
healthera.co.uk.    172800  IN  NS  ns-1976.awsdns-55.co.uk.
healthera.co.uk.    172800  IN  NS  ns-704.awsdns-24.net.
healthera.co.uk.    172800  IN  NS  ns-1098.awsdns-09.org.
healthera.co.uk.    172800  IN  NS  ns-251.awsdns-31.com.
;; Received 172 bytes from 156.154.100.3#53(156.154.100.3) in 67 ms
api.healthera.co.uk.    60  IN  A   52.56.65.26
api.healthera.co.uk.    60  IN  A   52.56.123.246
healthera.co.uk.    900 IN  NS  ns-1098.awsdns-09.org.
healthera.co.uk.    900 IN  NS  ns-1976.awsdns-55.co.uk.
healthera.co.uk.    900 IN  NS  ns-251.awsdns-31.com.
healthera.co.uk.    900 IN  NS  ns-704.awsdns-24.net.
;; Received 204 bytes from 205.251.196.74#53(205.251.196.74) in 69 ms


~$ sudo tcptraceroute api.healthera.co.uk 80
Selected device en0, address 172.20.10.5, port 55237 for outgoing packets
Tracing the path to api.healthera.co.uk (52.56.123.246) on TCP port 80 (http), 30 hops max
 1  172.20.10.1  5.244 ms  8.540 ms  10.747 ms
 2  * * *
 3  172.23.128.201  62.617 ms  38.532 ms  48.225 ms
 4  * * *
 5  188.31.253.50.threembb.co.uk (188.31.253.50)  46.400 ms  40.852 ms  47.852 ms
 6  188.31.255.77.threembb.co.uk (188.31.255.77)  39.116 ms  50.442 ms  46.770 ms
 7  188.31.255.161.threembb.co.uk (188.31.255.161)  47.963 ms  52.674 ms  47.617 ms
 8  188.31.255.126.threembb.co.uk (188.31.255.126)  52.529 ms  47.936 ms  40.104 ms
 9  188.31.255.157.threembb.co.uk (188.31.255.157)  51.766 ms  47.328 ms  47.880 ms
10  188.31.255.170.threembb.co.uk (188.31.255.170)  51.930 ms  51.522 ms  47.873 ms
11  195.66.237.175  51.970 ms  61.656 ms  52.034 ms
12  * * *
13  * * *
14  52.94.35.92  56.130 ms  66.108 ms  54.347 ms
15  52.94.33.185  47.736 ms  54.679 ms  59.655 ms
16  52.94.33.48  60.349 ms  59.425 ms  59.818 ms
17  * * *
18  * * *
19  * * *
20  ec2-52-56-123-246.eu-west-2.compute.amazonaws.com (52.56.123.246) [open]  47.924 ms  41.583 ms  45.531 ms


~$ sudo tcptraceroute api.healthera.co.uk 443
Selected device en0, address 172.20.10.5, port 55241 for outgoing packets
Tracing the path to api.healthera.co.uk (52.56.123.246) on TCP port 443 (https), 30 hops max
 1  172.20.10.1  3.697 ms  3.892 ms  5.801 ms
 2  * * *
 3  172.23.128.201  55.388 ms  42.007 ms  48.522 ms
 4  * * *
 5  188.31.253.50.threembb.co.uk (188.31.253.50)  49.337 ms  51.717 ms  39.670 ms
 6  188.31.255.77.threembb.co.uk (188.31.255.77)  52.875 ms  40.477 ms  43.492 ms
 7  188.31.255.166.threembb.co.uk (188.31.255.166)  40.851 ms  50.530 ms  48.073 ms
 8  188.31.255.117.threembb.co.uk (188.31.255.117)  116.008 ms  35.044 ms  47.981 ms
 9  188.31.255.154.threembb.co.uk (188.31.255.154)  56.149 ms  45.818 ms  52.129 ms
10  188.31.255.170.threembb.co.uk (188.31.255.170)  51.710 ms  46.975 ms  51.461 ms
11  195.66.237.175  48.861 ms  58.403 ms  58.259 ms
12  * * *
13  * * *
14  52.94.35.104  58.779 ms  44.056 ms  58.556 ms
15  52.94.33.189  416.028 ms  50.189 ms  51.591 ms
16  52.94.33.48  47.965 ms  52.498 ms  58.664 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
Destination not reached

Working network

~$ tcptraceroute api.healthera.co.uk 443
Selected device eth0, address 192.168.8.12, port 39878 for outgoing packets
Tracing the path to api.healthera.co.uk (52.56.65.26) on TCP port 443 (https), 30 hops max
 1  192.168.8.1  1.382 ms  0.690 ms  0.594 ms
 2  host90-152-126-145.ipv4.regusnet.com (90.152.126.145)  0.475 ms  0.580 ms  0.547 ms
 3  ga013c-the-count.access.colt.net (195.110.85.97)  9.519 ms  9.311 ms  9.240 ms
 4  ir3.fra.router.colt.net (212.74.76.181)  12.805 ms  9.735 ms  9.912 ms
 5  195.66.237.175  10.861 ms  10.541 ms  25.791 ms
 6  * * *
 7  * * *
 8  52.94.35.88  18.515 ms  20.163 ms  18.888 ms
 9  52.94.33.201  12.063 ms  11.593 ms  11.549 ms
10  52.94.33.78  12.014 ms  12.839 ms  11.568 ms
11  * * *
12  * * *
13  * * *
14  ec2-52-56-65-26.eu-west-2.compute.amazonaws.com (52.56.65.26) [open]  11.491 ms  12.290 ms  12.069 ms


~$ tcptraceroute api.healthera.co.uk 80
Selected device eth0, address 192.168.8.12, port 36500 for outgoing packets
Tracing the path to api.healthera.co.uk (52.56.123.246) on TCP port 80 (http), 30 hops max
 1  192.168.8.1  1.390 ms  0.581 ms  0.594 ms
 2  host90-152-126-145.ipv4.regusnet.com (90.152.126.145)  0.398 ms  0.404 ms  0.356 ms
 3  ga013c-the-count.access.colt.net (195.110.85.97)  9.241 ms  19.771 ms  9.237 ms
 4  xe0-0-7-pr2.lon.router.colt.net (212.74.72.117)  9.592 ms  10.360 ms  9.498 ms
 5  195.66.237.175  10.776 ms  10.595 ms  10.505 ms
 6  * * *
 7  * * *
 8  52.94.35.80  16.369 ms  27.377 ms  13.743 ms
 9  52.94.33.183  11.516 ms  10.957 ms  10.937 ms
10  52.94.33.52  10.903 ms  11.148 ms  11.598 ms
11  * * *
12  * * *
13  * * *
14  ec2-52-56-123-246.eu-west-2.compute.amazonaws.com (52.56.123.246) [open]  14.278 ms  13.619 ms  12.170 ms


~$ dig api.healthera.co.uk +trace
; <<>> DiG 9.9.5-3ubuntu0.15-Ubuntu <<>> api.healthera.co.uk +trace
;; global options: +cmd
.           3600    IN  NS  b.root-servers.net.
.           3600    IN  NS  c.root-servers.net.
.           3600    IN  NS  d.root-servers.net.
.           3600    IN  NS  e.root-servers.net.
.           3600    IN  NS  f.root-servers.net.
.           3600    IN  NS  g.root-servers.net.
.           3600    IN  NS  h.root-servers.net.
.           3600    IN  NS  i.root-servers.net.
.           3600    IN  NS  j.root-servers.net.
.           3600    IN  NS  k.root-servers.net.
.           3600    IN  NS  l.root-servers.net.
.           3600    IN  NS  m.root-servers.net.
.           3600    IN  NS  a.root-servers.net.
;; Received 460 bytes from 127.0.1.1#53(127.0.1.1) in 463 ms
uk.         172800  IN  NS  nsa.nic.uk.
uk.         172800  IN  NS  nsb.nic.uk.
uk.         172800  IN  NS  nsc.nic.uk.
uk.         172800  IN  NS  nsd.nic.uk.
uk.         172800  IN  NS  dns1.nic.uk.
uk.         172800  IN  NS  dns2.nic.uk.
uk.         172800  IN  NS  dns3.nic.uk.
uk.         172800  IN  NS  dns4.nic.uk.
uk.         86400   IN  DS  43876 8 2 A107ED2AC1BD14D924173BC7E827A1153582072394F9272BA37E2353 BC659603
uk.         86400   IN  RRSIG   DS 8 1 86400 20171004170000 20170921160000 15768 . ZKjCYbJffsP8fYzMOeeYFj4+w+bE12NTYgD0zM98ppT4ZbkS/nzESoIA bJ35XHTWBR1aZlsDlDE8ynIiy3Tp0xN6NvXrIE5iYwitwvR8RCOKyBZk R9eopH/6h5ZX0DhfgaQdgIhtdmokr63ZYfU+oFxdBJ9fa7NihVVRAdJ4 9/Y9UM0sxhUf6usgdg3iagY7iCYSz3XLZD0vk8i7F2fls+dweGTv7IZT cr/EHD7riuMiq82KPjhYmuJJVf2Y1AABZpD7Tl1p5K7lUkBDc9pgtMs9 j4eYeuoBr4GqW8C3bGnVF5fyJAqFYP+wCjvcLP4BbOwCAvafrwyWezuU ajpHcg==
;; Received 803 bytes from 193.0.14.129#53(k.root-servers.net) in 304 ms
healthera.co.uk.    172800  IN  NS  ns-1098.awsdns-09.org.
healthera.co.uk.    172800  IN  NS  ns-704.awsdns-24.net.
healthera.co.uk.    172800  IN  NS  ns-251.awsdns-31.com.
healthera.co.uk.    172800  IN  NS  ns-1976.awsdns-55.co.uk.
G9F1KIIHM8M9VHJK7LRVETBQCEOGJIQP.co.uk. 10800 IN NSEC3 1 1 0 - G9HKV8PHGJ1NMH94L9RMIQM0J64UCIPK NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534
G9F1KIIHM8M9VHJK7LRVETBQCEOGJIQP.co.uk. 10800 IN RRSIG NSEC3 8 3 10800 20171027064114 20170922060233 33621 co.uk. olk2vORgfr0jK+4kQpMcrvcvpB66fnaci6fE2+gHuDGUSgZu+IVUwCIO LLRV3UNu7fVJtc9gHUc2u2pSHBjBzqYIJ9g5ltHyUzQjQ0u1jdFUJs46 f8ay+aKDI4lydiGR+guCsweqjDlo7glFsIujf3h8HV2IaWNH5Cc6l/vN StQ=
5LKTI0UUB0BVT731FML5I9G32RGVK6B0.co.uk. 10800 IN NSEC3 1 1 0 - 5LM4S3GU530RJOS0G7PK5K90UEDRP3AP NS DS RRSIG
5LKTI0UUB0BVT731FML5I9G32RGVK6B0.co.uk. 10800 IN RRSIG NSEC3 8 3 10800 20171027091222 20170922081222 33621 co.uk. rRjUh0kmlq+IiXlxdHOqJzSChhtyMGiawzSsHsdOAJvb0N7EJqMd5RwZ pCcVpY79BPiY+GCmDZR974FP7kleDkh5laGXKKwDfeO1BDnQNXBT3Ldx YJseNQYwSGAT2QeyLAtQltYmRBup1mn6pUcekRAQQgrzjM6rjXMkG7/B L9U=
;; Received 706 bytes from 156.154.103.3#53(nsd.nic.uk) in 188 ms
api.healthera.co.uk.    60  IN  A   52.56.123.246
api.healthera.co.uk.    60  IN  A   52.56.65.26
healthera.co.uk.    900 IN  NS  ns-1098.awsdns-09.org.
healthera.co.uk.    900 IN  NS  ns-1976.awsdns-55.co.uk.
healthera.co.uk.    900 IN  NS  ns-251.awsdns-31.com.
healthera.co.uk.    900 IN  NS  ns-704.awsdns-24.net.
;; Received 215 bytes from 205.251.192.251#53(ns-251.awsdns-31.com) in 331 ms

UPDATE 2

Another interesting thing is that it seems that port 443 is blocked when we are on the 'broken' network:

~$ nmap -p 443 api.healthera.co.uk

Starting Nmap 7.60 ( https://nmap.org ) at 2017-09-22 12:07 BST
Nmap scan report for api.healthera.co.uk (52.56.123.246)
Host is up (0.064s latency).
Other addresses for api.healthera.co.uk (not scanned): 52.56.65.26
rDNS record for 52.56.123.246: ec2-52-56-123-246.eu-west-2.compute.amazonaws.com

PORT    STATE    SERVICE
443/tcp filtered https

Nmap done: 1 IP address (1 host up) scanned in 0.76 seconds
~$ nmap -p 80 api.healthera.co.uk

Starting Nmap 7.60 ( https://nmap.org ) at 2017-09-22 12:07 BST
Nmap scan report for api.healthera.co.uk (52.56.123.246)
Host is up (0.077s latency).
Other addresses for api.healthera.co.uk (not scanned): 52.56.65.26
rDNS record for 52.56.123.246: ec2-52-56-123-246.eu-west-2.compute.amazonaws.com

PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds

Instead on networks that are working properly port 443 seems open

$ nmap -p 80 api.healthera.co.uk

Starting Nmap 7.01 ( https://nmap.org ) at 2017-09-22 12:11 BST
Nmap scan report for api.healthera.co.uk (52.56.123.246)
Host is up (0.011s latency).
Other addresses for api.healthera.co.uk (not scanned): 52.56.65.26
rDNS record for 52.56.123.246: ec2-52-56-123-246.eu-west-2.compute.amazonaws.com
PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
$ nmap -p 443 api.healthera.co.uk

Starting Nmap 7.01 ( https://nmap.org ) at 2017-09-22 12:11 BST
Nmap scan report for api.healthera.co.uk (52.56.65.26)
Host is up (0.013s latency).
Other addresses for api.healthera.co.uk (not scanned): 52.56.123.246
rDNS record for 52.56.65.26: ec2-52-56-65-26.eu-west-2.compute.amazonaws.com
PORT    STATE SERVICE
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
Stavros Zavrakas
  • 53
  • 1
  • 10
  • 2
    Can't really help if you don't tell us what the website is. Are you sure you're using a GoDaddy SSL Certificate with ELB? I thought custom SSL certificates cost $600 per month. You can use SNI almost for free. – Tim Sep 20 '17 at 09:00
  • 2
    @Tim SSL certificates costs between $5/year and $5000 year. I want to know what kind of error message stavros is seeing, with that it could be anything – Orphans Sep 20 '17 at 10:06
  • @Tim I have no idea what is the custom SSL certificate. Is it like a wildcard SSL certificate? I am not sure about the cost but I can ask it. This allows us to configure multiple ELBs by using the same certificate. The domain name is healthera.co.uk – Stavros Zavrakas Sep 20 '17 at 10:12
  • @Orphans Unfortunately I can't see any error coming back, at some point the request just times out. It is quite difficult to reproduce it as well, as soon as you switch on and off the data it's coming back to normal. – Stavros Zavrakas Sep 20 '17 at 10:12
  • 1
    @Tim I believe you're thinking of SNI-incapable client support on CloudFront. ELB doesn't need SNI support from clients, so doesn't have such a feature. This sounds like a UCC/SAN cert, definitely supported on ELB. – Michael - sqlbot Sep 20 '17 at 12:52
  • @Michael-sqlbot I'm not sure if I understood everything in your discussion. Is the UCC/SAN cert the same like a wildcard certificate? – Stavros Zavrakas Sep 20 '17 at 16:14
  • 1
    The cert on your "api" domain is a wildcard. It seems fine. Your redirect on http requests to that domain is malformed, showing two trailing slashes `//` at the end of the `Location:` header instead of just one. The "auth" site uses the same cert but does not work on port 80 at all, so https must be typed manually, for access. Your admin site seems firewalled or misconfigured. Hard to say exactly which of these things you are trying to trobleshoot. – Michael - sqlbot Sep 20 '17 at 17:17
  • @Michael-sqlbot - you are right about everything above. The redirection on the api is malformed because we've added it quite fast just to check if the http works, we are planning to remove it and close completely port 80. This is why you have to type https on the auth server (we don't do redirection at all) and you are right about the admin, it is behind vpn (and we block port 80 in any case). – Stavros Zavrakas Sep 20 '17 at 21:45
  • Are sure it's about the certificate because you're trying to tcp traceroute your https port on your server and it fails. Is it then not a layer 4 problem or maybe a layer 3 problem? Because tcp traceroute just checks for the tcp handshake and thats layer 4. – almdandi Sep 22 '17 at 10:58
  • @almdandi Probably you are right, but still we are trying to figure out what is exactly the problem. It can't be DNS because we are not even able to access the api with the IP. It seems now that is not SSL issue. For a reason on this broken network the port 443 is filter and that's the reason that we can not access on SSL. Can this be internal AWS issue? – Stavros Zavrakas Sep 22 '17 at 11:16
  • In both traceroutes the last visible node ip address is owned by amazon. So maybe it's a problem in AWS. Can the devices call other https pages? – almdandi Sep 22 '17 at 11:29
  • @almdandi - yes this device by using this network can access the most of the major websites (google, facebook, stackoverflow etc) by using SSL. Is it possible that three network is modifying something in the packets before reaching amazon network? – Stavros Zavrakas Sep 22 '17 at 11:37
  • It's really hard to say. It's also very strange. Why should they block https? There's no reason to do that. Maybe a guess. Often ISP hand out their mobile users only a private ip address and put all of them bebind a carrier NAT. So many devices/users share the same public ip address and could trigger rate limiters. But this is really only a guess. I would recommend you to contact to AWS support and to send them all your information you got (traceroute, nmap scans, your public ip address). – almdandi Sep 22 '17 at 12:07
  • @almdandi - we've contacted AWS support, let's see what is the result :) What worries me a bit is if there is a possibility that they forward the traffic to different boxes or ELBs. Doing a full nmap scan against the api subdomain we could see that FTP port 21 is open and definitely this is not the case. Port 21 is blocked in our side through the security groups and actually it is blocked if you do an nmap through a network that does not have any issues. – Stavros Zavrakas Sep 22 '17 at 12:56
  • If your client is tunnelled through VPN, you must make sure that the https port is part of your encryption domain (some VPN aggregators leave https outside of the tunnel) – Marcel Sep 22 '17 at 14:16
  • @Marcel - there is just one platform that is private and is behind vpn and we don't really care if this works on this specific network. The api is not behind vpn. – Stavros Zavrakas Sep 22 '17 at 16:49

4 Answers4

2

Problem solved, it was so stupid - at least I've learned something more about network layers, ssl certificates and firewalls.

So the problem was:

VPC - Network ACL - Inbound Rules and then deny a whole ip subrange just for the port 443.

Sorry for wasting your time and thanks for your really useful input.

Stavros Zavrakas
  • 53
  • 1
  • 10
  • general rule - if ping works and tcp connection doesn't - it's firewall. Also if ping works and telnet on a port returns `destination unreachable` or similar - again it's firewall with `reject-with-icmp-unreachable`. In your case it was clearly seen the rule was set to `REJECT`. Nmap output showing the port as `filtered` prooves that, good practice says to `DROP` packets and then your nmap wouldn't show that port. – bocian85 Sep 28 '17 at 12:49
1

I work for a major SSL Certificate authority, and my experience has generally been that in these cases the issue is that the browser/keystore on the mobile device in question is out of date. Odds are that this device is not on the latest version of Android or iOS and newly published root certificate authorities are not trusted by this client.

Often in these cases, a root certificate authority has published a new signing certificate or they are an altogether new certificate authority and they will sign their new signing certificate with their old certificate or get their certificate signed by an existing (and competing) certificate authority.

In the case of a an existing signing authority (for example) this could come about because they are raising their encryption level - for instance if they used to sign certificates with a 1024 bit signing certificate and have now gone to 2048 bits. If the operating system of the mobile device you are working with was compiled and released before the 2048 bit certificate was published, it does not have the new certificate in it's bundle of known and trusted roots. You need a way to signal to the OS that it should trust the new root signing authority.

This then, is the role of an intermediary or chain certificate. By including a chain certificate, you should be able to use a certificate the legacy device already trusts to indicate the new certificate it doesn't yet know about can also be trusted to verify SSL. If you can provide some specifics about the CA that has signed your certificate and the version of mobile device you are working with, more detailed answers can probably be provided here for you, but as a general overview, this is the most likely problem.

James Shewey
  • 182
  • 14
  • If there were a problem with the cert this would a possibility to consider, but nmap getting no response from the port (filtered) cannot be caused by even the most awful truststore. FYI by looking at the site you can see the cert is under [GoDaddy RCA2 which is RSA2048+sha256 in 2009](https://crt.sh/?id=548406) (ahead of the first NIST schedule) although one could use https://crt.sh/?id=3264952 to bridge back to https://crt.sh/?id=39 from 2004 (also RSA2048 but sha1 but that doesn't matter in a root). – dave_thompson_085 Sep 23 '17 at 06:08
  • When nmap is actually blocked, it shows closed, not filtered - or simply does not list the port. The OP is also not clear on if the site fails a TCP connection or shows a cert error. – James Shewey Sep 23 '17 at 08:00
  • [The authors of nmap disagree with you:](https://nmap.org/book/man.html) "Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed" [and in more detail](https://nmap.org/book/man-port-scanning-basics.html) "closed ... port is accessible ... but there is no application listening on it" which we know to be untrue because the OP reports other clients successfully connecting. – dave_thompson_085 Sep 24 '17 at 02:34
  • So, then it may very well be open, but there are no ICMP notifications confirming... *Nmap cannot tell whether it is open or closed* – James Shewey Sep 24 '17 at 02:55
  • @JamesShewey - Is there an explanation why I can see the port 21 as open on the broken network? This port definitely is not open and doing an nmap using a network that is not broken you can see that this port is filtered. Are there any other tools that I can use to debug? – Stavros Zavrakas Sep 25 '17 at 08:47
  • Lots of things can cause that port to show filtered: Layer 7 firewall, a proxy on 443, a firewall configured to block specific replies. Why don't you rule out the network? Have the "specific guy" try wifi. If it works over wifi, call his carrier and ask them to get it fixed. If it doesn't work, you likely have certificate issues. – James Shewey Sep 25 '17 at 15:21
1

You can use tcptraceroute to guess where port 443 is blocked.

tcptraceroute 52.56.123.246 443

should give you the ip adress of the firewall which is blocking requests to port 443

bgtvfr
  • 1,262
  • 10
  • 20
0

test your ssl at https://www.ssllabs.com/ssltest/ make sure you get an "A" if not then there is something wrong with the certificate. most likely need 2048 bit encryption. really though your not with the best of hosting companies. I recommend digital ocean.

Hope this helps

SEO DEVS
  • 9
  • 4