DeepViolet TLS Workbench is a free, open-source Java tool that performs deep TLS/SSL analysis of any server. In this walkthrough we will download the CLI scanner from GitHub, point it at badssl.com, and break down what the results tell us about the server’s security posture.
What Is badssl.com?
badssl.com is a well-known test site maintained by Google engineers. It hosts dozens of subdomains, each exhibiting a specific TLS misconfiguration—expired certificates, wrong hosts, weak ciphers, and more. The main www.badssl.com landing page itself uses a working certificate, but the server configuration intentionally leaves room for improvement. That makes it a perfect target for a TLS scanner demonstration.
Prerequisites
You only need one thing: Java 21 or later. Confirm your version with:
java -version
openjdk version "21.0.10" 2026-01-20
If Java is not installed, grab it from Adoptium or your system package manager (e.g., apt install openjdk-21-jre-headless).
Step 1 – Download the CLI Scanner
Head to the DeepVioletTools releases page on GitHub. The latest release (6.1.0 at the time of writing) provides two JARs:
- dvui.jar – the desktop GUI workbench
- dvcli.jar – the command-line scanner
Download the CLI jar directly with curl:
curl -L -o dvcli.jar \
https://github.com/spoofzu/DeepVioletTools/releases/download/6.1.0/dvcli.jar
Or download dvui.jar if you prefer the graphical workbench. Both produce the same analysis; the GUI simply wraps it in a visual interface with heat maps and an AI assistant.
Step 2 – Run the Scan
Point the scanner at https://www.badssl.com/:
java -jar dvcli.jar -serverurl https://www.badssl.com/
The scan completes in a few seconds and prints a full report to the terminal. You can also export results in JSON, HTML, or PDF with the -f and -o flags:
java -jar dvcli.jar -serverurl https://www.badssl.com/ -f json -o badssl-report.json
Step 3 – Understanding the Results
Here is the actual output from our scan, section by section.
TLS Risk Assessment – Grade C (77/100)
DeepViolet evaluates the server across 65 rules in 7 categories and produces a letter grade. badssl.com received a C with a score of 77 out of 100, classified as HIGH risk. Here is the category breakdown:
| Category | Score | Risk |
|---|---|---|
| Protocols & Connections | 70/100 | HIGH |
| Cipher Suites | 46/100 | HIGH |
| Certificate & Chain | 75/100 | MEDIUM |
| Revocation & Transparency | 80/100 | MEDIUM |
| Security Headers | 83/100 | HIGH |
| DNS Security | 80/100 | MEDIUM |
| Other | 90/100 | LOW |
The two weakest areas—Protocols and Cipher Suites—drag the overall score down. Let’s examine each finding.
Protocols & Connections (70/100)
Three issues were flagged:
- TLS 1.3 not supported [HIGH] – The server only negotiates TLS 1.2. TLS 1.3 removes legacy algorithms, mandates forward secrecy, and reduces the handshake to a single round trip. Any production server should support it.
- Post-quantum key exchange not supported [MEDIUM] – The server does not offer hybrid post-quantum key exchange (e.g., X25519Kyber768). While not yet required, major browsers already negotiate it when available.
- ALPN not negotiated [LOW] – Application-Layer Protocol Negotiation was not completed. This means the server is not advertising HTTP/2 support via ALPN.
Cipher Suites (46/100)
This is the lowest-scoring category and the biggest red flag:
- 6 or more WEAK ciphers offered [HIGH] – The scan found 12 ciphers rated WEAK. These include CBC-mode suites like
TLS_RSA_WITH_AES_128_CBC_SHAand the deprecatedTLS_RSA_WITH_3DES_EDE_CBC_SHA. CBC ciphers are vulnerable to padding oracle attacks (POODLE, Lucky13), and 3DES has an effective key strength of only 112 bits. - No STRONG ciphers available [HIGH] – None of the offered suites qualified as STRONG. The best available are MEDIUM-strength GCM suites like
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. To reach STRONG, the server would need TLS 1.3 suites (e.g.,TLS_AES_256_GCM_SHA384) or CHACHA20 suites. - Server honors client cipher preference [MEDIUM] – The server lets the client dictate which cipher to use. A downgrade-capable attacker could exploit this to negotiate the weakest available cipher. Best practice is to enforce server-side cipher preference.
Certificate & Chain (75/100)
The certificate itself is valid and properly chained through Let’s Encrypt R13 up to the ISRG Root X1 trust anchor. Two minor issues:
- Certificate expires in less than 90 days [MEDIUM] – At scan time, the certificate had 84 days remaining. For an automated Let’s Encrypt setup this is normal (they issue 90-day certs and renew at 30 days), but DeepViolet flags it since short runway increases the risk of an accidental expiration.
- Wildcard certificate in use [LOW] – The cert covers
*.badssl.comandbadssl.com. Wildcard certs are convenient but broaden the blast radius if the private key is compromised—any subdomain can be impersonated.
Revocation & Transparency (80/100)
- OCSP stapling not present [MEDIUM] – Without OCSP stapling, each visitor’s browser must contact the CA’s OCSP responder to check revocation status, adding latency and leaking browsing history to the CA.
- Must-Staple extension not present [LOW] – The certificate does not include the OCSP Must-Staple flag, which would force the server to provide a stapled response.
On the positive side, the CRL check returned GOOD (not revoked), and two valid Signed Certificate Timestamps (SCTs) were embedded—one from DigiCert’s Wyvern log and one from Sectigo’s Tiger log—confirming the certificate was logged to Certificate Transparency.
Security Headers (83/100)
Seven missing HTTP security headers were detected. The most significant:
- Strict-Transport-Security (HSTS) missing [HIGH] – Without HSTS, browsers will happily follow an HTTP link to the site before redirecting to HTTPS, creating a window for a man-in-the-middle downgrade attack (aka SSL stripping).
- Content-Security-Policy missing [LOW] – CSP helps prevent XSS by restricting which scripts and resources the page can load.
- X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy – all missing (LOW). These are defense-in-depth headers recommended by OWASP.
DNS Security (80/100)
- No CAA records [MEDIUM] – DNS Certification Authority Authorization records tell CAs which authorities are permitted to issue certificates for the domain. Without CAA, any CA can issue a cert for badssl.com.
- No DANE/TLSA records [LOW] – DANE allows domain owners to pin certificates via DNS, but requires DNSSEC and is not widely adopted for web servers.
TLS Fingerprint
DeepViolet sends 10 crafted TLS probes to characterize the server’s behavior. badssl.com passed 9 out of 10 probes, failing only the TLS 1.3-only probe (confirming that TLS 1.3 is not supported). The fingerprint is a compact hex string that uniquely identifies how this server responds to different handshake variations—useful for detecting configuration changes or identifying server software.
What Would a Good Score Look Like?
To bring badssl.com from a C to an A, the administrator would need to:
- Enable TLS 1.3 in nginx (just add
TLSv1.3to thessl_protocolsdirective) - Remove weak ciphers – drop all CBC and 3DES suites; keep only AEAD ciphers (GCM, CHACHA20)
- Enforce server cipher preference with
ssl_prefer_server_ciphers on - Enable OCSP stapling via
ssl_stapling onandssl_stapling_verify on - Add HSTS and other security headers
- Publish CAA records in DNS restricting issuance to Let’s Encrypt
Wrapping Up
In under a minute we downloaded DeepViolet from GitHub and generated a comprehensive TLS security assessment. The scan revealed that while badssl.com has a valid certificate and proper chain of trust, it suffers from outdated protocol support, weak cipher suites, missing security headers, and no HSTS—exactly the kind of issues that separate a passing grade from a secure one.
DeepViolet goes beyond what most online SSL checkers provide: the 65-rule risk assessment, TLS fingerprinting, Certificate Transparency verification, post-quantum readiness checks, and DNS security analysis give you a thorough picture of a server’s TLS posture from a single command.
To learn more, visit the DeepVioletTools and DeepViolet API repositories on GitHub.