CAPEC-459
Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
On this page
Alternatively, the second certificate could be a signing certificate. Thus the adversary is able to start their own Certification Authority that is anchored in its root of trust in the legitimate Certification Authority that has signed the attacker's first X.509 certificate. If the original Certificate Authority was accepted by default by browsers, so will the Certificate Authority set up by the adversary and any certificates that it signs. As a result, the adversary is able to generate any SSL certificates to impersonate any web server, and the user's browser will not issue any warning to the victim. This can be used to compromise HTTPS communications and other types of systems where PKI and X.509 certificates may be used (e.g., VPN, IPSec).
Ask an AI about this attack pattern
Show the prompt
Explain the attack pattern CAPEC-459: Creating a Rogue Certification Authority Certificate: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/459.html and https://cve.bz/cve/capec/459?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.
How the attack unfolds
Experiment
They probe what they found.
[Craft Certificates] The adversary crafts two different, but valid X.509 certificates that when hashed with an insufficiently collision resistant hashing algorithm would yield the same value.
[Send CSR to Certificate Authority] The adversary sends the CSR for one of the certificates to the Certification Authority which uses the targeted hashing algorithm. That request is completely valid and the Certificate Authority issues an X.509 certificate to the adversary which is signed with its private key.
Exploit
They carry out the attack.
[Insert Signed Blob into Unsigned Certificate] The adversary takes the signed blob and inserts it into the second X.509 certificate that the attacker generated. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob is valid in the second certificate. The result is two certificates that appear to be signed by a valid certificate authority despite only one having been signed.
Prerequisites
Certification Authority is using a hash function with insufficient collision resistance to generate the certificate hash to be signed
Skills required
- High skill
Understanding of how to force a hash collision in X.509 certificates
- High skill
An attacker must be able to craft two X.509 certificates that produce the same hash value
- Medium skill
Knowledge needed to set up a certification authority
Resources required
Knowledge of a certificate authority that uses hashing algorithms with poor collision resistance
A valid certificate request and a malicious certificate request with identical hash values
Consequences
| Impact | Affects | Note |
|---|---|---|
| Gain Privileges | Access Control, Authentication |
Mitigations
Certification Authorities need to stop using deprecated or cryptographically insecure hashing algorithms to hash the certificates that they are about to sign. Instead they should be using stronger hashing functions such as SHA-256 or SHA-512.
Weaknesses it exploits
- CWE-290 Authentication Bypass by Spoofing
- CWE-295 Improper Certificate Validation
- CWE-327 Use of a Broken or Risky Cryptographic Algorithm
Recent CVEs with these weaknesses
- 9.1CVE-2026-82509
V programming language standard library net.http through version 0.5.2 prior to commit 4077484 contains a TLS certificate validation bypass vulnerability that allows on-path attackers to intercept HTTPS traffic by exploiting the default fa…
- 6.9CVE-2026-112165
The LaserGest mobile application disables TLS certificate and hostname verification via setServerTrustMode("nocheck"), allowing a man-in-the-middle attacker to intercept or modify network traffic, including credentials and API communicatio…
- 6.0CVE-2026-112168
The Magistra software uses weak custom encryption, relies on an outdated compression algorithm to protect the database, and contains embedded secrets.
- 6.8CVE-2026-78537
IBM Guardium Key Lifecycle Manager 4.1, 4.1.1, 4.2, 4.2.1, 5.0, and 5.1 could allow a local attacker to obtain sensitive information due to the use of a weak cryptographic algorithm.
- 5.9CVE-2026-14435
IBM Turbonomic kubeturbo agent 8.16.0 through 8.20.3 does not validate or improperly validates TLS certificate validation, which could allow an attacker to obtain sensitive information using man in the middle techniques.
- 5.9CVE-2026-14434
IBM Turbonomic kubeturbo agent 8.16.0 through 8.21.2 does not validate or improperly validates TLS certificate validation, which could allow an attacker to obtain sensitive information using man in the middle techniques.
- 5.9CVE-2026-14375
IBM Storage Scale 5.2.3.0 through 5.2.3.8, and 6.0.1.0 does not validate or improperly validates TLS certificate validation when communicating with remote cluster GUI interfaces, which could allow an attacker to inject forged JSON response…
- 8.9CVE-2026-123587
The DNSSEC validation in the Hickory DNS hickory-net crate 0.26.0 before 0.26.2 identifies wraparound NSEC records by comparing the next domain name to an SOA record in the response, accepting that SOA even if it fails validation. Attacker…
The newest records naming one of them. Each weakness's page lists them all.
Related attack patterns
- Part of
- CAPEC-473 Signature Spoof
Examples
MD5 Collisions
MD5 Collisions
The MD5 algorithm is not collision resistant, allowing attackers to use spoofing attacks to create rogue certificate Authorities.
See also: CVE-2004-2761
SHA1 Collisions
SHA1 Collisions
The SHA1 algorithm is not collision resistant, allowing attackers to use spoofing attacks to create rogue certificate Authorities.
See also: CVE-2005-4900
PKI Infrastructure vulnerabilities
PKI Infrastructure vulnerabilities
Research has show significant vulnerabilities in PKI infrastructure. Trusted certificate authorities have been shown to use weak hashing algorithms after attacks have been demonstrated against those algorithms. Additionally, reliable methods have been demonstrated for generated MD5 collisions that could be used to generate malicious CSRs.
MITRE's words, unchanged: CAPEC-459 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.