2

Let's say we have:

  1. Publicly available HTTPS API (e.g. api.example.com). The web server that runs it uses a certificate from a publicly trusted CA (e.g. Let's Encrypt) with both server auth and client auth usages.
  2. A database using mutual TLS to authenticate itself and clients (and encrypt communication, obviously).

The API web server needs to authenticate to the database. We can create and manage a private PKI to issue certificates for database client authentication, but that's a hassle. What's stopping us from configuring the database to trust Let's Encrypt for client verification, adding a user with common name = api.example.com and reusing the api.example.com server certificate to authenticate as a client to the database (the certificate has client authentication in extended usages).

Are there any drawbacks to this scheme? Would we be compromising security in any way? The only problem I see is that if an attacker has gained access to alter DNS records, he can obtain a certificate for api.example.com and therefore have valid credentaials to authenticate to the database. Still, certificate issuance will be noticed (thanks to certificate transparency) and an attacker would need to gain network access to the database (it's not publicly exposed).

Improve this question

2 Answers 2

Reset to default
0

It's original to reuse the HTTPS server certificate as client certificate, but what you describe should work. You would obviously need to configure the db server to use LetsEncrypt as the client CA to trust, and basic tasks like ensuring your certificate isn't stolen, needed in both cases.

Using LetsEncrypt would force you to renew the client certificate every few months, which is something you would probably not be doing on your own with an internal PKI.

I think the biggest issue would be in the list of users. The user names must match the network resources you have available. Anyone would be able to present to your database a certificate signed by the right CA (LetsEncrypt), but for a different user (hostname). If someone even created a user security.stackexchange.com, suddenly a third party (the one running this site) could log into your database. Getting a certificate signed by your offline CA would be much harder (hopefully).

Another issue would be in the future. Right now you have an identity between the web server and the database client. But in the future, you may have an high load on api.example.com and wish to separate it in two servers (e.g. api-1 and api-2), each with their own database account to avoid copying the same private certificate on two hosts. Then your schema would be a problem. And you could want to place a load balancer in front of api-1 and api-2, performing the https termination for the name api.example.com That load balancer would be serving api.example.com to the world, but should not have access to the db server.

You are overloading the meaning of that certificate. While this is something that makes sense when they identify a single entity, or perhaps even needed in a constrained environment such as some IoT devices, I think I would go with a separate client certificate. This reuse is not the end of the world, but I think handling separate certificates will simplify the maintenance in the future.

Improve this answer
0

As usual the question of what shall we trust will come into consideration. While being a serious organization I would not necessarily trust Let's Encrypt to protect highly sensitive mission critical information. It is perfectly fine for most uses, not necessarily for administrator accesses or military grade data.

You should always think in terms of security zones:

  • what information is accessible in that zone
  • what are the risks if the information is compromissed (Availability, Integrity, or Confidentiality)
  • what are the protection layers and who controls them
  • are the risks and protection measures coherent

There is no general answer to your question, because it actually depends on the sensitivity of the information contained in the database.

Improve this answer

You must log in to answer this question.

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