Open Bug 1942270 Opened 12 days ago Updated 5 days ago

SSL.com: Revocation process requires submission to a form that is unusable

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: hanno, Assigned: rebeccak)

Details

(Whiteboard: [ca-compliance] [policy-failure])

I have tried to report a certificate with a compromised key to ssl.com. It appears their process is very problematic, and I have been unable to report the compromised cert according to their requirements.

CCADB lists these as problem reporting mechanisms for SSL.com:
support@ssl.com, https://www.ssl.com/revoke/

I reported it via email, including the cert and the private key, so at this point SSL.com should have all the information to confirm that the key is compromised. I received a reply stating that I should report it via https://ssl.com/revoke

This form requires a "Certificate Thumbprint", but is not specific on what that means. I first assumed this would be the certificate fingerprint, as given by openssl (default options). This turned out to be incorrect, while the form submission was accepted, I received an automated email reply stating: "The thumbprint you submitted doesn't match any SSL.com certificates."
I furthermore tried the certificate's serial number and the sha256 hash of the certificate, as those are common "identifiers" of certificates. In both cases, I received the same error.

I believe this is unacceptable. Reporting a security incident with a certificate should not require guessing how to report it. Furthermore, if a problem reporting mail address is provided in CCADB, that mail address should be able to receive reports of compromised keys/certificates.

Assignee: nobody → rebeccak
Status: NEW → ASSIGNED
Type: defect → task
Whiteboard: [ca-compliance] [policy-failure]

Hi Hanno,

Thank you for submitting this report to provide useful feedback regarding our reporting mechanisms and the CPR webpage form.

Our review found that your submission to report a compromised key was processed within the required timeline, the compromised certificate was revoked, and the relevant reports were sent according to our processes. The investigation also confirmed that the relevant teams were immediately notified of all requests and that the process is operating effectively.

Although our review did not confirm any violation to our CPS, we agree that there is room for usability improvements in our CPR intake form, and we plan to make those in the upcoming weeks.

Hi Rebecca, Hanno,

Could either of you clarify whether you think SSL.com responded to the problem reports in the way that is expected from a CA by the BR, specifically BR section 4.9.5 where notification of the subscriber about the investigation is required?

Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report. After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate.

From the issue description it seems like SSL.com did not "provide a preliminary report on its findings to [...] the entity who filed the CPR" - or at least not a very accurate one (lacking an affirmative response that this was indeed a key compromise); and no information indicates that SSL.com did "work with [...] any entity reporting the Certificate Problem Report [...] to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate".

Hi Matthias-

SSL.com has complied with BR Section 4.9.5 including notifying both the Subscriber and Reporter in this CPR event. While there was some confusion caused by crosstalk involving the original support representative who received Hanno's email and the team lead who took ownership of the issue, the request was handled within the required timeline. Below is a timeline of events pertaining to the CPR:

All times are UTC.

2025-01-17:

  • 7:00: SSL.com received an email from reporter regarding a certificate with a compromised key.

  • 8:05: SSL.com sent out a preliminary report to reporter.

  • 8:10: SSL.com sent out a preliminary report to subscriber.

  • 10:10 to 10:15: Alerts received for 3 CPRs of the same reporter through our CPR web form (all related to the same key/certificate).

  • 12:55: Certificate was revoked.

  • 12:57: Emailed reporter to inform certificate has been revoked.

  • 12:58: Emailed subscriber to inform certificate has been revoked.

You need to log in before you can comment on or make changes to this bug.