How to bind website and its SSL version using the same port

Question

I have hosted my site on TCP port 91.

Is there a way to bind their SSL certificate on that same port 91?

Answer 1

I have hosted my site on TCP port 91. Is there a way to bind their SSL certificate on that same port 91?

I'm interpreting this question as "I'm running my site on http://www.mysite.example:91/ and I also want to run it for HTTPS at https://www.mysite.example:91/" (in which case it's not a duplicate of Multiple SSL domains on the same IP address and same port?, as temporarily marked).

This can be done using Port Unification, which is supported by Grizzly for example (a Java web server). (Your question doesn't say which server you want to use.)

Port unification can work for any protocol where the client is expected to talk first (for example HTTP, SSL/TLS, but not IMAP, ...).

Essentially, the server tries to detect which protocol is used by looking at the beginning of the request before dispatching it. If it receives GET / ... it can assume it's an HTTP request. If it receives a ClientHello, it can assume it's an SSL/TLS request (which may then be redirected to the appropriate protocol of top of it, if needed, in this case HTTP over TLS).

Support for this feature is quite unusual, but it works. However, you will have to specify the port explicitly in your URL if it's not the default (80 will always be the default for http:// and 443 will always be the default for https://).

I'm not aware of this feature being implemented in Apache Httpd, but that's not in principle a problem. Other answers mention that two services (or two processes) can't listen on the same port. That's true, but nothing prevents the same server/process to be able to handle multiple sites (Apache Httpd does it very well when the same process listens to multiple ports, e.g. 80 and 443, and does the VirtualHost dispatch in the back).

Coming back to the "possible duplicate question", another solution might have been to use RFC 2817, as mentioned in this answer. Unfortunately, although this answer mentions this RFC, the logs it shows indicate that curl there was not plain HTTP traffic before the SSL/TLS traffic, which would indicate it was using Server Name Indication (SNI) and not RFC 2817. In addition, I'm not aware of any implementation of RFC 2817, whereas curl already had support for SNI at the time of that answer.

Supporting RFC 2817 is much more involved than supporting port unification, since it requires support on both the client and server sides, including the ability to upgrade in the middle of the protocol. (It's not the end of the world, SMTP, LDAP and others can do this, but it's already widely supported for these protocols.)

In contrast, port unification only requires changing the initial dispatch mechanism on the server side. By just specifying the port explicitly in the URL, any browser will support it on the client side.

Answer 2

It doesn't work. You can only bind one service per port.

Answer 3

Two services can't listen on the same port on the same system using TCP. You can use NAT and route traffic from different locations to different internal addresses on the same port, but an external IP couldn't use both services on the same port.

Answer 4

When a user agent or a client initiates a HTTPS request it uses the default port which is 443. The default port for HTTP is 80.

If your server is listening on another port (91), then you need to forward port 443 to this port, so when someone types https://www.example.com/, it will point to the server listening on port 91.

You cannot have http://www.example.com/ and https://www.example.com/ running on the same port, since only one process may listen on a port. You can have them listening on the same server, if the server has multiple IP addresses.

If your server will only have the https site then forwarding 443 to 91 and switching your server to HTTPS will work.