- September 11, 2023: Separated finding messages.
- April 20, 2023: 2023 RAU weight adjustment & grading when there are no findings.
- January 4, 2023: Recommendations if no SNI is specified.
For the TLS/SSL Certificates risk vector, we look at a variety of criteria when determining the effectiveness of TLS/SSL certificates and their implementation. Companies should have up-to-date certificates with any domains interacting with sensitive data.
|Field||Description||Details & Values|
|Finding Behavior||How findings behave, depending on the action taken.||
Findings with a certificate serial number identical to the previous record are considered to be the same finding.
|Lifetime||The number of days a finding will impact the risk vector grade, assuming nothing changes in the future and the finding is not updated with new information. Learn why findings have a decay and lifetime period.||60 Days|
|No Findings||The letter grade if there are no findings or only Neutral findings for this risk vector.||
Some findings cannot be traced back to specific companies due to the use of third party systems; such as web filters and Content Delivery Networks (CDN), that are capable of redirecting and encapsulating network traffic. Some firewalls might also be detecting and blocking external data gathering tools from getting any data. This is set in the center of the grading scale for computing into Bitsight Security Ratings.
If there are no findings and we are temporarily unable to collect data, the most recent grade is assigned for up to 400 days before being assigned the default grade.
|Refresh||The Bitsight platform regularly checks for new observations. Bitsight findings are updated as these observations change, e.g., newly observed Diligence findings or an existing finding was remediated.|
|Automated Scan Duration||The duration of a regularly scheduled finding refresh, as the Bitsight platform checks for new observations.||60 Days|
|User-Requested Refresh Duration||The duration of a user-requested refresh, which initiates a refresh of eligible findings upon request. This is recommended when a change in the finding is expected, such as when a finding has been remediated.||
If the certificate has a new serial number, the previous finding will have an Asset Not Reached refresh status.
|Weight||Out of 70.5% in Diligence.||10%|
In order to be graded as GOOD, a certificate must adhere to the following industry-standard practices:
- Certificate validity:
- Today’s date must fall within the valid dates for the certificate. If a certificate is expired or if it goes into effect in the future, any data sent to or from the host may be insecure.
- Apple, Google, and Mozilla no longer trust certificates that were issued on or after September 1, 2020 and have a validity duration greater than 398 days. Certificates issued on or after September 1, 2020 that have a validity period of more than 398 days are graded as WARN.
- The certificate must be issued by a trusted certificate authority. Certificate authorities must be in at least two of the following stores to be considered as “trusted”: Microsoft, MacOS, Google Android, Mozilla NSS.
- The key must be generated using a secure algorithm, such as RSA, DSA or elliptic curve.
- Keys must be the recommended length or longer. For RSA and DSA keys, a length of 2048 bits is recommended; for elliptic curve keys (EC), a length of 224 bits is recommended.
- The certificate must be signed using a secure algorithm. MD2, MD5 and SHA1 are considered insecure.
- Providing a self-signed or untrustworthy certificate for connecting clients, such as not specifying a Server Name Indication (SNI), is a practice that denotes poor security and should be avoided. See recommendations.
TLS/SSL Certificate findings are evaluated as GOOD, FAIR, WARN, or BAD. Not all attributes are weighted evenly; some messages may be more serious and affect the overall grade more than other, similarly graded messages.
See finding messages.