So quite a few applications stay far from the security components. They do not check the authentication, so they do not know who they are talking to. Then they can also not authorize anyone to perform certain actions of their service.
PKI at best tells you who you are talking to (and that can be done confidentially): authentication. That by itself is useless if you then not also make a deliberate decision whether you want to do business with that client or service, and if so, what you want to share and what it can or can not do on your system / with your service / with your data: authorization. PKI can not handle that (but see Note 2). A lot of people appear to not understand this. If you contact them with any certificate, you are welcome and you can do anything. And as we saw above, it is likely that a number of choices have been made beforehand that compromise the security of even authentication.
It is even a design model: a trust zone. An internal CA issues certificates to services that communicate across the Intranet over HTTPS or another TLS protocol. There is only a check at PKI level that you have a certificate issued by a trusted CA: then it's "one of us", and among us everyone is allowed anything. I have seen situations where every host uses the same certificate, which just works in such a construction.
Of course, in this age of outsourcing and cloud services, someone will have to talk to an external party.
That must be done securely, so everything has to go over TLS. But that third party uses a certificate from another, public CA. And such an external commercial service really can not use a certificate signed by your private CA. So you have to also put the public root CA certificate into all your truststores. Of course, doesn’t everybody do that with well-known CAs? MS-Windows comes with a full list of root CA certificates preinstalled too, so that MS-Edge can speak HTTPS with all banks and webshops. That only makes things safer.
Right?
Well, then suddenly everyone who has a certificate from that CA gets into your trust zone. And such a public CA loves to sell a certificate to anyone who wants it. Also to werobyourbank.ru .
But such a certificate from a CA that everyone uses can be trusted, can it not?
Yes, for a certain degree of authentication. It is up to the recipient to decide if he wishes to grant authorizations. And a certificate is certainly not a Statement of Good Behavior. But a lot of people seem to think it is.
Not every "leaf" certificate (for the end user) is signed by a Root CA. Often there is a chain of 1 or more Intermediate CAs. One reason may be that for security, one does not want to put the Root CA onto the network at all: then a cumbersome manual procedure is required to get CSRs on and certificates from the system, so this is only done for subordinated CAs which then issue the "leaf" certificates. Or one wants to distinguish sub-domains using separate Intermediate CAs. This will be a nuisance after a reorganization, or worse, if a department is sold: forever certificates will remain in circulation for which you remain the responsible Root CA, but you are no longer in control of their issue. It seems better to use multiple independent Root CAs that issue leaf certificates directly.
The TLS protocol also has the option that a service that is called by a client, can request the client to also send its own certificate to identify itself: Mutual Authentication (TLS-MA). That will only be useful if the server then looks into the client certificate, reads the identity, and decides if it will authorize that client to use its services. If the server only does a technical check whether the client certificate has been signed by some CA that it has in its truststore, then Mutual Authentication will add nothing to security. For confidentiality the single server certificate is sufficient. With mutual authentication, at the least on the server side there has to be some filtering on incoming clients: for the Apache web server this requires adding and configuring extra modules. This can also be delegated to a separate policy server, which follows rules (policies) to decide which authenticated users are authorized to do which things. TLS-MA is only done for communication between services in some multi-tier application chain, where the potential clients are known.
For browser-based access TLS-MA is unpractical: a huge number of unknown browsers may request the webservice. A browser typically does not have a client certificate, instead users must identify and authenticate themselves in some other way (e.g. username and password), and then authorization for access to the service is handled by some policy server. After all only the application can know about its data and which clients may access it; PKI security at the underlying network layer can not properly handle such authorization.