Incryptography, apublic key certificate, also known as adigital certificate oridentity certificate, is anelectronic document used to prove the validity of apublic key.[1][2] The certificate includes the public key and information about it, information about the identity of its owner (called the subject), and thedigital signature of an entity that has verified the certificate's contents (called the issuer). If the device 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 communicate securely with the certificate's subject. Inemail encryption,code signing, ande-signature systems, a certificate's subject is typically a person or organization. However, inTransport 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 nameSecure Sockets Layer (SSL), is notable for being a part ofHTTPS, aprotocol for securely browsing theweb.
In a typicalpublic-key infrastructure (PKI) scheme, the certificate issuer is acertificate authority (CA),[3] usually a company that charges customers a fee to issue certificates for them. By contrast, in aweb of trust scheme, individuals sign each other's keys directly, in a format that performs a similar function to a public key certificate. In case of key compromise, a certificate may need to berevoked.
The most common format for public key certificates is defined byX.509. Because X.509 is very general, the format is further constrained by profiles defined for certain use cases, such asPublic Key Infrastructure (X.509) as defined inRFC 5280.
TheTransport Layer Security (TLS) protocol – as well as its outdated predecessor, theSecure Sockets Layer (SSL) protocol – ensures that the communication between aclient computer and aserver is secure. The protocol requires the server to present a digital certificate, proving that it is the intended destination. The connecting client conductscertification path validation, ensuring that:
TheSubject field of the certificate must identify the primary hostname of the server as theCommon Name.[clarification needed] The hostname must be publicly accessible, not usingprivate addresses orreserved domains.[4] A certificate may be valid for multiple hostnames (e.g., a domain and its subdomains). Such certificates are commonly calledSubject Alternative Name (SAN) certificates orUnified Communications Certificates (UCC). These certificates contain theSubject Alternative Name field, though many CAs also put them into theSubject Common Name field for backward compatibility. If some of the hostnames contain an asterisk (*), a certificate may also be called awildcard certificate.
Once the certification path validation is successful, the client can establish an encrypted connection with the server.
Internet-facing servers, such as publicweb servers, must obtain their certificates from a trusted, public certificate authority (CA).
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.[5]
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 invirtual private networks (VPN) andRemote Desktop Services, where they authenticate devices.
In accordance with theS/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.
Aself-signed certificate is a certificate with a subject that matches its issuer, and a signature that can be verified by its own public key.
Self-signed certificates have their own limited uses. They have full trust value when the issuer and the sole user are the same entity. For example, the Encrypting File System on Microsoft Windows issues a self-signed certificate on behalf of the encrypting user and uses it to transparently decrypt data on the fly. The digital certificate chain of trust starts with a self-signed certificate, called aroot certificate,trust anchor, ortrust root. A certificate authority self-signs a root certificate to be able to sign other certificates.
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 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.
Subject Alternative Name (SAN) certificates are anextension toX.509 that allows various values to be associated with a security certificate using asubjectAltName field.[6] These values are calledSubject Alternative Names (SANs). Names include:[7]
RFC 2818 (May 2000) specifies Subject Alternative Names as the preferred method of adding DNS names to certificates, deprecating the previous method of putting DNS names in thecommonName field.[8]Google Chrome version 58 (March 2017) removed support for checking thecommonName field at all, instead only looking at the SANs.[8]
As shown in the picture of Wikimedia's section on the right, the SAN field can contain wildcards.[9] Not all vendors support or endorse mixing wildcards into SAN certificates.[10]
*)A public key certificate which uses anasterisk* (thewildcard) in itsdomain name fragment is called a Wildcard certificate.Through the use of*, a single certificate may be used for multiplesub-domains. It is commonly used fortransport layer security incomputer networking.
For example, a single wildcard certificate forhttps://*.example.com will secure all these subdomains on thehttps://*.example.com domain:
payment.example.comcontact.example.comlogin-secure.example.comwww.example.comInstead of getting separate certificates for subdomains, you can use a single certificate for all main domains and subdomains and reduce cost.[11]
Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops),[12] these domains would not be valid for the certificates:[13]
test.login.example.comexample.comNote possible exceptions by CAs, for example wildcard-plus cert by DigiCert contains an automatic "Plus" property for the naked domainexample.com.[citation needed]
Only a single level ofsubdomain matching is supported in accordance withRFC 2818.[1]
It is not possible to get a wildcard for anExtended Validation Certificate.[14] A workaround could be to add every virtual host name in theSubject Alternative Name (SAN) extension,[15][16] the major problem being that the certificate needs to be reissued whenever a new virtual server is added. (SeeTransport Layer Security § Support for name-based virtual servers for more information.)
Wildcards can be added as domains in multi-domain certificates orUnified Communications Certificates (UCC). In addition, wildcards themselves can havesubjectAltName extensions, including other wildcards. For example, the wildcard certificate*.wikipedia.org has*.m.wikimedia.org as a Subject Alternative Name. Thus it secureswww.wikipedia.org as well as the completely different website namemeta.m.wikimedia.org.[17]
RFC 6125 argues against wildcard certificates on security grounds, in particular "partial wildcards".[18]
The wildcard applies only to one level of the domain name.*.example.com matchessub1.example.com but notexample.com and notsub2.sub1.domain.com
The wildcard may appear anywhere inside a label as a "partial wildcard" according to early specifications[19]
f*.domain.com is OK. It will matchfrog.domain.com but notfrog.super.domain.combaz*.example.net is OK and matchesbaz1.example.net*baz.example.net is OK and matchesfoobaz.example.netb*z.example.net is OK and matchesbuzz.example.netHowever, 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.[20] All major browsers have deliberatelyremoved support for partial-wildcard certificates;[21][22] 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[23] and Go. Thus,
Do not allow a label that consists entirely of just a wildcard unless it is the left-most label
sub1.*.domain.com is not allowed.A cert with multiple wildcards in a name is not allowed.
*.*.domain.comA cert with* plus a top-level domain is not allowed.
*.comToo general and should not be allowed.
*International domain names encoded in ASCII (A-label) are labels that areASCII-encoded and begin withxn--. URLs with international labels cannot contain wildcards.[24]
xn--caf-dma.com iscafé.comxn--caf-dma*.com is not allowedLw*.xn--caf-dma.com is allowedThese 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.
This is an example of a decoded SSL/TLS certificate retrieved from SSL.com's website. The issuer's common name (CN) is shown asSSL.com EV SSL Intermediate CA RSA R3, identifying this as anExtended Validation (EV) certificate. Validated information about the website's owner (SSL Corp) is located in theSubject field. TheX509v3 Subject Alternative Name field contains a list of domain names covered by the certificate. TheX509v3 Extended Key Usage andX509v3 Key Usage fields show all appropriate uses.
Certificate: Data: Version: 3 (0x2) Serial Number: 72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3 Validity Not Before: Apr 18 22:15:06 2019 GMT Not After : Apr 17 22:15:06 2021 GMT Subject: C=US, ST=Texas, L=Houston, O=SSL Corp/serialNumber=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Private Organization/street=3100 Richmond Ave/jurisdictionST=Nevada/jurisdictionC=US Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:ad:0f:ef:c1:97:5a:9b:d8:1e ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD Authority Information Access: CA Issuers - URI:http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt OCSP - URI:http://ocsps.ssl.com X509v3 Subject Alternative Name: DNS:www.ssl.com, DNS:answers.ssl.com, DNS:faq.ssl.com, DNS:info.ssl.com, DNS:links.ssl.com, DNS:reseller.ssl.com, DNS:secure.ssl.com, DNS:ssl.com, DNS:support.ssl.com, DNS:sws.ssl.com, DNS:tools.ssl.com X509v3 Certificate Policies: Policy: 2.23.140.1.1 Policy: 1.2.616.1.113527.2.5.1.1 Policy: 1.3.6.1.4.1.38064.1.1.1.5 CPS:https://www.ssl.com/repository X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl X509v3 Subject Key Identifier: E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B X509v3 Key Usage: critical Digital Signature, Key Encipherment CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 87:75:BF:E7:59:7C:F8:8C:43:99 ... Timestamp : Apr 18 22:25:08.574 2019 GMT Extensions: none Signature : ecdsa-with-SHA256 30:44:02:20:40:51:53:90:C6:A2 ... Signed Certificate Timestamp: Version : v1 (0x0) Log ID : A4:B9:09:90:B4:18:58:14:87:BB ... Timestamp : Apr 18 22:25:08.461 2019 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:43:80:9E:19:90:FD ... Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 55:81:D4:C2:16:90:36:01:4A:EA ... Timestamp : Apr 18 22:25:08.769 2019 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:21:00:C1:3E:9F:F0:40 ... Signature Algorithm: sha256WithRSAEncryption 36:07:e7:3b:b7:45:97:ca:4d:6c ...
In the European Union,(advanced) electronic signatures on legal documents are commonly performed usingdigital signatures with accompanying identity certificates. However, onlyqualified electronic signatures (which require using a qualified trust service provider and signature creation device) are given the same power as a physical signature.
In theX.509 trust model, a certificate authority (CA) is responsible for signing certificates. These certificates act as an introduction between two parties, which means that a CA acts as a trusted third party. A CA processes requests from people or organizations requesting certificates (called subscribers), verifies the information, and potentially signs an end-entity certificate based on that information. To perform this role effectively, a CA needs to have one or more broadly trusted root certificates or intermediate certificates and the corresponding private keys. CAs may achieve this broad trust by having their root certificates included in popular software, or by obtaining a cross-signature from another CA delegating trust. Other CAs are trusted within a relatively small community, like a business, and are distributed by other mechanisms like WindowsGroup Policy.
Certificate authorities are also responsible for maintaining up-to-date revocation information about certificates they have issued, indicating whether certificates are still valid. They provide this information throughOnline Certificate Status Protocol (OCSP) and/or Certificate Revocation Lists (CRLs). Some of the larger certificate authorities in the market includeIdenTrust,DigiCert, andSectigo.[28]
Some major software contain a list of certificate authorities that are trusted by default.[citation needed] This makes it easier for end-users to validate certificates, and easier for people or organizations that request certificates to know which certificate authorities can issue a certificate that will be broadly trusted. This is particularly important in HTTPS, where a web site operator generally wants to get a certificate that is trusted by nearly all potential visitors to their web site.
The policies and processes a provider uses to decide which certificate authorities their software should trust are called root programs. The most influential root programs are:[citation needed]
Browsers other than Firefox generally use the operating system's facilities to decide which certificate authorities are trusted. So, for instance, Chrome on Windows trusts the certificate authorities included in the Microsoft Root Program, while on macOS or iOS, Chrome trusts the certificate authorities in the Apple Root Program.[29] Edge and Safari use their respective operating system trust stores as well, but each is only available on a single OS. Firefox uses the Mozilla Root Program trust store on all platforms.
The Mozilla Root Program is operated publicly, and its certificate list is part of theopen source Firefox web browser, so it is broadly used outside Firefox.[citation needed] For instance, while there is no common Linux Root Program, many Linux distributions, like Debian,[30] include a package that periodically copies the contents of the Firefox trust list, which is then used by applications.
Root programs generally provide a set of valid purposes with the certificates they include. For instance, some CAs may be considered trusted for issuing TLS server certificates, but not for code signing certificates. This is indicated with a set of trust bits in a root certificate storage system.
A certificate may be revoked before it expires, which signals that it is no longer valid. Without revocation, an attacker would be able to exploit such a compromised or misissued certificate until expiry.[31] Hence, revocation is an important part of apublic key infrastructure.[32] Revocation is performed by the issuingcertificate authority, which produces acryptographically authenticated statement of revocation.[33]
For distributing revocation information to clients, timeliness of the discovery of revocation (and hence the window for an attacker to exploit a compromised certificate) trades off against resource usage in querying revocation statuses and privacy concerns.[34] If revocation information is unavailable (either due to accident or an attack), clients must decide whether tofail-hard and treat a certificate as if it is revoked (and so degradeavailability) or tofail-soft and treat it as unrevoked (and allow attackers to sidestep revocation).[35]
Due to the cost of revocation checks and the availability impact from potentially-unreliable remote services,Web browsers limit the revocation checks they will perform, and will fail-soft where they do.[36]Certificate revocation lists are too bandwidth-costly for routine use, and theOnline Certificate Status Protocol presents connection latency and privacy issues. Other schemes have been proposed but have not yet been successfully deployed to enable fail-hard checking.[32]
The most common use of certificates is forHTTPS-based web sites. Aweb browser validates that an HTTPSweb server is authentic, so that the user can feel secure that his/her interaction with theweb site has no eavesdroppers and that the web site is who it claims to be. This security is important forelectronic commerce. In practice, a web site operator obtains a certificate by applying to a certificate authority with acertificate signing request. The certificate request is an electronic document that contains the web site name, company information and the public key. The certificate provider signs the request, thus producing a public certificate. During web browsing, this public certificate is served to any web browser that connects to the web site and proves to the web browser that the provider believes it has issued a certificate to the owner of the web site.
As an example, when a user connects tohttps://www.example.com/ with their browser, if the browser does not give any certificate warning message, then the user can be theoretically sure that interacting withhttps://www.example.com/ is equivalent to interacting with the entity in contact with the email address listed in the public registrar under "example.com", even though that email address may not be displayed anywhere on the web site.[citation needed] No other surety of any kind is implied. Further, the relationship between the purchaser of the certificate, the operator of the web site, and the generator of the web site content may be tenuous and is not guaranteed.[citation needed] At best, the certificate guarantees uniqueness of the web site, provided that the web site itself has not been compromised (hacked) or the certificate issuing process subverted.
A certificate provider can opt to issue three types of certificates, each requiring its own degree of vetting rigor. In order of increasing rigor (and naturally, cost) they are: Domain Validation, Organization Validation and Extended Validation. These rigors are loosely agreed upon by voluntary participants in theCA/Browser Forum.[citation needed]
A certificate provider will issue a domain-validated (DV) certificate to a purchaser if the purchaser can demonstrate one vetting criterion: the right to administratively manage the affected DNS domain(s).
A certificate provider will issue an organization validation (OV) class certificate to a purchaser if the purchaser can meet two criteria: the right to administratively manage the domain name in question, and perhaps, the organization's actual existence as a legal entity. A certificate provider publishes its OV vetting criteria through itscertificate policy.
To acquire anExtended Validation (EV) certificate, the purchaser must persuade the certificate provider of its legal identity, including manual verification checks by a human. As with OV certificates, a certificate provider publishes its EV vetting criteria through itscertificate policy.
Until 2019, major browsers such as Chrome and Firefox generally offered users a visual indication of the legal identity when a site presented an EV certificate. This was done by showing the legal name before the domain, and a bright green color to highlight the change. Most browsers deprecated this feature[37][38] providing no visual difference to the user on the type of certificate used. This change followed security concerns raised by forensic experts and successful attempts to purchase EV certificates to impersonate famous organizations, proving the inefficiency of these visual indicators and highlighting potential abuses.[39]
Aweb browser will give no warning to the user if a web site suddenly presents a different certificate, even if that certificate has a lower number of key bits, even if it has a different provider, and even if the previous certificate had an expiry date far into the future.[citation needed] Where certificate providers are under the jurisdiction of governments, those governments may have the freedom to order the provider to generate any certificate, such as for the purposes of law enforcement. Subsidiary wholesale certificate providers also have the freedom to generate any certificate.
All web browsers come with an extensive built-in list of trustedroot certificates, many of which are controlled by organizations that may be unfamiliar to the user.[1] Each of these organizations is free to issue any certificate for any web site and have the guarantee that web browsers that include its root certificates will accept it as genuine. In this instance, end users must rely on the developer of the browser software to manage its built-in list of certificates and on the certificate providers to behave correctly and to inform the browser developer of problematic certificates. While uncommon, there have been incidents in which fraudulent certificates have been issued: in some cases, the browsers have detected the fraud; in others, some time passed before browser developers removed these certificates from their software.[40][41]
The list of built-in certificates is also not limited to those provided by the browser developer: users (and to a degree applications) are free to extend the list for special purposes such as for company intranets.[42] This means that if someone gains access to a machine and can install a new root certificate in the browser, that browser will recognize websites that use the inserted certificate as legitimate.
Forprovable security, this reliance on something external to the system has the consequence that any public key certification scheme has to rely on some special setup assumption, such as the existence of acertificate authority.[43]
In spite of the limitations described above, certificate-authenticated TLS is considered mandatory by all security guidelines whenever a web site hosts confidential information or performs material transactions. This is because, in practice, in spite of theweaknesses described above, web sites secured by public key certificates are still more secure than unsecuredhttp:// web sites.[44]
The National Institute of Standards and Technology (NIST) Computer Security Division[45] provides guidance documents for public key certificates:
[...] *.a.com matches foo.a.com but not bar.foo.a.com.
For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.
Wildcard certificates are not allowed for EV Certificates.
This document states that the wildcard character '*' SHOULD NOT be included in presented identifiers but MAY be checked by application clients (mainly for the sake of backward compatibility with deployed infrastructure). [...] Several security considerations justify tightening the rules: [...]
{{cite journal}}:Cite journal requires|journal= (help)Authority control databases: National |
|---|