Public key certificate

Last updated
Client and server certificate of *.wikipedia.org Client and Server Certificate.png
Client and server certificate of *.wikipedia.org

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the ownership of a public key. [1] The certificate includes information about the key, 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 signature is valid, and the software examining the certificate trusts the issuer, then it can use that 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), usually a company that charges customers 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.

The most common format for public key certificates is defined by X.509. [2] 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.svg
The roles of root certificate, intermediate certificate and end-entity certificate as in the chain of trust.

TLS/SSL server certificate

In TLS (an updated replacement for SSL), a server is required to present a certificate as part of the initial connection setup. A client connecting to that server will perform the certification path validation algorithm:

  1. The subject of the certificate matches the hostname (i.e. domain name) to which the client is trying to connect;
  2. The certificate is signed by a trusted certificate authority.

The primary hostname (domain name of the website) is listed as the Common Name in the Subject field of the certificate. A certificate may be valid for multiple hostnames (multiple websites). Such certificates are commonly called Subject Alternative Name (SAN) certificates or Unified Communications Certificates (UCC). These certificates contain the field Subject Alternative Name, though many CAs will 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.

A TLS server may be configured with a self-signed certificate. When that is the case, clients will generally be unable to verify the certificate, and will terminate the connection unless certificate checking is disabled.

As per the applications, SSL certificates can be classified into three types: [3]

TLS/SSL client certificate

Client certificates are less common than server certificates, and are used to 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. Also, because authentication is usually managed by the service provider, client certificates are not usually issued by a public CA that provides server certificates. Instead, the operator of a service that requires client certificates will usually operate their own internal CA to issue them. Client certificates are supported by many web browsers, but most services use passwords and cookies to authenticate users, instead of client certificates.

Client certificates are more common in RPC systems, where they are used to authenticate devices to ensure that only authorized devices can make certain RPC calls.

Email certificate

In the S/MIME protocol for secure email, senders need to discover which public key to use for any given recipient. They get this information from an email 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.

EMV certificate

EMV payment cards are preloaded with a card issuer certificate, signed by the EMV certificate authority [4] to validate authenticity of the payment card during the payment transaction. The EMV CA certificate is loaded on ATM or POS card terminals and is used for validating the card issuer certificate.

Code signing certificate

Certificates can also be used to validate signatures on programs 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.

Root certificate

A self-signed certificate used to sign other certificates. Also sometimes called a trust anchor.

Intermediate certificate

A certificate used to sign other certificates. An intermediate certificate must be signed by another intermediate certificate or a root certificate.

End-entity or leaf certificate

Any certificate that cannot be used to sign other certificates. For instance, TLS/SSL server and client certificates, email certificates, code signing certificates, and qualified certificates are all end-entity certificates.

Self-signed certificate

A certificate with a subject that matches its issuer, and a signature that can be verified by its own public key. Most types of certificate can be self-signed. Self-signed certificates are also often called snake oil certificates to emphasize their untrustworthiness.

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.

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

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

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. [5]

Root programs

Some major software contain a list of certificate authorities that are trusted by default. 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:

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. [6] 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. For instance, while there is no common Linux Root Program, many Linux distributions, like Debian, [7] 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.

Certificates and 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. 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. 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.

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 [8] [9] 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. [10]

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. [11] [12]

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. [13] 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. [14]

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. [15]

Standards

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

See also

Related Research Articles

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It is used 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 Telecommunications Union (ITU-T). ITU-T was formerly known as the Consultative Committee for International Telephony and Telegraphy (CCITT). X.500 was approved first 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) was a partner in developing the standards, incorporating them into the Open Systems Interconnection suite of protocols. ISO/IEC 9594 is the corresponding ISO identification.

In cryptography and computer security, a man-in-the-middle, monster-in-the-middle, machine-in-the-middle, monkey-in-the-middle (MITM) or person-in-the-middle (PITM) attack is a cyberattack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other. One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within the reception range of an unencrypted Wi-Fi access point could insert themselves as a man-in-the-middle.

Transport Layer Security (TLS), and its now-deprecated predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. Several versions of the protocols are widely used in applications such as email, instant messaging, and voice over IP, but its use as the Security layer in HTTPS remains the most publicly visible.

Public key infrastructure

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. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.

In cryptography, X.509 is a 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. An X.509 certificate contains a public key and an identity, and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key.

In cryptography, a certificate authority or certification authority (CA) is an entity that 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.

CAcert.org is a community-driven certificate authority that issues free public key certificates. As of July 2016, CAcert had over 334,000 verified users and had issued over 1,285,000 certificates. CAcert.org heavily relies on automation and therefore issues only Domain-validated certificates.

In cryptography and computer security, a self-signed certificate is a security certificate that is not signed by a certificate authority (CA). These certificates are easy to make and do not cost money. However, they do not provide all of the security properties that certificates signed by a CA aim to provide. For instance, when a website owner uses a self-signed certificate to provide HTTPS services, people who visit that website will see a warning in their browser. Website visitors who bypass such warnings are exposed to a risk that a third party could intercept traffic to the website using the third-party's own self-signed certificate. This is a type of man-in-the-middle (MitM) attack, and it allows the third party to read and modify all data sent to or from the website by the target user.

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.

An Extended Validation Certificate (EV) 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.

DigiCert, Inc. is an American technology company focused on digital security and headquartered in Lehi, Utah with international offices in Australia, Ireland, Japan, India, South Africa, Switzerland and United Kingdom. As a certificate authority (CA) and trusted third party, DigiCert provides the public key infrastructure (PKI) and validation required for issuing digital certificates or TLS/SSL certificates. These certificates are used to verify and authenticate the identities of organizations and domains and to protect the privacy and data integrity of users’ digital interactions with web browsers, email clients, documents, software programs, apps, networks and connected IoT devices. According to independent survey company Netcraft, "DigiCert is the world's largest high-assurance certificate authority, commanding 60% of the Extended Validation Certificate market, and 96% of organization-validated certificates globally."

The Certification Authority Browser Forum, also known as CA/Browser Forum, is a voluntary consortium of certification authorities, vendors of Internet browser software, operating systems, and other PKI-enabled applications that promulgates industry guidelines governing the issuance and management of X.509 v.3 digital certificates that chain to a trust anchor embedded in such applications. Its guidelines cover certificates used for the SSL/TLS protocol and code signing, as well as system and network security of certificate authorities.

StartCom was a certificate authority founded in Eilat, Israel, and later based in Beijing, People's Republic of China, that had three main activities: StartCom Linux Enterprise, StartSSL and MediaHost. StartCom set up branch offices in China, Hong Kong, the United Kingdom and Spain. Due to multiple faults on the company's end, all StartCom certificates were removed from Mozilla Firefox in October 2016 and Google Chrome in March 2017, including certificates previously issued, with similar removals from other browsers expected to follow.

Wildcard certificate

In computer networking, a wildcard certificate is a public key certificate which can be used with multiple sub-domains of a domain. The principal use is for securing web sites with HTTPS, but there are also applications in many other fields. Compared with conventional certificates, a wildcard certificate can be cheaper and more convenient than a certificate for each sub-domain. Multi-domain wildcard certificates further simplify the complexity and reduce costs by securing multiple domains and their sub-domains.

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 launched on April 12, 2016.

A domain validated certificate (DV) is an X.509 digital 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 "List of certificates included by Mozilla". Mozilla.org. Retrieved 30 July 2012.
  2. "Using Client-Certificate based authentication with NGINX on Ubuntu - SSLTrust". SSLTrust. Retrieved 26 March 2019.
  3. "Types of SSL Certificate". comparecheapssl.com. Retrieved 2018-11-20.
  4. "EMV CA". EMV Certificate Authority Worldwide. 2 December 2010. Retrieved January 20, 2020.
  5. "Usage Statistics and Market Share of SSL Certificate Authorities for Websites, May 2020". w3techs.com. Retrieved 2020-05-01.
  6. "Root Certificate Policy – The Chromium Projects". www.chromium.org. Retrieved 2017-03-19.
  7. "ca-certificates in Launchpad". launchpad.net. Retrieved 2017-03-19.
  8. "Firefox-dev Google group - Intent to Ship: Move Extended Validation Information out of the URL bar". groups.google.com. Retrieved 2020-08-03.
  9. "Chrome Security-dev Google group - Upcoming Change to Chrome's Identity Indicators". groups.google.com. Retrieved 2020-08-03.
  10. "Extended Validation Certificates are (Really, Really) Dead". troyhunt.com. Retrieved 2020-08-03.
  11. "DigiNotar removal by Mozilla". Mozilla.org. Retrieved 30 July 2012.
  12. "DigitNotar removal by Google" . Retrieved 30 July 2012.
  13. "Using certificates article at Mozilla.org". Mozilla.org. Retrieved 30 July 2012.
  14. Ran Canetti: Universally Composable Signature, Certification, and Authentication. CSFW 2004, http://eprint.iacr.org/2003/239
  15. Ben Laurie, Ian Goldberg (18 January 2014). "Replacing passwords on the Internet AKA post-Snowden Opportunistic Encryption" (PDF).Cite journal requires |journal= (help)
  16. "NIST Computer Security Publications – NIST Special Publications (SPs)". csrc.nist.gov. Retrieved 2016-06-19.
  17. "SP 800-32 Introduction to Public Key Technology and the Federal PKI Infrastructure" (PDF). National Institute of Standards and Technology.
  18. "SP 800-25 Federal Agency Use of Public Key Technology for Digital Signatures and Authentication" (PDF). National Institute of Standards and Technology.