Closed Bug 1942270 Opened 8 months ago Closed 5 months 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:
RESOLVED INVALID

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.

SSL.com considers this bug complete and should be closed as "invalid".

Unless there are additional comments or issues raised, I will close this as "invalid" on Wed. 12-Feb-2025.

Flags: needinfo?(bwilson)

I don't think this is a good reaction from ssl.com.

From what I can tell, the form at https://www.ssl.com/revoke/ now says "Fingerprint" instead of "Thumbprint", but that is still very ambiguous. There are multiple different ways how to define and display a fingerprint of an X.509 certificate (SHA1 vs. SHA256, pure hex values or hex values separated by ":"). There's a placeholder in the form that looks like a SHA1 hex value. But as someone reporting a certificate problem, IMHO, it should not be my job to guess what kind of fingerprint ssl.com is expecting here.

At the very least, I would suggest that if the form expects a certificate fingerprint, it should explicitly document the type/format of the fingerprint that is expected. I would furthermore suggest to give an example of how to generate such a fingerprint with commonly available tools like openssl.

I'll hold this open until SSL.com confirms that they have updated the instructions on their website for the expected format of the fingerprint.

It would also be good to ensure that the form can accept precertificate fingerprints, since sometimes the final certificate is not known.

It would also be good to ensure that the form can accept precertificate fingerprints, since sometimes the final certificate is not known.

In some cases it doesn't even exist. It is only presumed to exist.

Thank you for your responses and the additional suggestions. Though the recent small additions to the CPR form were made to provide some clarity, SSL.com will continue to improve the online submission form. We are looking at supporting other certificate identifiers and adding more user guidance as suggested.

SSL.com will provide more details on or before 2025-02-24.

Updates to our CPR submission form have been prepared and are currently in code review and testing. This update is scheduled to move to production by next week and will be in the next update to our site.

These updates will include:

  • Acceptance of multiple certificate identifiers and formats including fingerprint_sha1, fingerprint_md5, fingerprint_sha256, serial_decimal, and serial_hex
  • Improvements in the notification messages sent to the reporter and the subscriber
  • Guidance for reporters on how to generate a certificate identifier.

SSL.com will provide an update next week once the update is deployed into production.

SSL.com continues to work on the CPR submission form code review and will require additional time to move to production. We will provide an update next week.

SSL.com's online CPR submission form has been updated to provide several options to a reporter for identifying the affected certificate (see Comment 11 above). Guidance is also provided to the reporter, in the form of a linked web page, to assist in locating / calculating the related certificate identifier (fingerprint or serial number).

While we will continue to improve our CPR tools and guidance we provide to the public, these should not block closure of this bug as "invalid".

I have a question regarding this

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
…
Furthermore, if a problem reporting mail address is provided in CCADB, that mail address should be able to receive reports of compromised keys/certificates.

From the timeline given by SSL.com I don’t understand if the original email was acted upon, and would have been sufficient.

In the timeline provided, the CPR Hanno attempted to make via email is called an email and not a CPR which his attempts using the web form are called.
(In reply to Rebecca Kelley from comment #3)

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.

It’s all very confusing, and I hope that we can get some clarity.

Flags: needinfo?(rebeccak)

(In reply to Zacharias from comment #14)
Hi Zacharias,

The original email sent from Hanno was handled as a CPR and the following actions were triggered as a result:

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

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

Although the original email was acted on and would have been sufficient, there was confusion caused by internal crosstalk involving the original support representative who received Hanno's email, and the team lead who took ownership of the issue. This led to the representative requesting submission through our CPR webpage, while the team lead proceeded with the key compromise investigation and eventual revocation of the reported certificate.

SSL.com continues to monitor all submissions through our online CPR form and continues to train our support staff to assist all customers efficiently and correctly during interaction times of review and investigation.

Flags: needinfo?(rebeccak)

Unless there are any other questions, we propose that this bug be closed as "invalid".

I intend to close this as Invalid on or about Friday, 4-April-2025, unless there are explanations that make sense as to why it should not be closed as such.

Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Flags: needinfo?(bwilson)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.