Most TLS findings in a scan report are noise, and two or three are worth a change window. Knowing which is which saves weeks of arguing with a hosting provider about cipher suites nobody can exploit. The NCSC’s guidance on using TLS to protect data sets a clear baseline, and anything below it deserves attention while everything above it usually does not.
The findings that genuinely matter
Start with anything that lets an attacker read or alter traffic today. Support for SSLv3 or TLS 1.0 falls into that group, and RFC 8996 formally deprecated both in March 2021, while the payment card industry required TLS 1.0 to be gone from cardholder environments back in June 2018. An expired certificate matters because staff learn to click through the warning, which trains them to ignore the one warning that would have mattered. A certificate with a key that appears in a public repository matters more than either. Weak Diffie-Hellman parameters and export grade ciphers belong on the list as well, though they have become rare.
The findings that usually do not
A scanner will flag things it cannot rank, and your team should rank them. TLS 1.1 still enabled alongside 1.2 and 1.3 rates as a compliance issue rather than an attack path. SWEET32 against a 3DES cipher requires an implausible volume of traffic through a single connection. Self-signed certificates on internal management interfaces are ordinary and often intentional. The judgement call is whether an attacker can do something with the finding this quarter, and a scanner cannot make that call for you.
“The certificate finding I actually care about is the one nobody scanned, because the host was not in the range you gave us. Certificate transparency logs are public, so we search them at the start of every job and routinely find test and staging sites the client had forgotten were online. Search your own domains in those logs before an attacker does it for you.”
William Fieldhouse, Director, Aardwolf Security Ltd
What certificates reveal about the rest of your estate
Certificates are a public inventory of your infrastructure whether you like it or not. Every certificate issued by a public authority is logged, complete with the hostnames it covers. A wildcard certificate hides individual names, which is one argument for using them, but wildcards create their own problem: the same key ends up on a dozen servers, and the least protected of those defines the security of all the rest. Subject alternative names on a single certificate often reveal internal naming conventions, development hosts and the name of a supplier’s platform. External network penetration testing usually starts with exactly this data, because it is free and it is accurate.
Keeping renewal from becoming an incident
Automate renewal, then monitor the automation. Expiry outages nearly always trace back to a certificate outside the automated process, on an appliance or a load balancer that somebody renewed by hand in 2023. Build an inventory that includes expiry dates and owners, alert well before the date rather than on it, and treat any manual renewal as a small piece of technical debt. If you are choosing a specialist penetration testing company for perimeter work, ask whether their report separates exploitable issues from configuration hygiene, because a list of two hundred undifferentiated TLS findings helps nobody.
Frequently asked questions about TLS findings
These come up whenever an external report lands with a long encryption section.
Does an A rating from an online scanner mean you are secure?
It means your transport configuration is tidy. The application behind it can still leak data through an unauthenticated endpoint, and the rating will stay at A while it does.
How long should certificates last?
Shorter than they used to. Public certificate lifetimes are falling steadily, so build a process that copes with frequent renewal now rather than one that depends on annual manual work.
