How many SSL certificates you need - aspnet core + Apache reverse proxy?

There isn't a simple yes/no answer to this question I'm afraid.

If Kestrel and Apache are running on the same box, then you are effectively using a certificate only because Kestrel expects one. It provides no security and the Is it more secure? question is not applicable.

If Kestrel and Apache are on different boxes then it's slightly more complex. If the two boxes are on a trusted network, you could argue the same as above - the certificates are only there because Kestrel expects one.

If the network isn't trusted, you now will need some security. The certificate provides the machine identity required to instigate a TLS connection. Whether you use a self-signed certificate or a CA signed certificate for this adds more choices.

• If the Kestrel application is using an internal FQDN (e.g. app.local) and the CA is unwilling to certify such names (e.g. a commercial CA won't do this) then you are forced to use self-signed certificates.
• If the CA is internal and willing to certify local names, then you can consider using a CA for the Kestrel certificate.

So, assuming for now that you can use a CA certificate for Kestrel, you next need to ask yourself why you would need to do so:

• A CA signed certificate generally becomes worthwhile in a one-to-many scenario. If you have one server and many relying parties (clients) then a CA issued certificate ensures:

  • relying parties only need to trust the CA and every issued certificate is implicitly trusted (a self-signed certificate needs to be trusted by all clients);
  • relying parties do not need to review the governance and operational processes of each server they wish to trust as they can assume that if the CA has certified it, then it is trustworthy;
  • everything works after a certificate renewal (compared to a self-signed, which would need to be distributed to all clients after renewal);
  • revocation works (there's no concept of revocation for self-signed certificates - if the server certificate is compromised, you have to remove the certificate from all clients);

• However, if you're in a one-to-one scenario (like between a reverse proxy and an application server) then a CA brings less benefits (trust decisions are easier, renewal is easy, and if the server is compromised you simply remove the certificate from one client). In fact, if you don't have a CA available, the overhead of building and managing a CA just for the connection between application server and reverse proxy is so large as to make it not worthwhile.

For the latter, the only downside to using a self-signed certificate could be the lack of central management. Many CAs help with the lifecycle management of issued certificates, even if it's as simple an automated email to remind you that the certificate is about to expire, or as complex as automated renewals. A self-signed certificate is managed by you. To help mitigate this, some organisations use certificate lifecycle management tools to manage their certificates and if the tool can monitor self-signed certificate too, then that takes care of that problem.

So, to summarise, if your CA provides additional lifecycle management service which helps you manage the certificate then it may be worth considering; but otherwise, in a one-to-one scenario such as between an application server and a reverse-proxy, it doesn't really make a difference whether you use a self-signed certificate or a CA signed certificate.

If you do go down the route of a CA issued certificate for the application server, you have more decisions:

• If the application and reverse proxy are on the same box, you can safely consider using one certificate between them - it's unlikely that you will be in a situation where one service is compromised while the other is still trusted. You would (should) assume all certificates on a box are compromised if one is, so there is generally no real benefit in separate certificates.

• If the applications are on different boxes then you could be in a situation where one is compromised while the other isn't. In preparation for such cases, you should have a different certificate on each box.

Note that while the above discusses the communication between the application server and the reverse proxy, you could try the same reasoning with Identity Server 4 (whatever that may be).