1867851 - SSL.com: Findings in 2023 audit

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[SSL.com]

Steps to reproduce:

Finding #1

The following finding is noted as an 'Other matter' in the SSL.com Webtrust for CA Audit Report, i.e. a finding that does not modify the auditor's opinion:

For one (1) of six (6) certificate problem reports selected for testing, SSL.com was not able to provide evidence a preliminary report on its findings was distributed to both the subscriber and the entity who files the Certificate Problem Report within twenty-four hours of the report being filed.

Actual results:

Root Cause Analysis

Our Root Cause Analysis is based on the examination of facts gathered. It is driven by our internal Security Auditors to ensure impartiality, supported by subject matter experts who provide their insight.

Based on our investigation, the Certificate Problem Report (CPR) issue referred to a DV TLS certificate that turned out to relate to an entity listed in the OFAC Sanction List.

The CPR was processed upon receipt and triggered a lot of discussions internally because of its legal nature. The practices of other CAs were also researched, especially with regards to dealing with simple DV TLS certificates issued to domain spaces of sanctioned countries [1], [2].

Detailed CPR procedures were already in place for handling several types of CPRs, however not for this specific type. In addition, our analysis revealed that the SSL.com CPR procedures, as documented, are too complex especially when one is required to handle an undocumented CPR type within the hard deadlines defined in the Baseline Requirements. In this particular case, due to the legal nature of the issue, 24 hours were not enough for us to decide whether the CPR was legitimate in the first place or not.

According to the facts gathered, CPR actions included revocation, blocklisting of the offending domain and sub-domains, and delivery of an informative report to the reporter. All these actions were completed in a timely manner and within the time constraints defined in the BRs. However, a sub-sequent check revealed that the blocklisting regular expression was effective for the offending domain but not for its subdomains. This allowed for the issuance of another certificate to a subdomain three months later which was identified and revoked in a timely manner and within the time constraints defined in the BRs.

Per our analysis, the latter is attributed to the complexity of using regular expressions for registering blocklist entries in our system combined with the lack of tools to dry-run the regular expression against offending domains and subdomains to verify the effectiveness of an entry.

Expected results:

Action Items

| Action Item | Kind | Due Date |

| ----------- | ---- | -------- |

| Revamp/streamline the internal CPR procedures | Prevent | 2024-01-31 |

| Introduce automated preliminary reporting to reporter | Prevent | 2023-10-23 (completed) |

| Introduce automated preliminary reporting to subscriber| Prevent | 2024-03-15 |

| Introduce a blocklist checker tool | Prevent, Detect | 2023-12-15 (underway) |

Comment 1

[SSL.com]

This is an update to report current progress on this issue.

Action no.4 (Introduce a blocklist checker tool) has been completed.

Unless otherwise requested, we plan to provide our next update after the holidays.

Comment 2

[SSL.com]

We would like to update the community on the progress of action item 1, the revamp/streamlining of the internal CPR procedures. The task is 70% done and expected to complete on time. We will update this bug, again, next week.

Comment 3

[SSL.com]

This is an update to report current progress on this issue.

Action no.1 has been completed. This included revamping the internal CPR process and creating working instructions for the various CPR scenarios.

Action no.3 (the introduction of automated preliminary reporting to subscriber) is underway.

A progress update shall be provided mid February.

Comment 4

[SSL.com]

With regards to the remaining action no.3, we have now completed requirements analysis and design of the automated preliminary reporting mechanism.

The mechanism will allow the submission of CPRs via the designated web form, the automatic lookup of the certificate based on its thumbprint and, if found, the instant reporting to the subscriber. A bot protection shall be put in place to protect the public-facing revocation form from abuse. The CPR notification actions shall be automatically logged by the system for audit purposes.

The above specifications were defined based on our objective to provide meaningful preliminary reporting of CPRs, taking also into account review of practices by other CAs.

We expect to complete implementation within the next 2 weeks and deploy it by the first week of April.

Comment 5

[SSL.com]

This is an update to report current progress on this issue.

Implementation of the mechanism (action no.3) has been completed. We are now moving with testing/QA as planned.

An update shall be provided in two weeks.

Comment 6

[SSL.com]

Testing/QA for action no.3 has been completed with success. A couple of improvements were identified during QA, and have already been implemented. The CPR mechanism is now able to receive a CPR, lookup the thumbprint in our certificate DB and, if it exists, provide instant preliminary reporting to both the Subscriber and the Reporter. The system also makes sure that a notification is sent to the Reporter in case the thumbprint is not found in our certificate DB.

Deployment to production will take place next week as scheduled.

Comment 7

[SSL.com]

Action no.3 (the introduction of automated preliminary reporting to subscriber) has been completed with the deployment and verification of the mechanism.

This concludes all remediation actions for this bug.

Comment 8

[Ben Wilson]

I will close this sometime later next week (i.e. Apr. 24-26).