In cryptography, a public-key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the valid attribution of a public key to the identity of its holder. The certificate includes the public key and information about it, 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 party examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to interact 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 a fee 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. A public-key certificate is typically requested from a PKI using a CSR, which needs to be transferred using a secure certificate enrollment protocol such as CMP, EST, or ACME. The parties involved in the enrollment process must verify the authenticity, integrity, and authorization of the CSR, for which the certificate issuer bears the main responsibility. In case of key compromise or other situations that may lead to unauthorized use, a certificate may need to be revoked. The general format for public-key and attribute certificates is defined by X.509. For public-key certificates, the format has been profiled by the IETF for Internet-related use cases, such as Public-Key Infrastructure (X.509).
Chain of trust
A digital certificate system provides a chain of trust, meaning most certificates can be validated against parent certificates. The chain starts with a root certificate, which serves as a trust anchor (a.k.a. root of trust). This certificate is self-signed (see below) and has no parent. The issuing certificate authority uses other methods to safeguard and validate this certificate. An intermediate certificate has a purpose similar to that of the root certificate – its only use is to sign other certificates. However, an intermediate certificate is not self-signed. A root certificate or another intermediate certificate needs to sign it. An end-entity certificate, or leaf certificate, is any certificate that cannot sign other certificates. For instance, TLS/SSL server and client certificates, email certificates, code signing certificates, and qualified certificates are all end-entity certificates.
Types of certificate
TLS/SSL server certificate The Transport Layer Security (TLS) protocol – as well as its outdated predecessor, the Secure Sockets Layer (SSL) protocol – ensures that the communication between a client computer and a server is secure. The protocol requires the server to present a digital certificate, proving that it is the intended destination. The connecting client conducts certification path validation, ensuring that:
The subject of the certificate matches the hostname (not to be confused with the domain name) to which the client is trying to connect. A trusted certificate authority has signed the certificate. The Subject field of the certificate must identify the primary hostname of the server as the Common Name. This means that the name listed in the certificate should exactly match the domain name users connect to (for example, www.example.com), ensuring that the certificate is valid for that specific hostname. The hostname must be publicly accessible, not using private addresses or reserved domains. A certificate may be valid for multiple hostnames (e.g., a domain and its subdomains). Such certificates are commonly called Subject Alternative Name (SAN) certificates or Unified Communications Certificates (UCC). These certificates contain the Subject Alternative Name field, though many CAs 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. Once the certification path validation is successful, the client can establish an encrypted connection with the server. Internet-facing servers, such as public Web servers, must obtain their certificates from a trusted, public certificate authority (CA).
TLS/SSL client certificate Client certificates 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. In addition, the certificate authority that issues the client certificate is usually the service provider to which client connects because it is the provider that needs to perform authentication. While most web browsers support client certificates, the most common form of authentication on the Internet is a username and password pair. Client certificates are more common in virtual private networks (VPN) and Remote Desktop Services, where they authenticate devices.
Email certificate In accordance with the S/MIME protocol, email certificates can both establish the message integrity and encrypt messages. To establish encrypted email communication, the communicating parties must have their digital certificates in advance. Each must send the other one digitally signed email and opt to import the sender's 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.
Self-signed certificate
… excerpt ends here. Continue reading the full article.
