0

I realize the number of question about SSL certificates is legion, but after much searching I couldn't find a precise answer to the following confusion.

For one-way SSL, under what circumstances does the consumer of an HTTPS web service need to import the provider of said web service's certificate/public key? I've consumed a few web services over https before and never had to add the other company's certificate or public key to the key store (or is it trust store?) of any device at my company.

And yet apparently sometimes that is the case, as evidenced by these examples:

certificate mechanism between webservice provider and consumer

Consuming RESTful service over https with certificate using Java

Is it only necessary when the provider of the service's certificate is not issued by a CA known to the consumer?

Also, if the consumer does end up having to import the provider's certificate, AND it's the case that the consumer's consuming app itself consists of a client part and a server part, does the consumer import it into the store of the consumer's web server or into the store of each and every client computer at the consumer's company?

Finally, for two-way SSL, does the consumer send his own client certificate with code that executes on his (possibly many) client computers or on his own web server?

Thanks for any clarification.

RTF
  • 421
  • 2
  • 8

1 Answers1

0

Is it only necessary when the provider of the service's certificate is not issued by a CA known to the consumer?

yes. When relying party uses certificates from a globally trusted CA, there are no extra actions required to install foreign certificates.

into the store of each and every client computer at the consumer's company?

if issuer is not globally trusted, it must be installed on every device that consumes service with custom certificate.

does the consumer send his own client certificate with code that executes on his (possibly many) client computers or on his own web server?

it's unclear what do you mean. Can you elaborate?

update:

It depends on how 3rd party server authenticates you. Are they ok to identify your app as whole or they require to distinguish every internal user. In first case, it is enough to have single client certificate within your app and you will have two separate TLS connections:

3rd party server <--TLS--> Your App <--TLS--> End user (many)

End users connect and authenticate only on your application. When necessary, your app establishes a separate TLS connection to 3rd party and work is done. It is quite common practice. End users are not aware of 3rd party server and 3rd party server is not aware about your internal users (and probably should not be).

Crypt32
  • 12,850
  • 2
  • 41
  • 70
  • Elaboration on last point: Suppose I have a silverlight app on my intranet. It consists of a server side portion that runs on my server, and a client side portion that, say, a hundred clients in my intranet consume. You have a web service running on your server somewhere on the internet and agree to let my app consume it. However, you require client certificates to consume it. When one of my many clients uses your service it obviously must first go through my server. So is the client cert we send a single cert sitting on my server, or unique one from every client machine in my intranet? – RTF Sep 08 '19 at 14:51
  • Thank your for your response. I've seen an example of code in a server-side code file getting X509 credentials from the store and attaching them to a WebRequest in order to connect to web service, so I'm assuming that implies the "client" certificate we send in such a case is actually one certificate sitting on our web server and shared by all clients in our intranet. – RTF Sep 08 '19 at 15:16
  • Yes, it is correct. Your app don't have and shall not have direct access to client keys that belong to internal users. – Crypt32 Sep 08 '19 at 15:17