1

I'll start by saying that I am no expert on the setup of servers. Far from it.

I am setting up an Ubuntu server with Apache running on ports 8080 and 4433 because another service on the server is using ports 80 and 443. I have modified the hosts file, the hostname file, provided the proper path to the certificates and have worked it down where there are no errors or warnings in the Apache error logs where certificates are concerned.

On my internal network I can access the named server (on ports 80 and 443) with no issue. On my internal network I can access the IP (internal using 192.168.nnn.nnn, on ports 8080 and 4433) with no issue. On my internal network I cannot even ping the external IP (using 69.1.nnn.nnn - I get no results.

From outside of the network - I can access the named server (ports 80 / 443) with no issue. I cannot access the external IP (ports 80/ 443) without getting a distrusted certificate issue. Once I accept that there are issues with the cert it allows me proper access. I cannot access the external IP (ports 8080 / 4433) gateway timeout. I cannot access the external name server (ports 8080 / 4433) gateway timeout

I have been searching all day for a solution and I am willing to chalk it up to I have no idea what I am doing. Unfortunately I do not have anyone locally accessible (I've asked) who knows about this kind of thing.

From what I have written here is there anything obvious I have overlooked? Something in vhosts? Something the IT department has mis-configured in the firewall? I am at the end (and actually beyond - I learned some things) of my knowledge as this has gone beyond simple web server configuration.

Jay Blanchard
  • 117
  • 7
  • Something odd is going on - what's the trust issue that your browser is flagging with your certificate? The external IP won't ever work without some form of [hairpin](http://serverfault.com/questions/55611/loopback-to-forwarded-public-ip-address-from-local-network-hairpin-nat), but the different certificate behavior makes me think there's some kind of proxy behavior going on. – Shane Madden Jun 13 '14 at 21:45
  • That is what I was afraid of @ShaneMadden and our IT department (I am in R&D) is very stingy with details concerning proxies. We had to get them to open some ports and they stated that they did some things where the proxies were concerned as well. Perhaps it is time for a good, old-fashioned, come to an understanding meeting. – Jay Blanchard Jun 13 '14 at 21:48
  • 1
    That sounds like a good approach; at the very least, it seems that you will need some firewall changes made to get things working correctly. – Shane Madden Jun 13 '14 at 21:50

1 Answers1

1

The trust issue is actually an SSL certificate warning. The SSL certificate is bound to the name in the certificate, not the ip address of the server. What you're seeing when connecting to the ip address is perfectly normal and is the expected behavior. If it wasn't then we'd all be in a whole lot of trouble (akin to the Heartbleed bug). As for your connectivity problem, have you opened those ports in your network firewall to the server?

See these two screenshots. They're from the same web site. The first connection is to the ip address and the second connection is to the name that is bound to the SSL certificate. If you didn't get the warning as in the first screen shot then SSL would be completely useless.

enter image description here

enter image description here

joeqwerty
  • 108,377
  • 6
  • 80
  • 171