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 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 (in ), 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 (SAN) certificates are an
extension to
X.509 that allows various values to be associated with a security certificate using a subjectAltName field.
Google Chrome version 58 (March 2017) removed support for checking the commonName field at all, instead only looking at the SANs. Not all vendors support or endorse mixing wildcards into SAN certificates.
Wildcard certificate : ) A public-key certificate which uses an
asterisk (the wildcard) 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: • • • • Instead of getting separate certificates for subdomains, you can use a single certificate for all main domains and subdomains and reduce cost. Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops), these domains would not be valid for the certificates: • • Note possible exceptions by CAs, for example wildcard-plus cert by DigiCert contains an automatic "Plus" property for the naked domain .
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 (SAN) extension, the major problem being that the certificate needs to be reissued whenever a new virtual server is added. (See
Transport Layer Security § Support for name-based virtual servers for more information.) Wildcards can be added as domains in multi-domain certificates or
Unified Communications Certificates (UCC). 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 not Early specifications allowed the wildcard to appear anywhere inside a label as a "partial wildcard": : is OK. It will match but not : is OK and matches : is OK and matches : is OK and matches 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 :'''' is not allowed. 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 (A-label) are labels that are
ASCII-encoded and begin with . URLs with international labels cannot contain wildcards. : is : is not allowed : is allowed
Other certificates • EMV certificate:
EMV is a payment method based on a technical standard for
payment cards,
payment terminals and
automated teller machines (ATM). EMV payment cards are preloaded with a card issuer certificate, signed by the EMV certificate authority to validate authenticity of the payment card during the payment transaction. •
Code-signing certificate: Certificates can validate
apps (or their
binaries) to ensure they were not tampered with during delivery. •
Qualified 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. • Role-based certificate: Defined in the
X.509 Certificate Policy for the Federal Bridge Certification Authority (FBCA), role-based certificates "identify a specific role on behalf of which the subscriber is authorized to act rather than the subscriber’s name and are issued in the interest of supporting accepted business practices." • Group certificate: Defined in the
X.509 Certificate Policy for the Federal Bridge Certification Authority (FBCA), for "cases where there are several entities acting in one capacity, and where non-repudiation for transactions is not desired." ==Common fields==