Public key certificate

Last updated

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. [1] [2] 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 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. 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.

Contents

In a typical public-key infrastructure (PKI) scheme, the certificate issuer is a certificate authority (CA), [3] 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. In case of key compromise, a certificate may need to be revoked.

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


The roles of root certificate, intermediate certificate and end-entity certificate as in the chain of trust. Chain of trust v2.svg
The roles of root certificate, intermediate certificate and end-entity certificate as in the chain of trust.

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:

  1. The subject of the certificate matches the hostname (not to be confused with the domain name) to which the client is trying to connect.
  2. 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.[ clarification needed ] The hostname must be publicly accessible, not using private addresses or reserved domains. [4] 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. 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 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 and root certificates

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.

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 a root certificate , trust anchor, or trust 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 certificate

An example of a Subject Alternative Name section for domain names owned by the Wikimedia Foundation Subject Alt Names on Firefox 90 screenshot.png
An example of a Subject Alternative Name section for domain names owned by the Wikimedia Foundation

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. [6] These values are called Subject 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 the commonName field. [8] Google Chrome version 58 (March 2017) removed support for checking the commonName 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]

Wildcard certificate

An example of a wildcard certificate on comifuro.net (note the asterisk: *) Let's Encrypt example certificate on Firefox 94 screenshot.png
An example of a wildcard certificate on comifuro.net (note the asterisk: *)

A public key certificate which uses an asterisk * (the wildcard) in its domain name fragment 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 https://*.example.com will secure all these subdomains on the https://*.example.com domain:

Instead 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]

Note possible exceptions by CAs, for example wildcard-plus cert by DigiCert contains an automatic "Plus" property for the naked domain example.com.[ citation needed ]

Limitations

Only a single level of subdomain matching is supported in accordance with RFC   2818. [1]

It is not possible to get a wildcard for an Extended Validation Certificate. [14] A workaround could be to add every virtual host name in the Subject Alternative Name (SAN) extension, [15] [16] 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 subjectAltName extensions, including other wildcards. For example, the wildcard certificate *.wikipedia.org has *.m.wikimedia.org as a Subject Alternative Name. Thus it secures www.wikipedia.org as well as the completely different website name meta.m.wikimedia.org. [17]

RFC   6125 argues against wildcard certificates on security grounds, in particular "partial wildcards". [18]

Further examples

The wildcard applies only to one level of the domain name. *.example.com matches sub1.example.com but not example.com and not sub2.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 match frog.domain.com but not frog.super.domain.com
baz*.example.net is OK and matches baz1.example.net
*baz.example.net is OK and matches foobaz.example.net
b*z.example.net is OK and matches buzz.example.net

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. [20] All major browsers have deliberately removed 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.com

A cert with * plus a top-level domain is not allowed.

*.com

Too general and should not be allowed.

*

International domain names encoded in ASCII (A-label) are labels that are ASCII-encoded and begin with xn--. URLs with international labels cannot contain wildcards. [24]

xn--caf-dma.com is café.com
xn--caf-dma*.com is not allowed
Lw*.xn--caf-dma.com is allowed

Other certificates

Common fields

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.

Example

This is an example of a decoded SSL/TLS certificate retrieved from SSL.com's website. The issuer's common name (CN) is shown as SSL.com EV SSL Intermediate CA RSA R3, identifying this as an Extended Validation (EV) certificate. Validated information about the website's owner (SSL Corp) is located in the Subject field. The X509v3 Subject Alternative Name field contains a list of domain names covered by the certificate. The X509v3 Extended Key Usage and X509v3 Key Usage fields show all appropriate uses.

Usage in the European Union

In the European Union, (advanced) electronic signatures on legal documents are commonly performed using digital signatures with accompanying identity certificates. However, only qualified electronic signatures (which require using a qualified trust service provider and signature creation device) are given the same power as a physical signature.

Certificate authorities

The procedure of obtaining a Public key certificate PublicKeyCertificateDiagram It.svg
The procedure of obtaining a Public key certificate

In the X.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 Windows Group 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 through Online Certificate Status Protocol (OCSP) and/or Certificate Revocation Lists (CRLs). Some of the larger certificate authorities in the market include IdenTrust, DigiCert, and Sectigo. [28]

Root programs

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 the open 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.

Revocation

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 a public key infrastructure. [32] Revocation is performed by the issuing certificate authority, which produces a cryptographically 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 to fail-hard and treat a certificate as if it is revoked (and so degrade availability) or to fail-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 the Online 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]

Website security

The most common use of certificates is for HTTPS-based web sites. A web browser validates that an HTTPS web server is authentic, so that the user can feel secure that his/her interaction with the web site has no eavesdroppers and that the web site is who it claims to be. This security is important for electronic commerce. In practice, a web site operator obtains a certificate by applying to a certificate authority with a certificate 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 to https://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 with https://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 the CA/Browser Forum.[ citation needed ]

Validation levels

Domain validation

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).

Organization validation

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 its certificate policy.

Extended validation

To acquire an Extended 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 its certificate 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]

Weaknesses

A web 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 trusted root 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.

For provable 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 a certificate authority. [43]

Usefulness versus unsecured web sites

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 the weaknesses described above, web sites secured by public key certificates are still more secure than unsecured http:// web sites. [44]

Standards

The National Institute of Standards and Technology (NIST) Computer Security Division [45] provides guidance documents for public key certificates:

See also

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed name service that provides a naming system for computers, services, and other resources on the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). ITU-T was formerly known as the Consultative Committee for International Telephony and Telegraphy (CCITT). X.500 was first approved in 1988. The directory services were developed to support requirements of X.400 electronic mail exchange and name lookup. The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) were partners in developing the standards, incorporating them into the Open Systems Interconnection suite of protocols. ISO/IEC 9594 is the corresponding ISO/IEC identification.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

The Domain Name System Security Extensions (DNSSEC) is a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed. The process employs the use of a cryptographic hash to validate authenticity and integrity. Code signing was invented in 1995 by Michael Doyle, as part of the Eolas WebWish browser plug-in, which enabled the use of public-key cryptography to sign downloadable Web app program code using a secret key, so the plug-in code interpreter could then use the corresponding public key to authenticate the code before allowing it access to the code interpreter's APIs.

<span class="mw-page-title-main">Extended Validation Certificate</span> X.509 public key certificate

An Extended Validation (EV) Certificate is a certificate conforming to X.509 that proves the legal entity of the owner and is signed by a certificate authority key that can issue EV certificates. EV certificates can be used in the same manner as any other X.509 certificates, including securing web communications with HTTPS and signing software and documents. Unlike domain-validated certificates and organization-validation certificates, EV certificates can be issued only by a subset of certificate authorities (CAs) and require verification of the requesting entity's legal identity before certificate issuance.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

GlobalSign is a certificate authority and a provider of internet identity and security products. As of January 2015, Globalsign was the 4th largest certificate authority in the world, according to Netcraft.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

<span class="mw-page-title-main">DigiCert</span> Internet security company

DigiCert, Inc. is a digital security company headquartered in Lehi, Utah. DigiCert provides public key infrastructure (PKI) and validation required for issuing digital certificates or TLS/SSL certificates, acting as a certificate authority (CA) and trusted third party.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

<span class="mw-page-title-main">Automatic Certificate Management Environment</span> Protocol to manage public key certificates

The Automatic Certificate Management Environment (ACME) protocol is a communications protocol for automating interactions between certificate authorities and their users' servers, allowing the automated deployment of public key infrastructure at very low cost. It was designed by the Internet Security Research Group (ISRG) for their Let's Encrypt service.

<span class="mw-page-title-main">Domain-validated certificate</span> X.509 public key certificate

A domain validated certificate (DV) is an X.509 public key certificate typically used for Transport Layer Security (TLS) where the domain name of the applicant is validated by proving some control over a DNS domain. Domain validated certificates were first distributed by GeoTrust in 2002 before becoming a widely accepted method.

References

  1. 1 2 3 Wildcard SSL certificate limitation on QuovadisGlobal.com
  2. ↑ Alrawais, Arwa; Alhothaily, Abdulrahman; Cheng, Xiuzhen; Hu, Chunqiang; Yu, Jiguo (2018-06-01). "SecureGuard: A Certificate Validation System in Public Key Infrastructure". IEEE Transactions on Vehicular Technology. 67 (6): 5399–5408. doi:10.1109/TVT.2018.2805700. ISSN   0018-9545. S2CID   49270949. Archived from the original on 2022-08-26. Retrieved 2022-08-26.
  3. ↑ Chadwick, David W; Basden, Andrew (2001-10-31). "Evaluating Trust in a Public Key Certification Authority". Computers & Security. 20 (7): 592–611. doi:10.1016/S0167-4048(01)00710-6. ISSN   0167-4048. Archived from the original on 2022-02-26. Retrieved 2022-02-26.
  4. ↑ "Internal names". DigiCert Documentation.
  5. ↑ "Free SSL Certificate | IONOS by 1&1". www.ionos.co.uk. Archived from the original on 2022-07-18. Retrieved 2022-07-15.
  6. ↑ "x509v3_config - X509 V3 certificate extension configuration format". OpenSSL . Retrieved 2020-01-16.
  7. ↑ RFC   5280: 4.2.1.6. Subject Alternative Name
  8. 1 2 Medley, Joseph (March 2017). "Deprecations and Removals in Chrome 58". Google Inc. Retrieved 2022-01-04.
  9. ↑ "Common Name (CN) for a wildcard certificate". DigiCert Documentation.
  10. ↑ "Wildcard and SAN: Understanding Multi-Use SSL Certificates" (PDF). Thawte. 2013.
  11. ↑ "Wildcard Certificate Explained in Simpler Terms". 23 May 2016.
  12. ↑ "RFC 2818 - HTTP Over TLS". Internet Engineering Task Force. May 2000. p. 5. Retrieved 2014-12-15. [...] *.a.com matches foo.a.com but not bar.foo.a.com.
  13. ↑ Newman, C. (June 1999). RFC 2595 - Using TLS with IMAP, POP3 and ACAP. Internet Engineering Task Force. p. 3. doi: 10.17487/RFC2595 . RFC 2595 . Retrieved 2014-12-15. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.
  14. ↑ "Guidelines For The Issuance And Management Of Extended Validation Certificates, Version 1.5.2" (PDF). CA/Browser Forum. 2014-10-16. p. 10. Retrieved 2014-12-15. Wildcard certificates are not allowed for EV Certificates.
  15. ↑ x509v3_config Subject Alternative Name
  16. ↑ The SAN option is available for EV SSL Certificates on Symantec.com
  17. ↑ SSLTools Certificate Lookup of Wikipedia.org's wildcard ssl certificate
  18. ↑ Saint-Andre, P.; Hodges, J. (March 2011). RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). Internet Engineering Task Force. p. 31. doi: 10.17487/RFC6125 . RFC 6125 . Retrieved 2014-12-10. 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: [...]
  19. ↑ Rescorla, E. (May 2000). "RFC 2818 - HTTP Over TLS". tools.ietf.org. doi: 10.17487/RFC2818 . RFC 2818 . Retrieved 2019-04-20.
  20. ↑ Saint-Andre, P.; Hodges, J. (March 2011). "RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)". tools.ietf.org. doi: 10.17487/RFC6125 . RFC 6125 . Retrieved 2019-04-20.
  21. ↑ "Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling". The Chromium Projects, Google Inc. 3 December 2014. Retrieved 21 October 2020.
  22. ↑ "Limit wildcard DNS ID support to names of the form *.example.com (not foo*.example.com)". The Mozilla Foundation. 10 December 2014. Retrieved 21 October 2020.
  23. ↑ "Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling". The Python Software Foundation. 26 November 2017. Retrieved 21 October 2020.
  24. ↑ "Restrictions on data entries for public certificates". DigiCert Documentation.
  25. ↑ "EMV CA". EMV Certificate Authority Worldwide. 2 December 2010. Archived from the original on 4 July 2020. Retrieved January 20, 2020.
  26. ↑ "X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA)" (PDF). Archived (PDF) from the original on 2021-03-18. Retrieved 2021-05-07.
  27. ↑ "X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA)" (PDF). Archived (PDF) from the original on 2021-03-18. Retrieved 2021-05-07.
  28. ↑ "Usage Statistics and Market Share of SSL Certificate Authorities for Websites, May 2020". w3techs.com. Archived from the original on 2022-06-30. Retrieved 2020-05-01.
  29. ↑ "Root Certificate Policy – The Chromium Projects". www.chromium.org. Archived from the original on 2017-03-20. Retrieved 2017-03-19.
  30. ↑ "ca-certificates in Launchpad". launchpad.net. 30 April 2010. Archived from the original on 2017-03-20. Retrieved 2017-03-19.
  31. ↑ Smith, Dickinson & Seamons 2020, p. 1.
  32. 1 2 Sheffer, Saint-Andre & Fossati 2022, 7.5. Certificate Revocation.
  33. ↑ Chung et al. 2018, p. 3.
  34. ↑ Smith, Dickinson & Seamons 2020, p. 10.
  35. ↑ Larisch et al. 2017, p. 542.
  36. ↑ Smith, Dickinson & Seamons 2020, p. 1-2.
  37. ↑ "Firefox-dev Google group - Intent to Ship: Move Extended Validation Information out of the URL bar". groups.google.com. Archived from the original on 2020-08-12. Retrieved 2020-08-03.
  38. ↑ "Chrome Security-dev Google group - Upcoming Change to Chrome's Identity Indicators". groups.google.com. Archived from the original on 2020-06-07. Retrieved 2020-08-03.
  39. ↑ "Extended Validation Certificates are (Really, Really) Dead". troyhunt.com. 12 August 2019. Archived from the original on 2020-07-16. Retrieved 2020-08-03.
  40. ↑ "DigiNotar removal by Mozilla". Mozilla.org. 2 September 2011. Archived from the original on 3 June 2012. Retrieved 30 July 2012.
  41. ↑ "DigitNotar removal by Google". Archived from the original on 13 September 2011. Retrieved 30 July 2012.
  42. ↑ "Using certificates article at Mozilla.org". Mozilla.org. Archived from the original on 12 July 2012. Retrieved 30 July 2012.
  43. ↑ Ran Canetti: Universally Composable Signature, Certification, and Authentication. CSFW 2004, http://eprint.iacr.org/2003/239 Archived 2009-08-28 at the Wayback Machine
  44. ↑ Ben Laurie, Ian Goldberg (18 January 2014). "Replacing passwords on the Internet AKA post-Snowden Opportunistic Encryption" (PDF). Archived (PDF) from the original on 27 October 2014. Retrieved 15 November 2014.{{cite journal}}: Cite journal requires |journal= (help)
  45. ↑ "NIST Computer Security Publications – NIST Special Publications (SPs)". csrc.nist.gov. Archived from the original on 2017-09-17. Retrieved 2016-06-19.
  46. ↑ "SP 800-32 Introduction to Public Key Technology and the Federal PKI Infrastructure" (PDF). National Institute of Standards and Technology. Archived (PDF) from the original on 2018-06-05. Retrieved 2016-06-19.
  47. ↑ "SP 800-25 Federal Agency Use of Public Key Technology for Digital Signatures and Authentication" (PDF). National Institute of Standards and Technology. Archived (PDF) from the original on 2018-06-02. Retrieved 2016-06-19.

Works cited

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.