Public key certificate
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, and the digital signature of an entity that has verified the certificate's contents.
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 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, is notable for being a part of HTTPS, a protocol for securely browsing the web.
In a typical public-key infrastructure scheme, the certificate issuer is a certificate authority, 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 enrollement protocol such as CMP, EST, or ACME. The parties involved in the enrollment process must verify the authenticty, 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.
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. This certificate is self-signed and has no parent. The issuing certificate authority uses other methods to safeguard and validate this certificate.An intermediate certificate has a similar purpose to 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 protocol – as well as its outdated predecessor, the Secure Sockets Layer 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 to which the client is trying to connect.
- A trusted certificate authority has signed the 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.
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. Some service providers even offer free SSL certificates as part of their packages.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 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
A self-signed certificate is a certificate with a subject that matches its issuer, and a signature that can be verified by its own public key.Although this type of certificate is worthless for establishing remote trust between unacquainted parties, it has full trust value when the issuer and the sole user are the same entity. As discussed above, a root certificate is a self-signed certificate. The certificate authority, which is the sole user of the certificate, uses other means to validate and safeguard it. Another example is the Encrypting File System on Microsoft Windows, which issues a self-signed certificate on behalf of the encrypting user, and uses it to transparently decrypt data on the fly.
Subject Alternative Name certificate
Subject Alternative Name certificates are an extension to X.509 that allows various values to be associated with a security certificate using asubjectAltName field. These values are called Subject Alternative Names. Names include:- Email addresses
- IP addresses
- URIs
- DNS names: this is usually also provided as the Common Name RDN within the Subject field of the main certificate.
- Directory names: alternative Distinguished Names to that given in the Subject.
- Other names, given as a General Name or Universal Principal Name: a registered object identifier followed by a value.
commonName field is now deprecated. Google Chrome version 58 removed support for checking the commonName field at all, instead only looking at the SANs.As shown in the picture of Wikimedia's section on the right, the SAN field can contain wildcards. Not all vendors support or endorse mixing wildcards into SAN certificates.
Wildcard certificate
A public-key certificate which uses an asterisk in the domain name portion of it subject is called a Wildcard certificate.Through the use of, a single certificate may be used for multiple sub-domains. It is commonly used for transport layer security in computer networking.
For example, a single wildcard certificate for will secure all these subdomains on the domain:
Because the wildcard only covers one level of subdomains, these domains would not be valid for the certificates:
Limitations
Only a single level of subdomain matching is supported.It is not possible to get a wildcard for an Extended Validation Certificate. A workaround could be to add every virtual host name in the Subject Alternative Name extension, the major problem being that the certificate needs to be reissued whenever a new virtual server is added.
Wildcards can be added as domains in multi-domain certificates or Unified Communications Certificates. In addition, wildcards themselves can have extensions, including other wildcards. For example, the wildcard certificate has as a Subject Alternative Name. Thus it secures as well as the completely different website name.
argues against wildcard certificates on security grounds, in particular "partial wildcards".
Further examples
The wildcard applies only to one level of the domain name. matches but not and notEarly specifications allowed the wildcard to appear anywhere inside a label as a "partial wildcard":
However, use of "partial-wildcard" certs is not recommended. As of 2011, partial wildcard support is optional, and is explicitly disallowed in SubjectAltName headers that are required for multi-name certificates. All major browsers have deliberately removed support for partial-wildcard certificates; they will result in a "SSL_ERROR_BAD_CERT_DOMAIN" error. Similarly, it is typical for standard libraries in programming languages to not support "partial-wildcard" certificates. For example, any "partial-wildcard" certificate will not work with the latest versions of both Python and Go. Thus,
Do not allow a label that consists entirely of just a wildcard unless it is the left-most label
A cert with multiple wildcards in a name is not allowed.
A cert with plus a top-level domain is not allowed.
Too general and should not be allowed.
International domain names encoded in ASCII are labels that are ASCII-encoded and begin with. URLs with international labels cannot contain wildcards.