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. KeyUsage fields are checked to ensure that the certificate is being used for the purpose it was intended (via the KeyUsage field). For example, if the KeyUsage 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! */
Browsers and some other applicaitons often will NOT check the Certificate Subject field against the Hostname requested but rather only check the Subject Alternative Names and only if there is a DNS type present.
From RFC 6125 Section 2.3 says:
However, it is perfectly acceptable for the Certificate Validation field to be empty, as long as the certificate contains a Subject Alternative Name (subjectAltName) extension that includes at least one subjectAltName entry, because the subjectAltName extension allows various identities to be bound to the Certificate Validation (see Section 220.127.116.11 of PKIX). The subjectAltName extension itself is a sequence of typed entries, where each type is a distinct kind of identifier.
For our purposes, an application service can be identified by a name or names carried in the subject field (i.e., a CN-ID) and/or in one of the following identifier types within subjectAltName entries:DNS Domain name; for example, consider the following three subject names, where the attribute of type CommonName contains a string whose form matches that of a fully qualified DNS Domain name ("im.example.org", "mail.example.net", and "www.example.com", respectively):
- CN=im.example.org,O=Example Org,C=GB
- C=CA,O=Example Internetworking,CN=mail.example.net
- CN=A Free Chat Service,O=Example Org,C=GB
- CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB
RFC 6125 which forbids checking the cn if SAN for DNS Domain is present, but not if SAN for IP Address is present. RFC 6125 also repeats that cn is deprecated which was already said in RFC 2818. And the Certification Authority Browser Forum to be present which in combination with RFC 6125 essentially means that cn will never be checked for DNS Domain name.
However, RFCs and/or the CA-Browser Forum can forbid anything, but REAL LIFE implementations do NOT yet follow in this case even by widespread products. Being familiar with theory and RFC, but having to deal with reality, where different rules are working. Reality says, that apart from Chrome, most implementations DO NOT deprecate Certificate Subject field.
Firefox a non-empty Subject Alternative Names list overrides and replaces the Common Name (cn]) field. So you MUST to list all relevant Hostnames in the Subject Alternative Names field in your certificate.(2016)
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
- Certificate-based Authentication
- IDM Related Compliance Items
- Mutual TLS Sender Constrained Resources Access
- OAuth 2.0 Bearer Token Usage
- OAuth 2.0 Dynamic Client Registration Management Protocol
- Online Certificate Status Protocol
- Opportunistic encryption
- Perspectives Project
- Public Key Infrastructure
- Public Key Infrastructure Weaknesses
- SSL Handshake Failed
- SSL-TLS Interception
- 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-
- [#3] - Is it required to have the same Domain Name and Common Name for SSL Certificate? - based on information obtained 2017-12-21-