HTTPS / TLS Configuration Audit
A focused audit of how your endpoint negotiates TLS and serves HTTPS — for teams who need more than an "A+" badge. We test protocol versions, cipher selection and forward secrecy, the full certificate chain and revocation, HSTS/preload, mixed content and response security headers, then hand you a prioritized fix list mapped to Mozilla and NIST baselines.
What we test
Protocol version enumeration
We probe SSLv2/SSLv3/TLS1.0/1.1/1.2/1.3 support and flag any negotiation of TLS 1.0/1.1 or SSL, which are deprecated (RFC 8996) and disallowed by PCI DSS and NIST SP 800-52r2.
Cipher suites & forward secrecy
We enumerate offered suites per protocol, verify ECDHE/DHE key exchange for forward secrecy, and flag RC4, 3DES, CBC-mode legacy, NULL, EXPORT and anonymous suites plus weak DH params (<2048-bit).
Certificate chain & validity
We validate the leaf, intermediates and chain order, key size and signature algorithm (flagging SHA-1 and RSA <2048), expiry window, SAN/hostname match and any self-signed or untrusted-root conditions.
Revocation: OCSP & stapling
We check OCSP responder reachability, OCSP stapling and must-staple, plus CRL availability — so a revoked certificate is actually rejected rather than silently trusted.
HSTS & preload
We verify Strict-Transport-Security presence, a max-age of at least one year, includeSubDomains and preload eligibility, and confirm the header is only served over HTTPS as the spec requires.
Redirect hardening & mixed content
We confirm HTTP permanently redirects to HTTPS before any sensitive response, and scan pages for active/passive mixed content (http:// scripts, styles, images) that breaks the trust boundary.
Known TLS attack exposure
We test for BEAST, POODLE, Heartbleed (CVE-2014-0160), ROBOT, CRIME/BREACH, Sweet32, LOGJAM, FREAK and renegotiation flaws using safe, testssl-class detection — no exploitation of live data.
Response security headers
We review CSP (including upgrade-insecure-requests), X-Content-Type-Options, X-Frame-Options/frame-ancestors, Referrer-Policy and Permissions-Policy for gaps that undermine the transport layer.
Methodology
- 1
Scope & discovery
We confirm authorization and in-scope hosts/ports, then enumerate every TLS-terminating endpoint — apex, www, API subdomains, load balancers and CDN edges — since config often drifts between them.
- 2
Automated baseline scan
We run testssl.sh-class tooling and Mozilla Observatory-style checks against each endpoint to capture protocols, cipher order, cert data and headers as reproducible evidence.
- 3
Manual verification
We manually confirm findings — negotiating specific suites, walking the chain, checking stapling behavior — to eliminate scanner false positives before they reach your report.
- 4
Baseline mapping & rating
Each finding is scored against Mozilla Intermediate/Modern and NIST SP 800-52r2, with CVSS where a CVE applies, so severity reflects a real standard rather than a tool's letter grade.
- 5
Reporting & fix guidance
You get a prioritized report with exact remediations — cipher strings, HSTS directives, chain fixes — plus copy-ready config for nginx/Apache/HAProxy or your CDN.
- 6
Re-test & verification
After you remediate, we re-scan the changed endpoints and issue an updated attestation confirming the baseline is met — included within the re-test window.
Standards & references
What you get
- Executive summary — One-page risk overview with the current Mozilla/NIST posture and the few changes that move the needle — written for management and auditors.
- Technical findings report — Per-endpoint detail: protocols, full cipher list, certificate chain, headers, each finding with severity, evidence and reproduction steps.
- Copy-ready remediation — Hardened config snippets for nginx/Apache/HAProxy/CDN — cipher strings, TLS 1.2+ only, OCSP stapling, HSTS and preload submission guidance.
- Re-test attestation — A signed post-fix verification letter confirming the target meets the agreed baseline — usable for compliance and customer security reviews.
FAQ
How long does a TLS audit take and what does it cost?+
A single hostname is typically completed within 1–2 business days; a set of related endpoints (apex, www, a handful of API subdomains) within 3–5. Pricing is fixed per scope based on the number of TLS-terminating endpoints, so you know the cost before we start rather than paying by the hour.
What do you need from us to begin?+
Just the hostnames/IPs and ports in scope, and written authorization from the domain or infrastructure owner. The audit is performed against your public TLS endpoint, so no source code, credentials or agent installs are required — though telling us about upstream CDNs or WAFs helps us test each layer accurately.
Is this safe to run against production?+
Yes. The checks are configuration and negotiation probes plus safe, non-destructive vulnerability detection (testssl-class). We do not exploit findings, exfiltrate data, or send meaningful load. Heartbleed and similar tests use benign detection that does not read memory or damage the service.
Do you include a re-test after we fix the issues?+
Yes. One re-test of the remediated endpoints is included within a defined window (typically 30 days) and produces an updated attestation. If you need continuous coverage as certs rotate and configs drift, we also offer scheduled monitoring.
Will you just give me an SSL Labs grade?+
No. Letter grades hide real risk — a site can score "A" while still lacking HSTS preload, stapling or a correct chain. We map every finding to Mozilla and NIST SP 800-52r2 and prioritize by actual impact, with exact fixes rather than a badge.
Do you also check HTTP security headers?+
Yes. Transport security is undermined if the response layer is weak, so we review HSTS, CSP (including upgrade-insecure-requests), X-Frame-Options/frame-ancestors, X-Content-Type-Options, Referrer-Policy and Permissions-Policy, and flag mixed content that breaks the HTTPS trust boundary.