Open-Source Testing · chromium

badssl.com

badssl.com is a Chromium-hosted testing site that serves deliberately misconfigured SSL/TLS endpoints to help developers and QA teams verify how their clients handle certificate errors. It provides a live, stable resource with test subdomains covering expired certs, self-signed certs, weak algorithms (RC4, SHA1), mixed content, and HSTS policies.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/chromium/badssl.com

GitHub stars

204

Forks

HTML

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	chromium/badssl.com
Owner	chromium
Primary language	HTML
License	Apache-2.0 — OSI-approved
Stars	3k
Forks	204
Open issues	207
Latest release	Unknown
Last updated	2026-06-01
Source	https://github.com/chromium/badssl.com

What badssl.com is

badssl.com runs on Google Cloud infrastructure and exposes a range of intentionally broken TLS configurations (expired certificates, self-signed chains, weak ciphers, missing SANs, invalid SCTs) via nginx. The repo includes Docker-based setup, certificate generation tooling, and test harnesses; it is maintained by contributors from Mozilla and Google Chrome teams.

Quickstart

Get the badssl.com source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/chromium/badssl.com.git2cd badssl.com3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Client certificate validation testing

Verify that web browsers, HTTP clients, and custom applications correctly reject or warn on expired, self-signed, or untrusted certificates before deployment.

TLS security feature verification

Test implementation of HSTS, OCSP stapling, SCT validation, and detection of weak ciphers (RC4, SHA1) to ensure your client enforces modern TLS standards.

QA and regression testing

Maintain a stable, documented set of bad TLS states for continuous integration pipelines and manual security acceptance testing across client applications.

Implementation considerations

Requires Docker and local DNS/hosts configuration to test locally; the make serve setup automates most steps but requires trusting test CA root certificates in your system keychain.
Test certificates are pre-generated but can be regenerated; preserve client and root keys using the pregen/ workflow if you need stability across make clean operations.
Public badssl.com subdomains are stable for most common test cases (self-signed, expired, weak ciphers) but may be reissued or updated; confirm expected certificate details before integrating into automated tests.
Integration with CI/CD pipelines should treat badssl.com as a live external dependency; consider local forking or containerization if you need hermetic or offline testing.

When to avoid it — and what to weigh

Production certificate authority — badssl.com is explicitly for *manual* testing only. Do not use it as a source of truth for certificate pinning, automated policy enforcement, or production infrastructure.
Guaranteed SLA or availability requirements — The project includes a disclaimer that functionality and certificates may change without notice and is offered 'AS-IS' without warranties. Not suitable for mission-critical compliance or audit evidence.
Private or air-gapped testing — badssl.com is a public internet service requiring DNS resolution and external connectivity. Not suitable for offline, isolated, or restricted-network test environments.
Custom certificate scenarios — While comprehensive, badssl.com covers common bad TLS cases but may not expose every edge case your application needs to handle; consider forking if you need specific test certificates.

License & commercial use

badssl.com is licensed under Apache License 2.0 (Apache-2.0), a permissive, OSI-approved open-source license that permits commercial use, modification, and redistribution with proper attribution and inclusion of the license text.

Apache-2.0 is permissive and allows commercial use. However, the project is co-maintained by Mozilla and Google as a public testing resource; commercial reliance should account for the lack of SLA, the explicit disclaimer of warranties, and the possibility of unannounced changes. Hosting your own fork or variant is recommended for mission-critical commercial deployments.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Low
DEV.co fit	Good
Assessment confidence	High

Security considerations

badssl.com deliberately hosts invalid TLS configurations to test error handling; this is by design for security testing. When testing against it, ensure your test harnesses and CI/CD systems do not accidentally trust or bypass these failures. The test CA root certificate should be stored securely and used only in isolated test environments, never in production or shared infrastructure. Verify that any automated cert pinning or validation code does not mistake badssl.com test certificates for real ones.

Alternatives to consider

OWASP ZAP / Burp Suite proxy

Full-featured security testing platforms with custom certificate and intercept capabilities; better for comprehensive security assessment but heavier-weight and requires licensing for some modules.

Let's Encrypt staging environment

Provides real (but untrusted) certificates for non-prod testing; suitable if you need valid TLS chains but not explicit failure scenarios like expired or self-signed certs.

Self-hosted nginx with custom certs

Complete control over certificate generation and failure modes; suitable if badssl.com does not cover your specific edge cases or you require air-gapped testing.

Software development agency

Build on badssl.com with DEV.co software developers

badssl.com is a free, open-source resource ideal for manual TLS validation testing. Contact our team to discuss integration into your CI/CD, security testing strategy, or custom certificate testing requirements.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

web-check tlsfuzzer goss

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Testing Web Application Development API Development Talk to DEV.co

badssl.com FAQ

Can I use badssl.com in production?

No. badssl.com is explicitly for manual testing of clients and security UIs. Certificates and behavior may change without notice, and the service is offered AS-IS without SLA or warranty.

Do I need to trust the badssl test CA to use the public service?

No for the public site—browsers will show certificate warnings as expected. For local testing via Docker, you must add the test CA root certificate to your system keychain to avoid errors on the remaining subdomains.

How do I integrate badssl.com into CI/CD?

Point your test suite at badssl.com subdomains via HTTP(S) requests (e.g., self-signed.badssl.com). Since it is a live external service, handle network dependency and expect occasional cert reissuance. For reproducible, offline CI, host your own fork.

What if badssl.com does not have a test case I need?

File an issue in the GitHub repo, or fork and host your own copy. The Docker setup and certificate generation tools are included; you can generate custom bad certs for your edge cases.

Custom software development services

DEV.co helps companies turn open-source tools like badssl.com into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source testing stack.

Evaluate badssl.com for Your Security Testing

Talk to DEV.co Schedule a Consultation