INinnoying·Oct 20, 2026
I've opened up a PR adding an example certificate generated using these keys to https://badssl.com - https://github.com/chromium/badssl.com/pull/559
In eMudhra intermediate CA compromisechromium
badssl.com
HTML2015–2026
chromium / badssl.com
badssl.com
:lock: Memorable site for testing clients against bad SSL configs.
6Distinct people
6Mentions
0Explicit recommenders
3.1KGitHub stars
What to know before exploring
What it is
:lock: Memorable site for testing clients against bad SSL configs.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year6 dated mentions
Observed mentions: 2015-09-08 16:16:06 UTC to 2026-10-20 18:08:40 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
6 sourcesLooks like the cert for extended-validation.badssl.com expired (and not deliberately!)
Edit: known issue https://github.com/chromium/badssl.com/issues/516
In Badssl.com (2017)I'm using Ruby on Rails for most of my web applications. It's very rare that you don't rely on the core wrapper classes that detect all of these network and system errors for you.
So when you receive an invalid request, most of the time the client gets back the appropriate HTTP status code (e.g. bad request when the bytes do not match the size of the request).
When you send an HTTP request e.g. to a payment provider, you need to take care of possible exceptions. This is a bit tricky, since it's hard to know all possible exceptions in advance and need to decide:
* You want to be noticed about the exception
* You want to ignore the exception
* You want to run additional code e.g. a re-try
With this background the workflow is as following:
* Watch for unhandled exceptions in production / staging
* Stub the exception, write a test and handle
Read the rest
the error
Returning back to your application: When I understand it correctly, this would only help developers, that e.g. build their own web server or web framework. So I see the number of users for such a service very limited. And nit: I like the approach to have such a service running locally in a docker container like it is possible for https://github.com/chromium/badssl.com, so you can use it for automated testing without network access.
I think you're right but missing the context: badssl.com was setup as a resource for security engineers who are running tests. It's great for that and it allows the kind of fine-grained testing which anyone who is developing software, configuring firewalls or group policy, etc. would want — i.e. if you do anything which consumes HTTPS, why not take the time to add a step to your CI process which prevents accidental regressions?
The dashboard (https://badssl.com/dashboard/) is very new — see https://github.com/chromium/badssl.com/issues/257 — and as the person who opened that issue, my context was different: that conversation started among a group of U.S. federal government employees who are often in the situation of needing to use a MITM SSL proxy for compliance reasons and don't directly control it, often lacking even the ability to inst
Read the rest
all software on their primary workstation (not without cause, given the threat model). Being able to run tests in a browser and send the helpdesk a single link saying “These three boxes should not be red, please file high-priority ticket with the network group” is really useful for getting changes through quickly.
Src code: https://github.com/lgarron/badssl.com
Credit to moviuro for sharing @ https://news.ycombinator.com/item?id=10186516
In Bad SSLNope, it's not: https://github.com/lgarron/badssl.com
In Httpbin – HTTP Client Testing Service