1

My company is launching cloud based SaaS service. There will be clients from different tenants connecting to our services via mutual SSL.

The clients would use a library provided by us to connect to the service. This Java based library would perform mutual SSL using keystores and truststores. So both server and clients are in our control. To emphasize, there are no browsers involved in the whole communication.

In order to successfully perform mutual SSL authentication, they must trust a certificate provided by our cloud service. This certificate could be:

  1. A public CA certificate (like Comodo, Verisign etc.). But asking clients to trust a public CA would allow possibility of man in middle attacks as someone else can use a different certificate signed by same CA to fool the clients.
  2. Private Root CA of our own. This would involve building our own PKI service and securing the private key et al. Does our situation justify opting this route?
  3. Self-signed certificate used by both server and clients. One problem I see with this solution is that when the certificate expires, all clients across tenants will have to reconfigure new certificate at the same time. That would be unacceptable.

Another option I have come across is to use some sort of SSL pinning (certificate or public key) which will override the trust chain. This is not an easy solution to implement.

What is the recommended solution?

Improve this question
5
  • Public Key Pinning is already disabled again by some major browser due to some incompatibilites. developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
    – Lithilion
    Commented Dec 11, 2018 at 10:44
  • There is nothing known about your clients. If these are normal browsers they will trust public CA anyway, even if you use a private root CA. If instead these are applications controlled by you creating your own CA and only trusting this makes sense - depending on the kind of service even a single self-signed certificate explicitly trusted by the clients (with maybe another one as backup) will work. But, you talk only about trusting server certificates so far although your title specifically asks about mutual SSL - which involves client certificates too. Please clarify your question.
    – Steffen Ullrich
    Commented Dec 11, 2018 at 11:08
  • @SteffenUllrich you are right I will include details about the clients in the question
    – xsreality
    Commented Dec 11, 2018 at 11:45
  • @SteffenUllrich I have updated the question with client details. To your point of self-signed certificates, upon expiry, they will have to be updated in all clients across multiple tenants at the same time which would be a monumental effort.
    – xsreality
    Commented Dec 11, 2018 at 11:54
  • @Lithilion Please have a look at the updated question. The clients are libraries in our control which do mutual SSL. No browsers involved. So public key pinning is still an option right?
    – xsreality
    Commented Dec 11, 2018 at 11:54

1 Answer 1

Reset to default
1

Given that both client and server are fully within your control I consider it the best (and maybe also easiest) thing to rely only on self-issued certificates so that you don't need to trust some external CA which is outside of your control.

If you have only a few communication peers it might be easy to go with self-signed certificates and exchange these when needed. Note that you could simply pin to the specific certificate or public key in this case and ignore any expiration, revocation etc - since everything is in your direct control anyway.

With more communication peers it is probably better to create your own PKI structure, i.e. have your own root CA which issues certificates for both clients and servers and which can also renew and revoke certificates. Once this PKI is setup the management of the communication peers is simplified since they only need to trust this specific CA (and only this CA). A simple PKI structure could be created with openssl already but there are also commercial products which might provide better usability and also scale better.

Given that you have full control over both clients and server it is actually possible to start simple and cheap (self-signed certificates), grow slowly but remain cheap (openssl based CA) and then move to an (not so cheap) enterprise CA when lots of clients are involved.

Improve this answer
2
  • Thanks for the quick answer Steffen! To clarify, by full control I meant that the client is built on custom library provided by us. But the lifecycle of the client is separate from the server and upgrading of clients would be done by our customers only. Also, at our initial launch, we would already have about 15-20 clients connecting to our services, so we don't want to start with an option like self signed certs from which migration would be needed soon. Curious to know more about the enterprise CA. Is it some sort of managed PKI service? Can you elaborate some more on this?
    – xsreality
    Commented Dec 11, 2018 at 12:29
  • 1
    @xsreality: There are companies who sell PKI solutions which you can then host yourself. There are probably also companies who will offer PKI as a service.
    – Steffen Ullrich
    Commented Dec 11, 2018 at 14:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .