0

Apologies for what might seem like a naive question, but there is a detail to PKI architecture between clients and servers, the answer to which I have so far not been able to come across no matter where I search.

Please indulge me in the following scenario so that there is no ambiguity to what I mean by "client."

Suppose company A has an application on its intranet. This app is hosted on a web server, which its ten employees access from their work stations. Company B has a web service that company A would like to consume. Company B's service, however, requires both server and client certificates. Therefore company A will need to present a client X509 certificate when when making the TLS connection.

So an employee at company A thus accesses company B's service by making a request from their personal client to company A's server, which then makes a request to company B's service.

Here's the confusion: Once A's server makes the request to B's service, A's server is now a client from the point of view of B. So the question is, where does company A store its client certificate to use B's service? On A's server, or is there a copy on each individual client workstation at A? If the former, is it stored on A's web server or domain controller? If the latter, does each individual workstation download a copy from A's server?

I've seen a bit of X509 used in back end code to make a call to a REST service out on the internet, so I'm assuming the answer is "Company A stores its client certificate on its server." Maybe that's obvious to most people, but as someone new to networking I feel it's a valid question to ask given the inherent ambiguity in functional terms like "client" and "server."

Also, company A may have server certificates it uses to authenticate clients from some company C. Are A's server certificates stored in the same place it stores its client certificates. Can they be the same certificate?

Thanks for any clarification.

RTF
  • 103
  • 3

1 Answers1

1

You have to distinguish the certificate from the private key of the certificate. The certificate itself can be distributed anywhere. The certificate is akin to saying "This is who I am" and the private key is used to prove it.

To demonstrate this, look at the address bar of your browser. You will see the certificate for this website, and it'll state that it is issued to *.stackexchange.com. You can save this certificate, send it to friends and have it tattooed on your back (if you want that).

However, the certificate alone isn't enough to prove any identity. What proves the identity is possession of the private key, which is mathematically associated with the certificate. As you see in our example, you (probably) don't possess the private key to the certificate. Only the administrators of the Stack Exchange network do.

Likewise in your example, the employee at Alice Corp. possesses the private key. In order for the Server of Alice Corp. to make sure that the employee is who they claim to be, the employee has to prove that they are in possession of the private key. The simplest way to do it is to create something that only someone in possession of the private key could, like a message signed with the private key1. To make sure that the message is actually from the employee and not copied from someone else who actually possesses the private key, the server can pick a random message and ask it to be signed. If this is done, the server can be reasonably sure that the employee actually possesses the private key.

So how does it work then when the employee connects to the Server at Alice Corp., which then connects to the server at Bob Industries? A simple way would be for the server at Alice Corp. to act as a proxy. The Server at Bob Industries picks a random number and asks the server at Alice Corp. to sign it. The Alice Corp. Server then asks the employee to sign it, which they do. The signed number is then sent to the Server at Alice Corp., which then replies to the Server of Bob Industries. The private key never leaves the computer of the employee.

1 Of course, the actual details are different. This serves as an illustration, rather than as a technical document.

  • Thank you for your detailed answer. If "The private key never leaves the computer of the employee" does that mean that when company A wants to connect to company C's service, client certificates for every employee at A must be installed individually? I assumed that A's server would hold the client key and allow all employees at company A to use it, and, moreover, that authorization between employees at A and A's server would be handled solely by Active Directory at A, not client certificates/keys. – RTF Sep 05 '19 at 15:13
  • @ReturnToForever You put way too many different technologies all in one question. I can't make statements regarding your companies specific setup, only how client certificate authentication works in general. –  Sep 05 '19 at 15:16
  • I guess there are still some details I'm missing. I would've thought the server at C would hold what would be known as a server certificate to authenticate itself, while the server at A would require a *client* certificate to use C's service. (I'm assuming again that C's service requires both client and server certificates if that makes sense. Also, at this point I've reversed the roles of A and C from original question.) Thanks again. – RTF Sep 05 '19 at 15:17
  • The server at C needs their own server certificate, the matching private key, as well as a certificate authority, serving as a root of trust for all client certificates. The last is not 100% necessary, especially if there is some certificates are validated later. –  Sep 05 '19 at 15:19
  • Fair enough. The essence of the question I had in mind was "Isn't it ambiguous to talk of client certificates, when the client itself most likely consists of a client and a server?" – RTF Sep 05 '19 at 15:21
  • No, a client doesn't necessarily be a server too. And someone making a request for a client doesn't need to have their private key either. –  Sep 05 '19 at 15:22
  • Of course not necessarily, but in the many cases in which it *is*, there is at least a superficial ambiguity in what one means by the client. I was unclear on whether the clients at A need their own certificate, or whether the server at A does all the client certificate signing/encrypting *when* it is acting as a client with respect to some other server out there on the internet. – RTF Sep 05 '19 at 15:24
  • As stated in my answer, the server at A can act as a proxy for the employee (the actual client) and doesn't need a client certificate on their own. –  Sep 05 '19 at 15:25
  • Ok I get that. Last detail: how would a company normally install these client certificates on the individual machines when A is in the process of setting up its consumption of B's service. Surely, there's an easier way than going by each client machine. – RTF Sep 05 '19 at 15:27