Purpose
Use this skill when the question is whether a service's TLS posture matches expected hardening.
Phase Fit
- Primary: Vulnerability Analysis
- Secondary: Retest and Closure
Use When
- Need to assess protocol support, certificate hygiene, or TLS hardening.
- Need to validate whether an exposed HTTPS service aligns to policy.
- Need to confirm that a TLS remediation actually took effect.
Avoid When
- The target is not an approved HTTPS endpoint.
- The issue is application logic rather than transport security.
Inputs
- Approved HTTPS targets
- Expected policy baseline or accepted hardening standard
Procedure
- Test only the approved endpoints.
- Compare observed protocol and certificate posture to the agreed baseline.
- Separate material weaknesses from policy deviations with low practical impact.
- Tie results to exposed asset criticality.
- Preserve the baseline comparison for retest.
Command Syntax
Replace sample targets with approved in-scope assets.
# Full TLS assessment
./testssl.sh https://portal.contoso.com
# Fast check (skip less common ciphers)
./testssl.sh --fast portal.contoso.com:443
# Check protocols and per-protocol ciphers
./testssl.sh --protocols --cipher-per-proto portal.contoso.com:443
# Check for known TLS vulnerabilities (POODLE, BEAST, Heartbleed, etc.)
./testssl.sh --vuln portal.contoso.com:443
# Output to JSON file
./testssl.sh --jsonfile contoso-tls.json portal.contoso.com:443
# Test SMTP with STARTTLS
./testssl.sh --starttls smtp mail.contoso.com:25
# Non-standard HTTPS port
./testssl.sh portal.contoso.com:8443
Evidence to Capture
- Protocol and certificate posture for each target
- Internet-facing weaknesses that increase downgrade or interception risk
- Remediation deltas during retest
Safety Boundaries
- Keep testing limited to approved hosts.
- Report business impact in context rather than overstating raw cryptographic terminology.