badssl.com is an openly licensed, community-maintained collection of deliberately misconfigured TLS endpoints — served at https://badssl.com and developed in the chromium/badssl.com repository — for developers, security engineers, and browser or HTTP client authors who need to verify how their software reacts to expired, self-signed, mixed-content, and otherwise invalid certificates.
What it is
badssl.com is a publicly reachable website whose subdomains each deliberately present a different class of broken TLS or certificate configuration, so that a client can be pointed at a memorable hostname instead of a hand-built broken server. The repository holds the server configuration, the certificate sets, and the tooling that generates and serves all of it; the project is written primarily in HTML, with the supporting stack drawing on nginx, Python, and Rcpp, and it is published under the Apache-2.0 licence. It is hosted on Google Cloud infrastructure and co-maintained by April King of Mozilla Firefox, Lucas Garron (formerly of Google Chrome), and Chris Thompson of Google Chrome.
The concrete problem it solves is that testing a TLS client's error handling has traditionally meant generating bad certificates, wiring up a host to serve them, and trusting them locally — work that every team repeated separately and got subtly wrong. badssl.com replaces that ad-hoc, per-project fixture-building with one stable, memorable public set of bad configurations, and it also ships the same material as a local deployment so the endpoints can be reproduced offline.
Key capabilities
- Named test subdomains covering distinct failure modes, including
self-signed.badssl.com, expired.badssl.com, mixed.badssl.com, rc4.badssl.com, and hsts.badssl.com.
- Certificate edge cases beyond plain expiry, including
sha1-2016, sha1-2017, sha1-intermediate, invalid-expected-sct, no-subject, no-common-name, and 1000-sans / 10000-sans.
- A local deployment path driven by Docker:
make serve starts the stack and make list-hosts prints the entries to paste into the system hosts file.
- A generated local root certificate at
certs/sets/test/gen/crt/ca-root.crt, which can be trusted in the client so that badssl.test and the other subdomains resolve without a certificate error.
- macOS trust setup, either by dragging the root into Keychain Access or by running
security add-trusted-cert -r trustRoot -p ssl -k "$HOME/Library/Keychains/login.keychain" certs/sets/test/gen/crt/ca-root.crt.
- Certificate preservation across rebuilds by copying material into
certs/sets/test/pregen/crt and certs/sets/test/pregen/key so it survives make clean.
- Coverage relevant to interception and proxy testing, represented by the
mitm topic alongside ssl, tls, https, sha1, and security.
Who uses it and how
- Browser and client developers who perform manual testing of security UI in web clients, which the README states is the project's intended purpose.
- Security engineers exercising certificate validation paths, including SHA-1 rejection, wildcard handling, and subject-name edge cases.
- Contributors working on proxies and interception tooling, who need endpoints that fail in specific, reproducible ways.
- Teams that need a guaranteed, unchanging configuration for a particular use case, and who are directed by the README to fork the project and host their own copy.
- Self-hosters running the stack on a stock Ubuntu VM with DNS A records for
badssl.com. and *.badssl.com. pointing at that machine.
Getting started
Clone the repository with git clone https://github.com/chromium/badssl.com && cd badssl.com, install Docker, add the make list-hosts output to the hosts file, and run make serve; alternatively, use the already hosted endpoints at https://badssl.com.
How it compares
The provided facts name no comparable tools and no list of paid products that this project replaces, so it stands alone in this registry on that axis. What can be said from the facts is that it is Apache-2.0 licensed, self-hostable from the same repository, and free to use, with the public instance offered as-is and without warranties.
When to use it — and when not to
A self-hoster must operate Docker, a VM with DNS control over both the apex and wildcard records, and local trust installation for the generated root certificate. It is a poor fit for anyone who needs a documented guarantee or immutable fixtures, because badssl.com is explicitly meant for manual testing, most subdomains are only likely to have stable functionality, and anything could change without notice; the README's stated remedies are filing an issue or forking and hosting a private copy. The project also carries a substantial open-issue count and is not an official Google product, so support expectations should stay modest.
project readme (upstream, from github) — read inline
Visit badssl.com for a list of test subdomains, including:
Server Setup
Stock Ubuntu VM, DNS A records for badssl.com. and *.badssl.com. pointing to the VM.
Testing and development
Follow the instructions to install Docker.
Clone into the badssl repo by running git clone https://github.com/chromium/badssl.com && cd badssl.com.
In order to access the various badssl subdomains locally you will need to add them to your system hosts file. Run make list-hosts and copy and paste the output into /etc/hosts.
Start Docker by running make serve.
You can now navigate to badssl.test in your browser, and you should see a certificate error.
The badssl root certificate is at certs/sets/test/gen/crt/ca-root.crt. In order to get the rest of the badssl subdomains working, you will need to add this to your machine's list of trusted certificates.
On macOS, drag certs/sets/test/gen/crt/ca-root.crt into the login section of the program Keychain Access. A BadSSL Root Certificate Authority entry should appear in the list. Double-click on this entry and select "Always Trust" from the drop-down menu next to "Secure Sockets Layer (SSL)." Close the window to save your changes.
If you are already familiar with this process, you can instead run this command:
security add-trusted-cert -r trustRoot -p ssl \
-k "$HOME/Library/Keychains/login.keychain" certs/sets/test/gen/crt/ca-root.crt
In order to preserve the client and root certificates even after running make clean, run:
cd certs/sets/test
mkdir -p pregen/crt pregen/key
cp gen/crt/ca-root.crt pregen/crt/ca-root.crt
cp gen/crt/client.crt pregen/crt/client.crt
cp gen/crt/client-ca-root.crt pregen/crt/client-ca-root.crt
cp gen/key/ca-root.key pregen/key/ca-root.key
cp gen/key/client.key pregen/key/client.key
cp gen/key/client-ca-root.key pregen/key/client-ca-root.key
Acknowledgments
badssl.com is hosted on Google Cloud infrastructure and co-maintained by:
Several public badssl.com certificates required special issuance processes. Most certificates were graciously issued for free, thanks to help from:
- Vincent Lynch, The SSL Store (
sha1-2016, sha1-2017)
- Richard Barnes, Mozilla (
1000-sans, 10000-sans)
- Clint Wilson, DigiCert (most wildcards)
- Andrew Ayer, SSLMate (
invalid-expected-sct)
- Rob Stradling, Comodo (
1000-sans, 10000-sans, no-subject, no-common-name, sha1-intermediate, ѕрооғ)
Various subdomains and test pages are also implemented by external contributors.
Disclaimer
badssl.com is meant for manual testing of security UI in web clients.
Most subdomains are likely to have stable functionality, but anything could change without notice. If you would like a documented guarantee for a particular use case, please file an issue. (Alternatively, you could make a fork and host your own copy.)
badssl.com is not an official Google product. It is offered "AS-IS" and without any warranties.