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:
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?
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?
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.