This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Certificate Validation
Certificate Validation

Version management

Difference between version and

At line 1 added 194 lines
!!! Overview[1]
The [Public Key Infrastructure] (PKI) describes a method of asserting the identity ([Authentication]) and validity of a [Digital Subject] that you have not previously met or interacted with through the use of [Certificates] containing identifying information and public keys (these certificates are more properly called [X.509] certificates).
[Public Key Infrastructure] accomplishes this by defining a [Certificate Authority] who is mutually trusted by all users of the [Public Key Infrastructure] system.
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|Certificate Revocation]. Meaning, that before you trust the authentication of a message from anybody using his certificate, you should perform [{$pagename}].
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.
[{Image src='Public Key Infrastructure/PKI Infrastructure Overview.png'}]
[{$pagename}] 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 [{$pagename}].
!! 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]
Next, the certificate is checked to ensure that it has not expired. This is done by verifying that the current time falls within the [Certificate Validity Period] included in the [Certificate].
!! [Certificate] [KeyUsage]
Next, 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].
Recall the step where the integrity checks are performed. The user must decrypt the [digital signature|Certificate Signature] using a [Public Key].
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|Verifying Certificate Signatures], 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]
At this point, the only remaining step is to verify the [Certificate Revocation] Status.
!! [hostname] Verification[2]
One final check that we need to do is to verify that name of the host name or [IP] address that was used to initiate the [secure connection] resides in the [Certificate Subject] or [Subject Alternative Names] of the [certificate].
The "*" wildcard character is allowed. If present, it applies only to the left-most [Certificate Subject] or [Subject Alternative Names] component.
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|Certificate Authority] to stop these bad things from happening.
Nelson Bolyard’s comment in the SSL_AuthCertificate function explains why:
%%pretty
{{{
/* 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.
[OpenSSL] versions prior to 1.0.2 did not perform hostname validation. [OpenSSL] added [hostname] validation in January [2015|Year 2015] but it is only utilized when requested.
From [RFC 6125] Section 2.3 says: \\However, it is perfectly acceptable for the [{$pagename}] 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 [{$pagename}] (see Section 4.2.1.6 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-ID|dNSName]
* [SRV-ID|DNS SRV Records]
* URI-ID
Existing certificates often use a CN-ID in the subject field to represent a fully qualified [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
* O=Examples-R-Us,CN=www.example.com,C=US
However, the [Common Name] is not strongly typed because a Common Name might contain a human-friendly string for the service, rather than a string whose form matches that of a [Fully Qualified Domain Name] (a [certificate] with such a single Common Name will typically have at least one [subjectAltName] entry containing the [Fully Qualified Domain Name]):
* CN=A Free Chat Service,O=Example Org,C=GB
Or, a certificate's subject might contain both a CN-ID as well as another common name attribute containing a human-friendly string:
* CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB
In general, this specification recommends and prefers use of [subjectAltName] entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the subject field (CN-ID) where possible, as more completely described in the following sections. However, specifications that reuse this one can legitimately encourage continued support for the CN-ID identifier type if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, [EV-CERTS]).
! Real World [3]
The [DNS Domain] of the [URL] [MUST] match the [Certificate Subject] of the [certificate]. In former times this could be either by setting the domain as [cn] of the certificate or by having the domain set as a [Subject Alternative Name]. Support for [cn] was [deprecated] for a long time (since [2000|Year 2000] in [RFC 2818]) and [Chrome] [browser] will not even look at the [cn] anymore so today you need to have the [DNS Domain] of the [URL] as a [Subject Alternative Name].
%%information
There can be multiple [Subject Alternative Name] and thus the [certificate] can be used for multiple [DNS Domains].
%%
[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|deprecated] [Certificate Subject] field.
[Microsoft Windows] (and their tools), there are a lot of use cases where [SAN] is __not__ mandatory. Moreover, I know only one use case (within Windows platform) when [SAN] is required.
[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|Year 2016])
!! Summary
In summary, the [{$pagename}] 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 [{$pagename}] steps to a centralized server that is trusted by users. This mechanism is called [Server-Based Certificate Validation Protocol] defined in [RFC 5055].
!! [Certificate Level Of Assurance]
* [Domain Validated Certificate]
* [Organization Validated Certificate]
* [Extended Validation Certificate] - EV Green Bar
!! [Certificate Validation Tools]
We have spotted some [Certificate Validation Tools] you may find helpful.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [http://blog.securism.com/2009/01/summarizing-pki-certificate-validation/|http://blog.securism.com/2009/01/summarizing-pki-certificate-validation/|target='_blank'] - based on 2013-04-10
* [#2] - [The First Few Milliseconds of an HTTPS Connection|http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html|target='_blank'] - based on information obtained 2017-01-12-
* [#3] - [Is it required to have the same Domain Name and Common Name for SSL Certificate?|https://security.stackexchange.com/a/175788/70391|target='_blank'] - based on information obtained 2017-12-21-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop