1. Introduction
Secure online communication relies heavily on X.509 certificates, which authenticate websites and encrypt connections. These certificates are encoded using ASN.1 and processed by various TLS libraries. However, the parsing of X.509 certificates is not uniform across different implementations. Errors in parsing can lead to security vulnerabilities, as seen in OpenSSL and other major libraries.
We investigated six major TLS libraries to evaluate their behavior when processing real-world certificates. Over 186 million certificates from a public dataset were tested to uncover inconsistencies in parsing results. The study »ParsEval: Evaluation of Parsing Behavior using Real-world Out-in-the-wild X.509 Certificates« found significant differences between libraries, with some rejecting more than 13% of certificates due to parsing errors. These inconsistencies can impact system security and interoperability, making it crucial for developers and security engineers to understand how their chosen libraries handle certificate parsing.
2. Understanding the Basics: X.509, ASN.1, and TLS Libraries
2.1. What is an X.509 Certificate?
X.509 is the standard format for public key certificates used in SSL/TLS encryption. It contains details such as the subject’s identity, for example, a website domain, and the issuing Certificate Authority (CA). Additionally, it includes the public key associated with the entity as well as metadata like expiration dates and usage constraints. These certificates are vital for HTTPS security, digital signatures, and authentication mechanisms.
2.2. ASN.1 and Parsing Challenges
Abstract Syntax Notation One (ASN.1) is a standard for encoding structured data. X.509 certificates use ASN.1, making them flexible but also complex. Different TLS libraries implement ASN.1 parsers in varying ways, leading to discrepancies in how they interpret certificates. Some may fail to recognize certain certificate fields, while others reject certificates due to strict parsing rules.
2.3. The Role of TLS Libraries
TLS libraries such as OpenSSL, Mbed TLS, and wolfSSL handle secure communications. They must parse X.509 certificates correctly to ensure proper authentication and encryption. Any inconsistency in parsing can create security risks, which include the possibility of accepting malformed certificates that could potentially allow spoofing attacks or rejecting valid certificates, which could cause connectivity issues.
3. Methodology: How the Study Was Conducted
3.1. Selection of Libraries
The study analyzed six widely used TLS libraries, namely OpenSSL, GnuTLS, Go standard library (stdlib), Mbed TLS, wolfSSL, and Python-cryptography. These libraries were chosen due to their widespread use in security-critical applications and their open-source availability.
3.2. Testing Process
The researchers obtained over 186 million real-world certificates from a public dataset. Each certificate was processed using the selected TLS libraries, with error messages and parsing inconsistencies logged and categorized. Additionally, the performance of each library was measured to determine how efficiently certificates were parsed.
4. Key Findings: How Different Libraries Handle X.509 Parsing
4.1. Error Rates
The study found significant variation in error rates across libraries. WolfSSL and Mbed TLS rejected over 13% of certificates, whereas Go stdlib and GnuTLS had an error rate of only 0.02 – 0.03%. OpenSSL had the lowest error rate, at just 0.003%, indicating that it accepts almost all certificates.
4.2. Common Parsing Issues
The errors encountered were categorized into different types. Some issues were related to ASN.1 parsing, where problems in certificate encoding caused failures. Others involved unsupported cryptographic algorithms, where certain encryption methods were not recognized by specific libraries. Another category included value errors, where certificates were rejected due to invalid parameters such as incorrect RSA public key values.
4.3. Library-Specific Observations
The results highlighted key differences among the libraries. OpenSSL was the most lenient, accepting nearly all certificates without additional validation. In contrast, wolfSSL and Mbed TLS were the most restrictive, failing to parse a large percentage of certificates due to strict validation rules. The Go standard library rejected certificates based on logical errors, such as malformed domain names. Python-cryptography showed stricter ASN.1 parsing compared to OpenSSL.
5. Implications for Cybersecurity
These findings highlight critical challenges in the TLS ecosystem. Security risks arise when some libraries accept certificates they shouldn’t, increasing the risk of man-in-the-middle attacks. Interoperability issues can also occur, as differences in parsing behavior may cause connection failures between systems using different TLS implementations. The lack of consistency suggests a need for better conformity testing to ensure secure and reliable certificate handling.
6. Handling Parsing Errors
The ParsEval paper introduces an approach for testing X.509 parsing modules and classifying their errors. We believe that unified parsing errors across multiple implementations will improve the traceability of errors that might otherwise remain undetected. By categorizing errors, we created a structured way to compare different libraries and uncover weaknesses in existing implementations.
To improve the reliability of TLS implementations, we recommend that developers and security professionals create and maintain automated tests that verify the conformity of libraries as extensively as possible. This approach will help to improve the overall security ecosystem by reducing inconsistencies and vulnerabilities in X.509 certificate parsing.
7. Conclusion
TLS libraries play a crucial role in securing internet communication, but inconsistencies in X.509 parsing present challenges. Organizations relying on digital certificates must carefully choose their TLS implementations and test them for compatibility. The findings from our research emphasize the need for improved conformity testing and security analysis of certificate parsers.
If you are developing security-critical products or managing IT infrastructure, understanding your TLS library’s behavior is essential. Interested in learning more? Reach out to the Fraunhofer AISEC research team to discuss how our expertise can help secure your systems.
Authors

Tobias Specht
Tobias Specht is an IT security researcher in the field of penetration testing and static code analysis with a focus on the embedded and automotive domain. He has been working at Fraunhofer AISEC since 2018 and has contributed to industry and research projects such as the gallia framework.
Contact: tobias.specht@aisec.fraunhofer.de

Sebastian N. Peters
Sebastian N. Peters has been an IT security researcher at Fraunhofer AISEC since 2021, after completing master’s degrees in electrical engineering and information technology and in economics at RWTH Aachen University.
He is doing his doctorate at the Technical University of Munich on industrial cyber security with a focus on authentication, trust establishment, protocol security and critical infrastructure.
Contact: sebastian.peters@aisec.fraunhofer.de

Stefan Tatschner
Stefan Tatschner joined the Fraunhofer AISEC in 2015. His research focus is penetration and software testing in the automotive domain.
Contact: stefan.tatschner@aisec.fraunhofer.de