HTTPS clients can take many forms e.g. web browsers talking to a web server, or a web service consumer talking to a web service, or a service running on a server talking to an application running on the server. When an HTTPS connection is established, the SSL design includes a “handshake” in which the client asks the server to identify itself. If the server is configured for two-way SSL, this means that the server will also ask the client to identify itself. To establish identify, the entity (server and optionally client) sends its identity certificate. The recipient of the certificate (e.g. the client in one-way SSL, or both the client and the server in two-way SSL) examines the certificate for a number of validating factors.
The design of SSL is based on a third party trust hierarchy, in which there are a number of certifying authorities (CAs) such as Verisign, that are responsible for issuing certificates. They do this by validating that the party purchasing the certificate is who they say they are. The CA creates a certificate for the party, and signs the party’s certificate with their CA certificate — this creates a mathematical relationship between the two certificates.
The last bit of this is the trust store, which is a collection of CA certificate signatures that can be used to mathematically validate any certificate as being signed by a CA. Major browsers, operating systems, and virtual environments (e.g. Java) ship with preconfigured trust stores that includes the certificate signatures for all the major CAs. For example, Firefox, IE, Windows, macOS, iOS, JREs, JDKs, and the like all have trust stores that ship with their software. WebLogic also includes a demo trust store (as WebLogic is based on Java) that is used to set up and test SSL connections. The trust store is configurable so administrators can add more CA certificates as needed (which I’ll describe later).
Back to the SSL handshake: when the client connects to a server via HTTPS, the client asks the server to present its identity certificate. The server sends its identity certificate to the client, and the client validates the certificate using its trust store. The validation process is basically described as "check that the certificate has been signed by a CA whose signature is present in the client’s trust store”. In the case of two-way SSL, the client would check that the server’s identity certificate has been signed by a CA whose signature is present in the client’s trust store, and the server will check that the client’s identity certificate has been signed by a CA whose signature is present in the server’s trust store.
Obtaining certificates and maintaining them is a non-trivial process that involves time and expense, so many entities will use self-signed certificates for non-production environments — but you may already perceive a problem (besides the fact that this nullifies third party trust): an entity that creates a certifying authority (CA) service will not have its CA signature present in any client trust stores, so each client must be configured with the entity’s CA signature. Note that this procedure is generally not used for production environments that are public-facing since entities do not have control over their service consumer’s trust stores.
There is also an additional complexity to consider with respect to certificates and that is that they are generally tied to a specific domain or host name, e.g. “www.oracle.com”, but you can also obtain certificates that use wildcards e.g. “*.oracle.com” could be used to secure servers identified by jms.oracle.com or www.oracle.com (but not super.secure.oracle.com as that would be a different pattern — *.*.oracle.com).
The short version of all of the above is that every unique service and/or server that provides an HTTPS connection must be configured with an identity certificate that has been signed by a CA whose root CA signature is present in every expected client’s trust store. It is possible that a wildcard certificate can be used across multiple servers depending on how the servers/clients are configured – for example, if ABC Company obtains a certificate for *.abccompany.com, then that certificate could be used as the identity certificate for any of the services it provides – even if there are load balancers, clusters, and redundant sites.
In summary, every item that provides a secured connection will require an identity certificate — TLS, SSL, HTTPS, and T3S are all covered by this requirement. It is up to the customer’s IT group to determine if a wildcard certificate is necessary or desirable.