Securing an API using Mutual TLS - Is checking the subject DN enough?

Question

I am using AWS API Gateway to build my API, and securing it using API Gateway's recently launched Mutual TLS feature. My use-case is to only authenticate a few servers. Here is my approach in brief:

1. Ask the clients to get client certificates issued from reputable CA, say, Digicert. The certificate must be for a domain that they own.
2. Set the truststore (the CA certificates used to validate the client-provided certificate) to certificate chain(s) of Digicert by downloading the appropriate certificates from their website. This will ensure that only certificates signed by Digicert are accepted, and any other certificate provided by clients will be rejected.
3. In a custom Lambda Authorizer, verify if the Subject DN field of the provided certificate matches the one that I expect. For example, if I trust client.example.com, I will check the Subject DN field of the certificate for this value. That is, if the Subject DN field does not equals client.example.com, 'Unauthorized` response is returned to the client.

My hypothesis is that this approach of securing the API is secure because:

• I myself download (and check the hash) for the CA Root Certificates, so they are not compromised.

• Client connections with any other certificate will be rejected.

• Lastly, Digicert would not sign a certificate for a domain without doing proper validations and ownership checks.

Is my hypothesis correct?

Answer 1

The design in overall is ok. The only thing I would change is to check Subject Alternative Names extension and look for suitable DNS Name name type. The problem with Subject field (apart from it is obsolete) is that subject can include only one name. This means that if client has a certificate with:

Subject: CN=example.com
SAN1: DNS=example.com
SAN2: DNS=client.example.com
<...>

it is valid for client.example.com, however you will reject it with your existing logic. When you need to validate identity, use Subject Alternative Names extension only and do not rely on Subject anymore. After all, it is deprecated by RFC5280 and CAB/Forum long ago.