In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the ownership of a public key. The certificate includes information about the key, information about the identity of its owner (called the subject), and the digital signature of an entity that has verified the certificate’s contents (called the issuer). If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate’s subject. In email encryption, code signing, and e-signature systems, a certificate’s subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate’s subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In a typical public-key infrastructure (PKI) scheme, the certificate issuer is a certificate authority (CA), usually a company that charges customers to issue certificates for them. By contrast, in a web of trust scheme, individuals sign each other’s keys directly, in a format that performs a similar function to a public key certificate.

The most common format for public key certificates is defined by X.509. Because X.509 is very general, the format is further constrained by profiles defined for certain use cases, such as Public Key Infrastructure (X.509) as defined in RFC 5280.

Types of Certificate

TLS/SSL server certificate

In TLS (an updated replacement for SSL), a server is required to present a certificate as part of the initial connection setup. A client connecting to that server will perform the certification path validation algorithm:

  1. The subject of the certificate matches the hostname (i.e. domain name) to which the client is trying to connect;
  2. The certificate is signed by a trusted certificate authority.

The primary hostname (domain name of the website) is listed as the Common Name in the Subject field of the certificate. A certificate may be valid for multiple hostnames (multiple websites). Such certificates are commonly called Subject Alternative Name (SAN) certificates or Unified Communications Certificates (UCC). These certificates contain the field Subject Alternative Name, though many CAs will also put them into the Subject Common Name field for backward compatibility. If some of the hostnames contain an asterisk (*), a certificate may also be called a wildcard certificate.

A TLS server may be configured with a self-signed certificate. When that is the case, clients will generally be unable to verify the certificate, and will terminate the connection unless certificate checking is disabled.

As per the applications, SSL Certificates can be classified into three types:

  1. Domain Validation SSL;
  2. Organization Validation SSL;
  3. Extended Validation SSL.

TLS/SSL client certificate

Client certificates are less common than server certificates, and are used to authenticate the client connecting to a TLS service, for instance to provide access control. Because most services provide access to individuals, rather than devices, most client certificates contain an email address or personal name rather than a hostname. Also, because authentication is usually managed by the service provider, client certificates are not usually issued by a public CA that provides server certificates. Instead, the operator of a service that requires client certificates will usually operate their own internal CA to issue them. Client certificates are supported by many web browsers, but most services use passwords and cookies to authenticate users, instead of client certificates.

Client certificates are more common in RPC systems, where they are used to authenticate devices to ensure that only authorized devices can make certain RPC calls.

Email certificate

In the S/MIME protocol for secure email, senders need to discover which public key to use for any given recipient. They get this information from an email certificate. Some publicly trusted certificate authorities provide email certificates, but more commonly S/MIME is used when communicating within a given organization, and that organization runs its own CA, which is trusted by participants in that email system.

Code signing certificate

Certificates can also be used to validate signatures on programs to ensure they were not tampered with during delivery.

Qualified certificate

Main article: Qualified digital certificate

A certificate identifying an individual, typically for electronic signature purposes. These are most commonly used in Europe, where the eIDAS regulation standardizes them and requires their recognition.

Root certificate

Main article: Root certificate

A self-signed certificate used to sign other certificates. Also sometimes called a trust anchor.

Intermediate certificate

A certificate used to sign other certificates. An intermediate certificate must be signed by another intermediate certificate, or a root certificate.

End-entity or leaf certificate

Any certificate that cannot be used to sign other certificates. For instance, TLS/SSL server and client certificates, email certificates, code signing certificates, and qualified certificates are all end-entity certificates.

Self-signed certificate

Main article: Self-signed certificate

A certificate with a subject that matches its issuer, and a signature that can be verified by its own public key. Most types of certificate can be self-signed. Self-signed certificates are also often called snake oil certificates to emphasize their untrustworthiness.

Common field

These are some of the most common fields in certificates. Most certificates contain a number of fields not listed here. Note that in terms of a certificate’s X.509 representation, a certificate is not “flat” but contains these fields nested in various structures within the certificate.

  1. Serial Number: Used to uniquely identify the certificate within a CA’s systems. In particular this is used to track revocation information.
  2. Subject: The entity a certificate belongs to: a machine, an individual, or an organization.
  3. Issuer: The entity that verified the information and signed the certificate.
  4. Not Before: The earliest time and date on which the certificate is valid. Usually set to a few hours or days prior to the moment the certificate was issued, to avoid clock skew problems.
  5. Not After: The time and date past which the certificate is no longer valid.
  6. Key Usage: The valid cryptographic uses of the certificate’s public key. Common values include digital signature validation, key encipherment, and certificate signing.
  7. Extended Key Usage: The applications in which the certificate may be used. Common values include TLS server authentication, email protection, and code signing.
  8. Public Key: A public key belonging to the certificate subject.
  9. Signature Algorithm: The algorithm used to sign the public key certificate.
  10. Signature: A signature of the certificate body by the issuer’s private key.

Sourece : wikipedia

LEAVE A REPLY

Please enter your comment!
Please enter your name here