I'm using TLS client authentication for a machine-to-machine connection. In addition to ensuring the client has a valid cert, I'd like to have access control to ensure the request is originating from one specific entity.

Is checking the CN of a valid certificate a secure form of access control?


I want to only accept requests from example.com

Is checking that CN = example.com sufficient?


If the CN (or other parts of the certificate like SAN) is usable for authentication depends on how much you can trust the one who put the CN there to properly verify the value. For example with a self-signed certificates you cannot trust the CN at all since you cannot verify who created the certificate in the first place (anybody could) and thus cannot trust this one to properly validate the value in the CN.

With certificates issued for domains by a public CA it depends. If this is a cheap/free DV certificate the issuer if the certificate just checked that the owner of the certificate had at least for a short time partial control of the domain - either over the domains DNS, the domains web server or maybe the email (depending on the verification method). This could have been an attacker as recent events show again. EV certificates on the other hand have more complex verification and thus are much harder to spoof.

Thus, if you can trust the one who puts the subject in the certificate to properly verify that the claimed owner is the actual owner and if you properly verify the certificate (issuer, expiration, revocation...) and if the sender of the certificate can prove ownership of the matching private key (done when used for authentication inside TLS) and if you can be sure that the private key is actually kept private by the owner (otherwise it is hopefully rejected) - then you can trust the value in the CN/SAN and use it for authentication.

And this is what is actually done in TLS: the server certificate is checked by the client to make sure that it talks to the right server (i.e. no man in the middle). Additionally a server might request a client certificate to authenticate the client. In protocols like SIP where each peer can be client and server it is not uncommon to have such mutual authentication (i.e. both server and client certificate) where the same certificate is used as server certificate when acting as server and as client certificate when acting as client.

  • In short: checking the CN is necessary, but not sufficient. You'll need to validate the signature as well, and find a trust chain that have an acceptable root of trust. – Lie Ryan Jan 15 '19 at 12:16
  • 1
    @LieRyan: correct, and the important part is the acceptable root of trust. – Steffen Ullrich Jan 15 '19 at 12:23
  • Thanks, Steffen, this is very helpful. In terms of an acceptable root of trust, I'm currently relying on Mozilla's trusted CAs. I imagine this is sufficient but please let me know if you there are any concerns there. – Shruggie Jan 16 '19 at 0:09
  • 1
    @ben: Which CA you trust depends on your specific use case and environment. In IoT or industry scenarios it is common to not rely on public CA but have their own PKI structure since this means more control and therefore also more trustability. – Steffen Ullrich Jan 16 '19 at 5:20
  • 1
    @ben: there are no general rules how the subject (CN/SAN) should be validated. There are only specific rules for server certificates in the context of HTTP, LDAP etc. But if the CN/SAN contains a domain name and you know which domain name to expect (as in protocols like SIP) then it makes sense to apply same/similar rules for server and client certificates. But client certificates might also be used to identify individuals (CN/SAN contains email or name) or other things so the exact process of checking the CN/SAN depends very much on your specific use case. – Steffen Ullrich Jan 19 '19 at 5:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.