There is also a problem with the identity for which a certificate is issued. As shown by the old RFC quote, all this is designed for an Internet where computer hosts talk to each other and identify themselves with their hostname. It was and is the default to put host names in the Common Name in the Subject of a certificate. So a 1-to-1 relationship between host and certificate has been assumed.
Now that has never been unambiguous. A host has a single hostname (e.g. gandalf was a popular host name) for which you can issue a certificate. On the Internet it has an IP address for which you could also issue a certificate. But a host can have multiple interfaces and therefore IP addresses – in the past 2 or more ethernet cards, nowadays virtually unlimited Virtual IP Addresses or IP Aliases: another certificate for each? The identity is not for the host as a whole. Furthermore, a host on the network receives from DNS a Fully Qualified Domain Name (e.g. gandalf.example.com), for which a certificate is required with appropriate Common Name in the Subject. But nowadays, countless DNS entries can refer to one and the same host - a host thus has multiple identities on the network and would require different certificates with different Common Names in the Subject. So in fact we have a many-to-1 relationship, and a single host certificate will not do.
Conversely, multiple different processes on the same host may require a certificate; e.g. a front-end web server reverse proxy, and a backend application that needs to identify itself to a database service. They typically run as different processes under different user accounts, may use different formats of keystores, so they cannot easily share one and the same host certificate; indeed since they have different purposes and maybe different security requirements, they shouldn't. If the hostname is required (in the Common Name field of the Subject), we have another many-to-1 relationship. The various applications can then distinguish themselves with other fields in the full Distinguished Name: the O (Organization) and multiple OU (Organizational Unit) fields. Then of course the Certification Authority has to support and validate those, and the applications need to filter and verify on them. But the "Common Name" of X509 certificates has been deprecated:
To solve these issues, early on one has introduced extensions like the Subject Alternative Names (SAN): a list of names for which the certificate is also valid; again see RFC2818: HTTP over TLS, section 3.1 on p.5. Since then (2000), the Common Name in the Subject has been deprecated by the IETF, but it has taken a long time before SANs became supported. e.g. only since Java 7 (2011), the standard keytool of Oracle / Sun supports SANs (See ref.[10]).
Also see RFC6125: Service Identity.
Nowadays, we mainly have web services that have URIs that lead through DNS to any host where the web application is listening (maybe through a reverse proxy web server) to port 80 (HTTP), 443 (HTTPS), or another port specifically configured for that application. Therefore, those URIs do not match the host name, which poses a problem with the certificate logic.
Worse, typically the URI leads to an IP alias on a Load Balancer (LB). In case that TLS is terminated on the LB a single appropriate certificate should be installed there; but otherwise if end-to end encryption is required, the LB passes on the encrypted requests to multiple hosts: so we have a 1-to-many relationship from a URI to the place where the certificates are used. It is a bad idea to try install the same certificate - with its private key - on multiple hosts: the mere fact that you can copy private keys means that they can be stolen, so security is breached. A workable solution is to issue certificates for each backend host with its own host name (FQDN) in the Subject, but put the shared DNS alias in a SAN field. But that will conflict with any other certificates that need to be issued for the host name, e.g. for another application with another URI running on the same hosts. A Certification Authority will typically refuse to issue another certificate for the same Common Name. Again different applications could distinguish themselves with O and OU fields in the Subject, or with SAN fields: but the CA needs to support that.
So the short story is that PKI, specifically X509 certificates, have been designed for a 1-to-1 relation between a Common Name and a physical host, but that is not tenable on todays complex Internet. One will have to design a different workable solution for different situations; there are some extensions that may be used to resolve the issues.