Difference between revisions of "Wild Card Certificates"

From MgmtWiki
Jump to: navigation, search
Line 18: Line 18:
<references />
===Other Material===
* [https://media.defense.gov/2021/Oct/07/2002869955/-1/-1/0/CSI_AVOID%20DANGERS%20OF%20WILDCARD%20TLS%20CERTIFICATES%20AND%20THE%20ALPACA%20TECHNIQUE_211007.PDF Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique]
* [https://media.defense.gov/2021/Oct/07/2002869955/-1/-1/0/CSI_AVOID%20DANGERS%20OF%20WILDCARD%20TLS%20CERTIFICATES%20AND%20THE%20ALPACA%20TECHNIQUE_211007.PDF Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique]
[[Category: Trust]]
[[Category: Trust]]

Revision as of 16:08, 5 November 2021

Wild Card Certificates

Wild Card Certificates allows servers with different URLs, but the same origin to use the same security certificates.


Web servers use digital certificates to establish a connection between the server and the user's computer also called the client computer, that is secure against a variety of attacks by malicious actors with a variety of motives.

  • A wildcard certificate is a single certificate with a wildcard character in the X509 certificate subject field (ex. CN = *.example.com) or subject alternative name field allowing the certificate to validate the identity of multiple subdomains of the same root domain.


  • Acquiring and maintaining certificates and secured servers is an expensive and time consuming process. Such security is not put there to gain customers but to protect the providers from losses of both money and disgruntled customers.
  • Mixed security sites allows both HTTP (unsecured) and HTTPS (secured) connections for a variety of good reasons including redirection of all traffic to a secured connection.
  • Any server that can communicate with clients using the same certificate (and hence the same same origin URL) has access to all cookies and data in any client computer that connects to the it. Increasingly the security features of the browser are shared only with services attaching to the same origin URL end points. That security can thus be breached by any server that can utilize that certificate.
  • Cybersecurity researchers have recently shown that using wildcard or other certificates that represent both HTTPS and non-HTTPS servers can lead to exploitable web vulnerabilities that don’t depend on TLS weaknesses or private key compromises. Under certain conditions, this technique, dubbed Application Layer Protocols Allowing Cross-Protocol Attacks (ALPACA)[1], allows malicious actors to exploit fault tolerance features of web browsers and servers combined with protocol confusion between HTTP and other text-based protocols protected by TLS to perform arbitrary actions and view sensitive data. While the conditions permitting this complicated technique to succeed are uncommon, ongoing research in this area is likely to identify additional configurations vulnerable to this type of malicious activity.


Most security solutions are not formulated as principles to adhere to but as checklists of things that developers must do or must avoid and so are written as heuristics that have proven valuable in the past to preventing loss. The following should be viewed as heuristics in that vein.

  1. View all the computers using the same certificate as operating in a secured enclave with the same security rules applied to every computer and every service within that enclave. While there is another heuristic that claims that security perimeters no longer can be trusted, that heuristic cannot be applied to computers and services that depend on the same certificate. Otherwise the security of all can be compromised by the weakest security server in the enclave.


  1. M. Brinkmann, + 7 ALPACA: Application Layer Protocol Confusion – Analyzing and Mitigating Cracks in TLS Authentication 2021. Available: https://alpaca-attack.com/ALPACA.pdf

Other Material