A collection of test subdomains with intentionally broken SSL configurations for testing client security behavior.
badssl.com is a testing website that provides numerous subdomains with intentionally broken SSL/TLS configurations. It allows developers to test how web clients, browsers, and applications respond to various SSL certificate errors and security warnings. The project serves as a practical tool for validating client-side security behavior.
Web developers, security engineers, QA testers, and browser developers who need to test how their applications handle SSL/TLS certificate errors and security warnings.
Developers choose badssl.com because it provides a comprehensive, ready-to-use collection of real SSL misconfigurations in one place, eliminating the need to manually create test certificates. It's maintained by security professionals from major browser teams and offers reliable test cases for common SSL issues.
:lock: Memorable site for testing clients against bad SSL configs.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Offers a wide range of subdomains for expired, self-signed, mixed content, weak ciphers, HSTS, and more, as listed on badssl.com, providing real-world SSL misconfigurations in one place.
Co-maintained by security professionals from Mozilla Firefox and Google Chrome, ensuring relevance and accuracy for browser-specific testing needs.
Hosted on Google Cloud with no cost to users, making it readily available for manual testing without setup overhead for basic use.
Includes Docker-based instructions in the README for local development, allowing developers to replicate test environments by editing hosts files and adding certificates.
The disclaimer states that subdomains could change without notice, making it unreliable for automated testing or long-term integration due to potential breaking changes.
Designed primarily for manual UI testing, as per the README, lacking APIs or support for automated scripts, which limits use in continuous testing workflows.
Setting up locally requires editing system hosts files and manually adding root certificates, which can be error-prone and time-consuming compared to simpler testing tools.