How to validate a client certificate

Question

My understanding is that when using a client certificate for security one issues a private and public key cert (for example X509) of some sort and sends that of to the consumer of the service that one wants to authorize themselves before consuming.

But what's then the standard way of checking that it's actually a valid client cert they are presenting? Please present the standard workflow here and also the role of the CA in this case.

also wondering what's preventing someone for just exporting the client cert from the client machine and using it somewhere else, is preventing export for the private key safe enough?

Answer 1

From a high level perspective, three things have to happen:

1. The client has to prove that it is the proper owner of the client certificate. The web server challenges the client to sign something with its private key, and the web server validates the response with the public key in the certificate.

2. The certificate has to be validated against its signing authority This is accomplished by verifying the signature on the certificate with the signing authority's public key. In addition, certificate revocation lists (CRLs) are checked to ensure the cert hasn't been blacklisted.

3. The certificate has to contain information which designates it as a valid user of the web service. The web server is configured to look at specific items in the certificate (typically the subject field) and only allow certain values.

Answer 2

The standard is called "X.509" and is best known under its incarnation as the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", better known as RFC 5280. The complete, standard, certificate validation algorithm is laid out in (pain)full details in section 6.

You cannot expect to seriously understand how X.509 works until you have gone through the effort of reading that document at least once. It will befuddle your mind, but that's because certificates and PKI are an inherently complex matter, which requires very precise notions of what is an identity, authentication, a private key, and trust. X.509 tries to tackle this complexity upfront, leading to Behemoth-like standards like RFC 5280.

---

Marking the private key as "non exportable" is just wishful thinking; it makes it slightly harder for non-technical users to actually export their key. A better answer would be that it should not matter. A user authenticates himself by demonstrating his control of the private key associated with his certificate. If the user wants to store his private key elsewhere that's his business; in the same way that it does not matter if you put your door key in your left trouser pocket, or in your right trouser pocket. And, similarly, if you leave your door key under the doormat and some dodgy individual grabs it from there, then your security disappears, but your insurance company will point out that it is your fault.

Answer 3

First of all I really think you need to identify what is exactly going on with the private key-certification:

1. Private key: this is something you must keep secret, for your eyes only.
2. Public key: this is something users will use so they can contact you (it is like you are using a language only the private key owner knows).
3. Certificate: this is something to validate that the public key it is actually the one associated to the owner of the private key.

So, consider that a certificate is something public that you can give away without being worried about that.

How does a certificate work? Let me put it in simple words: when issuing a public key, the CA adds a "secret mark" to the certificate, so when you want to validate it you have to send the certificate from the owner to the CA so it can check if the "secret part" is ok. If the CA checks the secret part and is consistent it will give you the "OK" to use the public key if not you should be suspicious about using it.

Consider having a look at this wikimedia diagram so you can learn about the whole process of creation and validation (CA included):

http://upload.wikimedia.org/wikipedia/commons/9/96/Usage-of-Digital-Certificate.svg

This other diagram might be useful as well:

http://blog.securism.com/wordpress/wp-content/uploads/2009/01/pki-simple-diag.jpeg

Also, consider that the CA are usually well-known trusted agencies and normally browsers have a list of them included. But some entities (usually public agencies or organizations) use their own CA and you have to manually add it to the list (please be extremely cautious about this since a malicious CA could really compromise your communications).

Hope this helps you.

(Feel free to add any grammar/syntax correction since English is not my mother tongue).

Answer 4

Certificates can hold a variety of parameters that can be used to limit the use of the certificate. For example, a certificate can be issued with application name and user name, so the application can confirm that the certificate is valid for the particular application then perform the standard x.509 certificate validation and then limit the acceptable user credentials to those of the individual to whom the certificate was issued.

This is a robust utilization of client-side certificates that requires the firm publishing the application specify and/or control the issuance of the certificates and that the certificate-based authentication be terminated at or passed through to the same architectural layer that authenticates the user credentials. [In other words, SSL/TLS concentrators can cause problems.]

NOTE: The additional fields in the certificate are cryptographically protected so, while visible, they cannot be changed without destroying the validity of the certificate. As a result, inclusion of these parameters cannot be spoofed with less difficulty than spoofing the entire certificate.

REFERENCES

• A directly related question -- Adding custom data in X.509 certificate
• Microsoft guidance --
  http://msdn.microsoft.com/en-us/library/ms731899(v=vs.110).aspx
• Wikipedia article -- http://en.wikipedia.org/wiki/X.509#Structure_of_a_certificate

Answer 5

Several projects, such as pathfinder-pki, will allow you to validate certificates in fully compliant ways.