0

I am working on a deployment where the customer is requesting to do things differently from our standard process for client authentication. Usually we generate a CA for a customer project, get them to generate a CSR, we sign it with the CA, then we give them the resulting certification. We then configure nginx to trust that CA and thus the certificates we signed with it.

In this case, we are being asked to trust a DigiCert CA (not specific to the customer) instead. Obviously this would mean anyone with a DigiCert issued key+cert could authenticate to our service. So the proposal is that we add some DN field specific criteria in our nginx configuration to do authorisation, e.g. Organization=Foo.

Firstly, this is not something I'm familiar with doing. Is this a reasonable and secure approach?

Secondly, is it definitely the case that public CA's like DigiCert validate the Organization field and only allow one customer (of theirs) to create certificates with that field. Obviously if they let any customer create certificates with any Organization field this entire approach falls to pieces and is not secure.

Thanks!

2
  • I'm not familiar with nginx, but apache2 has a number of environment variables that you can access to get information about the client certificate used in mTLS. Using these variables, you can make your authorization conditions as granular or as general as you want. For example, you can authorize based on a whitelist individual certificates, or a whitelist of CA's, or a whitelist of subject names, etc. See httpd.apache.org/docs/2.2/mod/mod_ssl.html#envvars. I would imagine nginx has the same.
    – mti2935
    Jan 7, 2022 at 15:02
  • @mti2935 I've already looked into that and it definitely does. I'm more concerned that authorizing using certain DN fields is not actually secure!
    – dpwr
    Jan 7, 2022 at 15:18

2 Answers 2

2

As you realized yourself, your idea fully depends on the CA not issuing another certificate with the same DN. Unless this is a very well known organization I would not rely on the CA doing proper validation of the organization. Moreover Digicert has even managed to not properly issue EV certificates in the past - see Digicert revokes a raft of web security certificates.

The best you could probably do is to pin to a specific certificate provided by your customer, i.e. not based on DN but based on on the very specific certificate or at least on its public key (which might be the same for certificate renewals).

If this is too much hassle with renewing, then relying on the CA and on the uniqueness of the DN might still be acceptable if the threat is sufficiently low, like if the certificate is not used to control access to precious information so that attackers will not invest much effort.

2
  • Really informative, thanks. Do you know if DigiCert (and others) at least maintain exclusiveness for certain fields. E.g. if a company Foo signs up to DigiCert with Organization=Foo in their DNs, would they allow any other subsequent customer to put Organization=Foo in their certs, or would that be prohibited because another customer of DigiCert already has that reserved? Also, thanks for your other idea about pinning, but as you probably suspect, we've already rejected that because our customer wants to be able to generate certs that can authorise to our service, at will.
    – dpwr
    Jan 7, 2022 at 23:04
  • @dpwr: As far as I know there is no exclusiveness for company names, i.e. the major ones might be trademarked but not necessarily the smaller ones (just look at all the small barbers, plumbing companies etc) . So having such restriction of not having same OU for different customers might not fit reality. Jan 8, 2022 at 6:25
1

if they let any customer create certificates with any Organization field

Trusted CAs are an essential part of PKI. Technically, everyone can be a CA. But to get trust, a CA has to fulfill many conditions (processes they have to implement, reporting, auditing, etc). See this answer for instance.

If there is a dubt that some CA is not reliable, it loses its trust. Remeber the case with DigiNotar: After they issued Google wildcard certificate to an unknown person, the certificates issued by this CA were revoked by companies like Google, Mozilla and Microsoft and browsers stopped trusting any web sites whose certificates were issued by DigiNotar. In 3 months DigiNotar was declared bankrupt.

The most Internet connections nowdays use HTTPS, means SSL/TLS certificates are used, and every certificate is issued by some CA. Have you ever checked what CAs your browser trust, what CAs the apps on your smartphone trust?

Actually, it is good, that you think what CAs you can trust. You don't have to trust any CA blindly. To decide if you can trust particular CA consider following:

  • What will be the price in case some user gets certificate for some other organization? Will it cost you 100 USD, 1000 USD, 1000000 USD?
  • How probable is that particular CA can issue an incorrect certificate? For this, check for instance how long this CA exists, what companies trust this CA, is this CA included in the preinstalled list of trusted CAs of major browsers, operating systems and some wildly used software like Java.

If certificates are issued by major well known CAs, you can expect that it is almost impossible that certificate was issued incorrectly.

You must log in to answer this question.

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