1

I am looking into the security of a service which uses client certificates for authenticating only known callers. We run a C# Web API Service that checks every request certificate subject if it is white listed. Also it verifies that the cert is valid (cert chain validation).

But if an attacker gets a certificate with the same subject name that is issued by some certificate authority, they can attack our service, right? This seems less secure to me. Server SSL certificates are secure because users are reaching to a domain explicitly and the SSL cert the server uses contains the domain name validated by a cert authority. Unless the server certificate and some how the domain the user is trying to reach is compromised, the server is secure and client can trust the server.

But trusting a client seems less secure to me. Is my understanding right or am I missing something?

Improve this question
4
  • How about you whitelist a number of CAs that you are willing to trust and also verify that the certificate is valid? Would that be enough?
    – StackzOfZtuff
    Feb 8, 2018 at 19:33
  • How should an attacker get such a certificate? Which CA do you trust which will issue such certificates? Maybe you should restrict which CA you trust in the first place. Client certificates are commonly issued by your own CA (or a CA you control) since you only trust this one for this task.
    – Steffen Ullrich
    Feb 8, 2018 at 19:53
  • @SteffenUllrich Isn't it easy to get a certificate from a root CA with a given subject name? It might be hard to get a cert for a domain but a cert can be issued, let's say for <myname>.com with a subject name which matches with the subject name of some body else's certificate. This will still be accepted by the server if the server is only white listing based on subject names.
    – rboorgapally
    Feb 8, 2018 at 22:45
  • @rboorgapally: again: choose the CA you trust for client verification. Better trust only the CA you control, i.e. your own CA.
    – Steffen Ullrich
    Feb 9, 2018 at 6:04

1 Answer 1

Reset to default
4

Good question. With C# and .NET it is hard to limit a number of trusted root CAs via X509Chain class you will use to validate chains. This class doesn't offer such functionality (although, underlying CertCreateCertificateChainEngine native function allows this via CERT_CHAIN_ENGINE_CONFIG.hRestrictedRoot, bit it is long story).

In Active Directory, for example, this question is solved by introducing an NTAuthCertificates record under CN=Public Key Services, CN=Services, CN=Configuration, {ConfigurationNamingContext} which stores CA certificates (direct issuers) which are allowed to issue smart card logon and client authentication certificates. Domain controller during smart card logon performs general path building and validation, then gets issuer (from validated chain) and checks if it is listed in NTAuthCertificates. If everything is ok, then certificate logon continues, otherwise, it fails.

I would suggest to go same way. Maintain a collection of CAs (again, direct issuers, not roots) which are approved by your policy to issue authentication certificates. You can store whole certificates, their thumbprints, public keys or whatever that helps you to strongly identify them.

Improve this answer

You must log in to answer this question.

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