This rule raises an issue when an SSL/TLS is configured at application level with an insecure version (ie: a protocol different from "TLSv1.2" or "TLSv1.3").
No issue is raised when the choice of the SSL/TLS version relies on the OS configuration. Be aware that the latest version of https://docs.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl\--schannel-ssp-[Windows 10 and Windows Server 2016 have TLSv1.0 and TLSv1.1 enabled by default]. Administrators can configure the OS to enforce TLSv1.2 minumum by https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings[updateing registry settings] or by applying a group policy.
* http://cwe.mitre.org/data/definitions/327.html[MITRE, CWE-326] - Use of a Broken or Risky Cryptographic Algorithm
* https://www.sans.org/top25-software-errors/#cat3[SANS Top 25] - Porous Defenses
* https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https[Diagnosing TLS, SSL, and HTTPS]
* https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#22-use-secure-protocols[SSL and TLS Deployment Best Practices - Use secure protocols]
* https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls[Transport Layer Security (TLS) best practices with the .NET Framework]