Every time before using a key or Certificate the validity of a Certificate should be checked . In case of stolen or outdated certificates, these certificates will be revoked. Meaning, that before you trust the authentication of a message from anybody using his certificate, you should perform Certificate Validation.
The following logical diagram shows how this works where the "User" is presenting my credentials to a Relying Party to setup a trusted communication path.
Certificate Validation is described in RFC 5280 which is notoriously complex due to issues of backwards compatibility with older X.509 standards. We can still easy to describe the overall process used by end user software to perform Certificate Validation.
Certificate’s Integrity#The first step of validating a certificate is to first verify the certificate’s integrity. This is done by first creating a one way hash of the certificate contents (using the hash algorithm indicated in the certificate). This hash is stored temporarily in memory. Next, the Digital Signature embedded in the certificate is decrypted using the Public Key included in the certificate (or, for Certificate Authority issued certificates using the Public Key from the Certificate Authority root certificate). The decrypted Digital Signature (which is again a hash of the certificate contents) is then compared to the hash that was computed locally. If the hashes match, then the user knows that the certificate has not been altered since it was created. Certificate Validity Period included in the Certificate. Certificate Key Usage field). For example, if the Certificate Key Usage field of a certificate is set to cRLSign but the Certificate is presented by a bank website, the Certificate is not being used as intended and will (well Should) be rejected.
Validation of the Certificate Issuer#Validation of the Certificate Issuer bears more discussion as it is the validation step that is most important in trusting a Certificate. An important field embedded in a X.509 certificate is the Certificate Issuer field. The Certificate Issuer field lists the name of a Certificate Authority which has vouched for the validity of the Certificate.
Instead of using the Public Key embedded in the Certificate, the user looks at the Certificate Issuer field to identify a Certificate Authority certificate, or Root Certificate that contains the Public Key that should be used to verify the Certificate. The Root Certificates are stored locally on the user-agent in a Trust Anchor Store, so the software searches through this list to fetch the correct Root Certificate.
Once the Root Certificate has been found, the Public Key from the Root Certificate is used to decrypt the Certificate Signature in the Certificate being validated. If the signature is validated, the user knows that the owner of the Root Certificate (the Certificate Authority), has signed the Certificate being presented and therefore vouches for the contents of the Certificate.
We show some more technical details about how this is performed in Verifying Certificate Signatures.Certificate Revocation Status. IP address that was used to initiate the secure connection resides in the Certificate Subject or Subject Alternative Names of the certificate.
E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. If more than one identity of a given type is present in the certificate the Certificate Subject or Subject Alternative Names, a match in any one of the set is considered acceptable.
This check helps prevent against a Man-In-The-Middle attack because we are implicitly trusting that the Registration Authority on the Certificate Chain would not do something bad, like sign a certificate claiming to be from Amazon.com unless it actually was Amazon.com. If an attacker is able to modify your DNS server by using a technique like DNS cache poisoning, you might be fooled into thinking you’re at a trusted site (like Amazon.com) because the address bar will look normal. This last check implicitly trusts certificate Authorities to stop these bad things from happening.
Nelson Bolyard’s comment in the SSL_AuthCertificate function explains why:
/* cert is OK. This is the client side of an SSL connection. * Now check the name field in the cert against the desired hostname. * NB: This is our only defense against Man-In-The-Middle (MITM) attacks! */
Summary#In summary, the Certificate Validation process is complex and resource intensive. The PKIX community has recognized this as becoming more of a problem with the prevalence of mobile devices that have limited processing resources. A solution that is being proposed is a mechanism to offload the responsibility of performing all of the Certificate Validation steps to a centralized server that is trusted by users. This mechanism is called Server-Based Certificate Validation Protocol defined in RFC 5055.
- Domain Validated Certificate
- Organization Validated Certificate
- Extended Validation Certificate - EV Green Bar
More Information#There might be more information for this subject on one of the following:
- Certificate Authority
- Certificate Pinning
- Certificate Revocation List
- Certificate Signature
- Certificates and Authentication
- OAuth 2.0 Bearer Token Usage
- OAuth 2.0 Dynamic Client Registration Management Protocol
- Online Certificate Status Protocol
- Perspectives Project
- Public Key Infrastructure
- Public Key Infrastructure Weaknesses
- Self-signed Certificate
- Subject Certificate
- Trusted Certificate
- [#1] - http://blog.securism.com/2009/01/summarizing-pki-certificate-validation/ - based on 2013-04-10
- [#2] - The First Few Milliseconds of an HTTPS Connection - based on information obtained 2017-01-12-