!!! Overview
There are a lot of things that can go wrong with the [Public Key Infrastructure] and the related [Certificates]. Without a [Public Key Infrastructure] that has [integrity] and maintains [confidentiality] for the [Private Key] the [Public Key Infrastructure] will fail to be trustworthy.

The certification model for [X.509] [Certificates] has often been criticized, not really on technical grounds, but rather for politico-economic reasons. The certification model for [X.509] concentrates validation power into the hands of a [few players|Registration Authority], who are not necessarily well-intentioned, or at least not always competent. Now and again, proposals for other systems are published (e.g. Convergence or [DNSSEC] or [Decentralized Public Key Infrastructure]) but none has gained wide acceptance (yet).

For [certificate]-based [user-agent] [authentication], it is entirely up to the server to decide what to do with a [user-agent] [certificate] (and also what to do with a [user-agent] who __declined__ to [send a certificate|Client Send Certificate]). 

!! Security Risk of Keys Being Unprotected
If the [Private Keys] for any of the [Certificates] within the [Certificate Chain] are not properly safeguarded, digital forgery can become a major concern as the [Private Keys] is considered to be a [Bearer Tokens].

!! The [Usability] of [Public Key Infrastructure]
Even if [third-party] [certificate Authority] and the [Registration Authority] could be [trusted|Trust], the current [PKI] system has major usability problems. A group from Brigham Young University investigated the usability of Mailvelope, a [browser] extension that supports GPG-encrypted communication through third-party websites like Gmail. Their research demonstrated a 90% failure rate in secure communication attempts among the participants. [Public Key] management, the study found, was the main reason that users were unable to use the [application] correctly. [2]

Even TextSecure/[Signal] — a secure messaging system endorsed by [Edward Snowden] for its security and ease of use — has usability problems due to its inability to smoothly handle [Public Key] changes. If a user deletes and reinstalls the app, their friends are warned that their public key "fingerprint" has changed. This scenario is indistinguishable from a [Man-In-The-Middle] [attack], and few users are likely to understand or bother verifying that they received the correct [Public Key].[2]

! [user-agent] warnings[1]
''The major lesson that we’ve learned from the history of security (un-)usability is that technical solutions like PKI and access control don’t align too well with user conceptual models so that, as a pair of US government program managers with extensive PKI experience put it, "users find it easier to just turn PKI off rather than to try to figure out what actions they need to take to use it". As a result, calling in the usability people after the framework of your application or device’s security measures have been set in concrete by purely technology-driven considerations is doomed to failure, since the user interface will be forced to conform to the straightjacket constraints imposed by the security technology rather than being able to exploit the full benefits of years of usability research and experience. Security and security usability need to be baked in, not brushed on. Blaming security problems on the user when they’re actually caused by the security system design is equally ineffective, but unfortunately even now, after ten years of work on security usability, still very popular.''

User do not understand the warnings presented and how to react to such warnings. [Phishing] is also an issue for these type of [user-agent] warnings. 

[user-agent] warnings are part of a [Human Limitation] for [{$pagename}]

! No [user-agent] warning
A [user-agent] 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.

A change from an [Extended Validation Certificate] to a non-[Extended Validation Certificate] will __ONLY__ be apparent as the green bar will no longer be displayed. Where [certificate] providers, [Registration Authority] or [Certificate Authority], 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 Agency]. Subsidiary wholesale [certificate] providers also have the freedom to generate any [certificate].

!! [Registration Authority]
A [Certificate] is a [credential] and an [Identity Document] issued by a [Certificate Authority] which has (Hopefully) gone through [Credential Enrollment] by a [Registration Authority].

Typical [user-agents] come with a built-in list of [Certificate Authority], many of which are controlled by organizations that may be unfamiliar to the user. The [end-User] [trust] that the [Registration Authority] to properly perform their job of [Identity Proofing] of the [entity] during the [Credential Enrollment] to obtain the [Certificate]. Each of these [Registration Authority] is free to issue any [certificate] for any [website] and have the guarantee that [user-agents] that include its root certificates will accept it as [Authentic|Authenticity]. 

This is further complicated by the risk of coercion or [Compromised Certificate] of a [Certificate Authority]. Because of these dangers, users cannot be certain that their communications are not being compromised by a fraudulent certificate allowing a [Man-In-The-Middle] [attack]. 

In addition end users must rely on the developer of the [user-agent] software to manage its built-in list of certificates and on the [certificate providers|Registration Authority] to behave correctly and to inform the [user-agent] developer of problematic certificates. While uncommon, there have been incidents in which fraudulent certificates have been issued: 
* in some cases, the  [user-agents] have detected the fraud
* in others, some time passed before [user-agent] developers removed these [certificates] from their software.

!! Extension of [user-agents] Trusted Certificates
The list of built-in [Trust Anchors] is also not limited to those provided by the browser developer.  Users and to a degree applications are free to extend the list of [Trust Anchors] for special purposes such as for company [intranets]. This means that if someone gains access to a machine and can install a new [Trust Anchor] in the [user-agent], that [user-agent] 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 and trustworthiness the [certificate Authority] and the [Registration Authority].

!! [Certificate Validation]
Many [user-agents] may fail to properly perform [Certificate Validation]. There are some constrained environments where they may not be able to perform proper [Certificate Validation]. The [user-agent] may not have sufficient CPU or memory for these purposes. 

!! Possible Assistance for [{$pagename}]
* [Certificate Transparency]
* [Certificate Pinning]
* [DNSChain]
* [Perspectives Project]
* [Strict-Transport-Security]
* [Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)]
* [Public Key Pinning Extension for HTTP] ([RFC 7469])
* [Using the Secure Remote Password (SRP) Protocol for TLS Authentication]
* [Decentralized Public Key Infrastructure] ([DPKI])
* [Blockstack]
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Engineering Security|https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf|target='_blank'] - based on information obtained 2014-04-10
* [#2] - [Decentralized Public Key Infrastructure|https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/dpki.pdf|target='_blank'] - based on information obtained 2017-08-01
* [#3] - [Ballot SC22: Reduce Certificate Lifetimes|https://cabforum.org/pipermail/servercert-wg/2019-August/000942.html|target='_blank'] - based on information obtained 2019-08-26 
* [#4] - [The Huge Web Security Loophole That Most People Don’t Know About, And How It’s Being Fixed|https://www.fastcompany.com/3042030/the-huge-web-security-loophole-that-most-people-dont-know-about-and-how-its-be|target='_blank'] - based on information obtained 2018-12-27