How Browser Verify SSL Certificate? – Before We Get Into The Topic , let’s Learn Some Basic Of This Topic
Browsers and Certificate Validation
Introduction
HTTPS (via SSL/TLS) employs public-key encryption to prevent browser communications from being intercepted or altered while in transit over the Internet. Servers provide a public key to visiting browsers, which is used to establish an encrypted connection for all subsequent data transfers.
Receiving a working public key, on the other hand, does not guarantee that it (and, by extension, the server) belongs to the correct remote subject (i.e. person, company, or organization). Man-in-the-middle attackers can use networks to serve their own keys, putting any communication at risk.
Browsers prevent this by using certificates to authenticate HTTPS servers. Certificates are digital documents that bind a public key to a specific subject. The binding is established by having a reputable Certification Authority (CA), such as SSL.com, validate the identity of potential certificate owners using automated and manual checks against certified databases.
Because of this trust relationship, online user security isn’t absolute; instead, users must trust browsers and CAs to secure their privacy. As a result, we believe that having a fundamental understanding of how certificate validation works are in everyone’s best interests.
It’s worth noting that the certificate validation procedure (detailed in detail in RFC 5280) is fairly complicated. We’ll try to walk you through one path (a browser checking a host’s SSL/TLS certificate) in this post, avoiding intricate details that are irrelevant to most users.
Do you require a certificate? You’re covered by SSL.com. Compare S/MIME and code signing certificates, as well as other possibilities, to determine the best option for you.
Certificates and the X.509 format
Certificates are digital files in every way, which means they must adhere to a file format to hold data (e.g. signatures, keys, issuers, etc.). While private PKI settings can use any certificate type they like, publicly trusted PKIs (those trusted by browsers) must follow RFC 5280, which mandates the usage of the X.509 v3 standard.
Additional data, such as use constraints or policy information, can be included as extensions in X.509 v3, with each extension being either critical or non-critical. Browsers can disregard non-essential extensions that are invalid or unrecognized, but they must process and validate any critical extensions.
Certification Paths and Path Processing
All issued certificates are cryptographically signed by CAs using a private key. Such signatures can establish that a certificate was issued by a specific CA and that it was not updated after it was signed in an irreversible manner.
CAS establishes ownership of its signature key by holding a self-issued certificate (referred to as the root) for the public key. CAS must follow strict, audited protocols to build, operate, and operate a root, and they will typically employ a root to issue intermediate certificates to limit their exposure. These intermediates can then issue certificates for their clients. Browsers come with a built-in list of trusted roots. (These are CA roots that have met the browser’s severe inclusion criteria.) To verify a certificate, the browser will receive a series of certificates, each of which has signed the certificate before it, thus connecting the signing CA’s root to the server’s certificate.
A certification path is a collection of credentials in a specific order. The root of the path is referred to as a trust anchor, whereas the server’s certificate is referred to as the leaf or end-entity certificate.
Path Construction
Browsers frequently have to assess numerous certification paths before finding one that is valid for a given certificate. Even though a path may comprise certificates that “chain” together properly to a recognized anchor, the path may be refused to owe to path length, domain name, certificate usage, or policy constraints.
Every new certificate a browser encounters necessitate an expensive process of constructing and assessing all feasible pathways. Various improvements have been applied by browsers to reduce the number of rejected candidate pathways, however digging into such specifics is beyond the scope of this article.
Path Validation
candidate certification path using information contained in the certificates after it has been built. A path is legitimate if browsers can cryptographically establish that each certificate’s corresponding private key was used to produce the next one in the path, all the way down to the leaf certificate, starting with a certificate directly signed by a trust anchor.
Certification Path Validation Algorithm
RFC 5280 provides a standard technique that browsers use to assess an X.509 certificate’s certification path.
Starting with the trust anchor (i.e. the root certificate), browsers go over all certificates in the route, confirming each certificate’s basic information and important extensions.
If the procedure completes without errors using the last certificate in the path, the path is considered legitimate. The paths are marked as invalid if errors are produced.
Basic certificate processing
Browsers must always validate basic certificate information such as the signature and issuer, regardless of extensions. The sections that follow show the order in which browsers complete their inspections.
1. The certificate’s validity is checked by the browser.
Normal public key cryptography can be used to verify the signature on the certificate. If the signature is invalid, the certificate is deemed to have been altered after it was issued and is thus denied.
2. The authenticity of the certificate is checked by the browser.
The validity period of a certificate is the amount of time that the signing CA guarantees that it will keep track of its status. Any certificates with a validity term that ends before or starts after the date and time of the validation check are rejected by browsers.
3. The certificate’s revocation status is checked by the browser.
When a certificate is granted, it is assumed that it will be used for the duration of its validity period. Of course, a certificate may become invalid before it expires due to a variety of factors.
A subject’s name being changed or their private key is suspected of being compromised are examples of such events. In such instances, a CA must revoke the relevant certificate, and users must trust CAs to tell browsers of the revocation status of their certificates.
4.CAs should use revocation lists for this, according to RFC 5280.
CAS issue a certificate revocation list, which is a signed, time-stamped list of revoked certificates, regularly (CRL). Browsers can obtain and consult the CA’s most recent CRL when validating a certificate because CRLs are distributed in publicly accessible repositories.
The time granularity of revocation is confined to the CRL issuing period, which is a weakness in this method. Only until all currently issued CRLs are scheduled to be updated will a browser be alerted of a revocation. This could take an hour, a day, or perhaps a week, depending on the signatory CA’s policy.
Certificates can put constraints on which rules they can be subject to for legal and operational reasons. Browsers must validate certificates if they contain essential policy limitations before proceeding. (However, because crucial policy restrictions are uncommon in the real world, they will be ignored for the remainder of this essay.)
5. The browser looks for name restrictions.
With the right name limitations, a privately owned (but publicly trusted) intermediate CA can give an organization fine-grained control over certificate maintenance and issuance. For a company or organization’s domain name, certificates might be confined to a certain domain or domain tree (including subdomains). For intermediate CA certificates obtained from a publicly trusted CA, name limitations are frequently used to prevent the intermediate CA from issuing completely acceptable certificates for third-party domains (e.g. google.com).
6. Policy constraints are checked by the browser.
A certificate policy is a legal document published by a CA that outlines the rules for issuing and managing certificates. CAS may issue certificates under one or more policies, and each certificate issued includes links to these policies so that relying parties can analyze them before determining whether or not to trust that certificate.
7. The browser does a rudimentary constraint check (a.k.a. path length)
Issuers can specify the maximum path length a certificate can support using the X.509 v3 standard. This gives you the ability to choose how far each certificate can be put in a certification path. This is significant because, until a researcher revealed how he utilized his website’s leaf certificate to manufacture a legitimate certificate for a large e-commerce website in a 2009 presentation, browsers ignored the certification path length.
8. The browser double-checks key usage.
The “key usage” extension specifies the function of the certificate’s key. Encryption, signatures, certificate signing, and other similar applications are examples of such uses. Browsers reject certificates that violate their key usage restrictions, such as a server certificate with a key intended just for CRL signing.
9. All critical extensions are still being processed by the browser.
Browsers evaluate all remaining extensions that the current certificate deems as critical before going on to the next after processing the extensions indicated above. If a browser successfully reaches a path’s leaf certificate, the path is considered legitimate. If any issues occur, the path is flagged as invalid, and a secure connection is not made.
Conclusion
The World Wide Web is a complicated system of interlinked moving pieces that are constantly evolving. As a result, browser security is not a solved topic, and we hope that this post has shed some light on the complexity of even the single component we’ve examined. Because trust is so important in keeping you safe online, we recommend that you learn more about your CA’s certificate policy. (In reality, you may study SSL.com’s regulations here.)