Section 1

Private Keys and Certificates

1.1 Key strength

#

Correct

ECDSA P-256 (128 bits of security) or RSA 2048 (112 bits). ECDSA is preferred and faster.

Misconfigured

RSA 1024 or any sub-2048 key. CAs no longer issue against weak keys, so this is legacy or self-signed only.

Why it breaks: weak keys are factorable and offer inadequate security margin.

1.2 Certificate chain

#

Correct

Leaf plus intermediate(s) forming a valid chain to a trusted root.

Misconfigured

Leaf certificate only, or a set that does not form a valid chain.

Why it breaks: an invalid chain can render the whole TLS connection invalid. Some browsers paper over it, others do not, so it is inconsistent and hard to diagnose.

1.3 CAA records

#

Correct

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "digicert.com"
example.com. CAA 0 issuewild "entrust.com"
example.com. CAA 0 issuemail ";"
example.com. CAA 0 iodef "pki@example.com"

Misconfigured

No CAA record at all. Default policy: any CA may issue.

Why it breaks: without CAA, any CA in the world can issue a certificate for your domain, widening the attack surface for misissuance.

1.4 Certificate coverage

#

Correct

Every DNS name that points to your properties has a valid cert, including apex and www. One cert can cover related names via SAN.

Misconfigured

Cert for www.example.com but not example.com (the redirect host), or a name mismatch.

Why it breaks: certificate warnings, and with HSTS deployed, immediate hard breakage with no click-through.

1.5 Key and certificate sharing

#

Correct

Separate private keys per logical environment. No reuse of one key across unrelated services.

Misconfigured

One private key shared across unrelated services, or unrelated service domains bundled on one cert.

Why it breaks: compromise of one property exposes all the others in the shared group. Sharing across teams or systems is always bad.

1.6 Renewal and lifetime

#

Correct

Automated renewal (ACME), renew about a month early, consider short-lived certs for important properties.

Misconfigured

Manual yearly renewal.

Why it breaks: manual renewal invites expiry outages, and the yearly option disappears in March 2026 (max lifetime drops to 200 days, then 100 in 2027, then 47 in 2029).

Section 2

Protocol and Cipher Configuration

2.1 Protocol versions

#

Correct

TLS 1.3 and TLS 1.2 only.

Misconfigured

TLS 1.0 / 1.1 / SSL 3 / SSL 2 enabled.

Why it breaks: SSL 2 is fully broken and can attack even well-configured servers sharing certs or keys (DROWN). SSL 3 is insecure. TLS 1.0 and 1.1 are obsolete.

2.2 Forward secrecy

#

Correct

ECDHE key exchange on all suites.

Misconfigured

Static RSA key exchange (no forward secrecy).

Why it breaks: an adversary who records traffic and later obtains the server key can decrypt all past sessions.

2.3 Key exchange parameters

#

Correct

ECDHE with X25519 or P-256. If DHE is used at all, 2048-bit parameters minimum.

Misconfigured

DHE below 2048 bits, or well-known predefined DH groups.

Why it breaks: weak or shared DH groups are vulnerable to precomputation attacks. Anything below 1024 bits is trivially exploitable.

2.4 TLS 1.3 cipher suites

#

Correct

TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_256_GCM_SHA384

2.5 TLS 1.2 cipher suites

#

Correct

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

Misconfigured

Do not enable unless supporting Windows XP era clients.

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Why it breaks: plain RSA suites have no forward secrecy. 3DES is weak. These belong only at the very end of a list for ancient clients, never as a primary.

2.6 Server cipher preference

#

Correct

Server preference enforced, so the server picks the strongest mutually supported suite.

Misconfigured

Server takes the first suite offered by the client.

Why it breaks: a downgrade-capable client can steer the connection to a weaker suite.

2.7 Session ticket keys

#

Correct

Ticket keys configured explicitly and rotated on a schedule (for example daily).

Misconfigured

Implicit ticket key created at startup and never rotated.

Why it breaks: under TLS 1.2, knowing the ticket key lets an attacker passively decrypt all sessions. A long-lived process means a long-lived key.

Section 3

HTTP and Application Security

3.1 HSTS

Single most important improvement #

Correct

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Misconfigured

No HSTS header, or a very short max-age with no plan to raise it.

Why it breaks: without HSTS, certificate warnings are click-through-able, leaving users open to active network attacks and HTTPS stripping. Roll out incrementally (start around 300s, no preload) if you do not fully control your infra.

3.2 Secure cookies

#

Correct

Secure, HttpOnly, and __Host- or __Secure- name prefixes.

Set-Cookie: __Host-session=...; Secure; HttpOnly; Path=/; SameSite=Lax

Misconfigured

A session cookie with none of these flags.

Why it breaks: a fully encrypted site can still leak its session if cookies span HTTP, are readable by script, or can be overwritten by a subdomain.

3.3 Content Security Policy

#

Correct

A CSP that controls resource origins and can block plaintext mixed content.

Misconfigured

No CSP.

Why it breaks: no defence in depth against XSS or third-party mixed content.

3.4 Caching of sensitive content

#

Correct

Cache-Control: private, no-store

Misconfigured

Sensitive content served cacheable, or with no cache directives.

Why it breaks: intermediate proxies and CDNs may cache and, with bad config, even share sensitive responses between users.

3.5 HTTP compression awareness

#

Correct

Mask CSRF tokens with random content, adopt same-site cookies.

Misconfigured

Unmasked secrets in compressed responses.

Why it breaks: CRIME, TIME, and BREACH use compression side channels to recover secrets like CSRF tokens.

3.6 Subresource Integrity

#

Correct

SRI hash on third-party scripts and styles.

<script src="https://cdn.example.com/lib.js" integrity="sha384-..." crossorigin="anonymous"></script>

Misconfigured

Third-party script with no integrity attribute.

Why it breaks: a compromised third party becomes a backdoor into your site. SRI lets the browser reject altered resources.

Section 4

Performance

These are good practice optimisations, presented as single panels rather than good versus bad pairs.

Session resumption

Enable it. Servers that do not resume sessions are significantly slower.

TLS 1.3

Halves full handshake latency, enables 0-RTT. Note the replay caveat: not suitable for all applications.

Modern HTTP

HTTP/2 and HTTP/3 (QUIC) for connection management.

CDN

Reduces handshake latency by terminating close to the user.

Keep-alives

Reuse connections to avoid repeat handshakes.

Fast primitives

ECDSA keys plus hardware-accelerated AES. Equal-preference ChaCha20 for mobile clients (prioritize_chacha in OpenSSL).

Do not over-engineer

Target 128 bits of security. Stronger primitives just cost performance with no meaningful gain.

Section 5

Documented, Not Deployed

A Hardenize-gradeable bad site could trigger every check that exists, but some checks describe services whose only customers are abusers. This section is the line we drew.

5.1 Open recursive resolver

#

Correct

Authoritative nameservers answer only for the zones they host. They do not perform recursion for unrelated clients.

Misconfigured

The same nameserver also recurses for any client on the internet that asks. Used in reflected DNS amplification DDoS.

Why it breaks: a 60 byte query produces a multi kilobyte answer, sent to a spoofed victim address. The bandwidth multiplier is the attack.

Not deployed: standing this up would create live, abusable amplification infrastructure pointed at strangers. The teaching card is enough.

5.2 Open zone transfer (AXFR)

#

Correct

AXFR is restricted to a known list of secondary nameservers, typically by IP allowlist plus TSIG.

Misconfigured

AXFR is answered for any client. The whole zone, every name and value, is downloadable in one query.

Why it breaks: internal hostnames, dev environments, mail and admin records, anything the operator did not mean to publish individually is enumerated in one shot.

Not deployed: the harm is to the operator's own attack surface but the abuse pattern (anonymous enumeration of arbitrary zones) is what makes this an explain-only item.

5.3 SubdoMailers

#

Correct

Subdomains whose DNS no longer points at any service are removed. No host record is left dangling under a name an attacker can claim.

Misconfigured

A forgotten subdomain CNAMEs to a SaaS or hosting platform tenant that has been released. An attacker registers the tenant and sends mail that authenticates as your domain.

Why it breaks: SPF, DKIM and DMARC inherit from the parent. A reclaimed subdomain inherits trust the attacker did not have to earn.

Not deployed: this check describes real active abuse infrastructure. Standing up a live example would mean either claiming a real platform tenant (which we will not do) or describing how to.

5.4 Certificate nearing expiration

#

Correct

Certificates renew well before expiry. Monitoring alerts on time-remaining, not on already-expired.

Misconfigured

A leaf certificate within days of expiry, still in production.

Why it breaks: renewal cron failures, lost ACME accounts, or human handoffs leave the service one weekend away from a hard outage.

Not deployed: deliberately shipping a near-expiry cert means the bad site goes hard-down on a fixed date. Noisy, and the card already makes the point.

5.5 Nameserver operational failures (see broken.dangl.ing)

#

Correct

Authoritative nameservers respond authoritatively, on UDP and TCP, with names that resolve to routable IPv4 and IPv6, with PTR records, and with parent glue that matches the in-zone A/AAAA.

Misconfigured

One or more of those fails. Daemon stopped. UDP firewalled. NS name underscored. NS target on 127.0.0.1. Glue disagreeing with the in-zone A.

Why it breaks: any one of these failures masks every check downstream. A zone with no working NS resolves to nothing, so the scanner cannot grade anything else.

Demonstrated, but not on this domain: these failures live on the isolated broken.dangl.ing subdomain. Putting them on good or bad would take the whole site down and mask every other check.

Validate and Monitor

TLS config is easy to get wrong and drifts over time as platforms upgrade and certificates expire. Pair the controls above with continuous monitoring.

Use CSP reporting and Network Error Logging (NEL) for real-user visibility into mixed content, broken handshakes, and certificate problems. For inventory and posture across an estate, Red Sift Certificates tracks chains, expiry, and known weaknesses on a recurring basis.