SSL certificate for a web-service running on a non-standard port on multiple domains

Question

I have a legacy internal corporate web-service which is not running on the standard HTTP\HTTPS ports. In addition, it consists of multiple sub-services. Meaning, the web-interface calls REST functions through HTTP calls and these functions are located on different domains, some are even called from an IP-address:port.

The problem I'm having with this now is that modern browsers constantly complain about the lack of verified SSL certificates for any of the above.

I want to finally sign all of this mess somehow so that Google Chrome and Firefox would stop blocking it and complaining about the security. However, because of this architecture, I'm not sure which certificate I should get. Maybe even multiple certificates.

Specifically, my questions are:

1. Does the fact that the web-inteface isn't running on a standard HTTPS port has any significance to the type of the certificate or its issuer?

2. Since parts of the web-application are called from different domains, I guess I need a Multi-Domain SSL Certificate, right? What if I sign every service with its own certificate?

3. REST APIs that are exposed without a domain assigned, meaning they are called directly from a specific IP. Do I understand it correctly when thinking that I'll have to get a domain for those and issue a certificate for the domain? Like, there is no way to get a proper certificate from a trusted authority for an IP address? I understand it's a terrible thing to even consider but this specific part is an old, barely maintainable Tomcat server, that I really don't want to touch.

Solution

If you control the endpoints, you can deploy a certificate authority to devices. Might be your own if you want to run a PKI. The only thing "proper" about public issued certs is that they are rooted in commonly trusted CAs.

TLS does not care about the port. It is an application in any stream of bytes. Consistently using ports like 443 for https is for user convenience. Why make them type something like :8443 when you can reverse proxy from 443 to the actual backend? Makes firewall rules and packet capture easier as well.

It is your decision regarding how many certificates are necessary.

• One cert per service is fine. Make your cert issuing processes easy enough where this is feasible.
• Subject Alternative Name (SAN) allows several different names on one cert. Such as multiple virtual hosts for one web server instance.
• A wildcard certificate such for *.example.com is useful but also dangerous. If it leaks out anyone can pretend to have your cert under any matching name, like evil.example.com. RFC6125 discourages its use, but acknowledges it is still around.

Really should have a name for every service, DNS is not optional these days and makes things possible.

You can put IP addresses in SANs, a well known example being https://1.1.1.1/. However, it is not commonly used, and not easy to get with your typical DNS based certificate provider. While a browser might accept an IP address in a SAN, some other user agent might not. Just give it a name and issue the cert in that name.

---

Start by making new apps all TLS encrypted. Internal and external, sensitive data and less so. Easier to practice PKI and services oriented design in a new clean environment.