0

One of our internal apps are reachable via following, example domain name address:

https://some-addres.some-domain:8443

For all following cases:

We are ending up in correct, SSL-ed application page. However, when we try to reach it via IP address (let's assume 1.2.3.4) following happens:

I'm not a sysDamin, and basically I have no access to any configuration of this particular instance, I'm just curious, how it is possible, that Domain name and IP address that ultimately at the end are same thing can behave in such different way? Does it depend on server configuration or this is part of RFC/Some other spec?

Thank you for help!

1 Answer 1

4

You do have a SSL/TLS connection – if the client is trying to speak TLS, the server cannot simply return a non-TLS response, it must either respond with TLS or terminate the connection. You simply don't have successful verification that you're connecting to the correct server.

  • Servers in TLS are identified by a certificate, which must match the URL that you tried to access – the certificate is only valid for those names for which it was originally issued, and does not automatically become valid for the corresponding IP addresses or any other variation.

    For example, when you try to access https://1.2.3.4:8443, the certificate must explicitly list the iPAddress 1.2.3.4 among its subjectAltNames. In your case, most likely it doesn't list the IP address, only the full domain name.

    See RFC 2818 section 3.1 "Server identity":

    In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.

    [...] In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.

  • In addition to that, TLS clients tell the server what address you tried to access, and servers can return different certificates based on that. (For example, when configuring an HTTPS site in Apache or Nginx, each <VirtualHost> can have a different SSLCertificateFile parameter – so it could use a single certificate with 5 domains in it, or it could use 5 individual certificates for one domain each.)

    So it could also be that when accessing https://1.2.3.4:8443 you are hitting a virtualhost that doesn't have the certificate properly configured at all (e.g. it could be using the default dummy cert).

1
  • Thank you for fantastic answer, all clear now.
    – Tomas
    Jan 17, 2020 at 8:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .