I'm running an IIS server. I have used WinACME to create an SSL certificate for domain.com:443. I need to set up another service on a different port (already done and running) that uses the same domain (domain.com). However, the service must use an SSL certificate and the service runs on port 55459 (domain.com:55459). In IIS, can I just add an additional binding and for the domain.com:55459 and use the existing SSL cert already assigned to domain.com:443?
If this is okay, will the certificate auto-renew? It's already auto-renewing for port 443 so I assume if the same cert is bound to 55459, it will auto-renew as well.
If this is not okay; would someone please explain why this cannot be done and how I could use WinACME (or other method) and LetsEncrypt to get another certificate bound to port 55459?
Thank you so much for your quick reply! Do you think my method of doing this via IIS > Website > Bindings > Add is sufficient, or should I figure out how to do this with WinACME? My apologies, I'm quite new to IIS.
Yes, if you manually create the (https) port binding the app will auto update the previous usage of the certificate when renewing, retaining the port. win-acme
Note that the convention (on IIS and pretty much everything else) is to stick to port 443 for https and use different hostnames pointing to the same server, with SNI (server name indication) used to differentiate.
So on IIS you would setup your web application as a new Site (IIS can handle thousands of sites), then in your site bindings setup the http binding hostname to a name for your server that will resolve in DNS to your server IP e.g. api.example.com.
When win-acme or any other windows based tool creates the certificate binding it will add an SNI enabled binding with the same hostname set. To do the same manually you would create a new https binding, set the hostname and enable SNI, with IP address set to (All Unassigned).
As an aside, note that setting specific IP addresses in https bindings overrides all SNI for that IP and as most hosts only have one real IP then the machine is forced to serve the first cert that binds to that IP that IP+port, which is usually not what you want.
While you can put an SSL Certificate on any port, most users prefer to terminate SSL on a gateway server and proxy a HTTP connection to internal applications/servers running on higher ports. A big reason for this is that clients (browsers, apps, etc) often have a hard time handling SSL on ports other than 443.
You can certainly install your certificate on any port, but that generally brings up a lot of compatibility issues. Some services/protocols that run on higher ports are typically configured to run SSL as a server and expect SSL as a client, so those are unaffected. If you're doing anything with HTTP/HTTPS though, it's often best to keep SSL on port 443 and segment by hostname, then proxy the connection to the backend.