I am currently in the process of reporting a large number of certificates with compromised keys.
CAs have to provide a problem reporting mechanism in the CCADB, and GoDaddy provides the mail address [email protected] for reporting.

However, this mail address does not accept mail attachments. I have been trying to send them a collection of compromised keys, first as a tarball, then as a zip. Each time, I get a response that their mail address does not accept the attachment type.

There may be workarounds for this (e.g., I could try to send the keys in the mail body, or some form of textual proof of compromise). But generally, I believe CAs should not be allowed to create needless friction or make it difficult to report certificate compromises.

If GoDaddy wants to avoid a followup delayed revocation incident, they may contact me and inform me about a working way to provide them a large number of compromised keys.

Thank you for alerting us to this problem with our email settings on the practices@ email address we use for problem reporting. We are actively looking into resolving this issue to allow for file extensions to be sent to the email address. In the meantime, I have reached out directly to attempt receiving the list of compromised keys to process further.

Thanks, Steven.

Some time ago, in bug 1886626, certSIGN had an incident due to spam filters on the CPR submission address preventing valid reports from coming through. Could you briefly describe what GoDaddy did when reviewing that incident to ensure that they were not similarly affected?

(In reply to Mike Shaver (:shaver emeritus) from comment #2)

Thanks, Steven.

Some time ago, in bug 1886626, certSIGN had an incident due to spam filters on the CPR submission address preventing valid reports from coming through. Could you briefly describe what GoDaddy did when reviewing that incident to ensure that they were not similarly affected?

Thank you for your question. Our process in reviewing other CA compliance bugs is to understand the root cause and review our own setups, infrastructure, etc to verify that we are not susceptible to a similar incident. Upon review of Bug 1886626, we noted that the root cause of this bug was related to spam/junk email filtering. At the time of our bug review, we verified that our practices@ email configuration does allow spam/junk email through to the inbox and these messages are manually reviewed by our validation specialists.

In the case of this particular issue (our current bug), the issue for the reporter in this case was due to email bounce and quarantine related to malware scanning. We are actively working on an incident report which will be posted here: https://bugzilla.mozilla.org/show_bug.cgi?id=1942877 and will have some more details of what caused this particular issue. Hope this helps in the meantime!

(In reply to Brittany Randall from comment #3)

Upon review of Bug 1886626, we noted that the root cause of this bug was related to spam/junk email filtering. At the time of our bug review, we verified that our practices@ email configuration does allow spam/junk email through to the inbox and these messages are manually reviewed by our validation specialists.

In the case of this particular issue (our current bug), the issue for the reporter in this case was due to email bounce and quarantine related to malware scanning.

I guess I can see that reasoning, but I have to say it’s a little disappointing that the lesson GoDaddy took away from bug 1886626 was so narrow, rather than “ensure that there is nothing that can block an email to the CPR address”. In hindsight, does GoDaddy feel that its approach to addressing the issue surfaced in bug 1886626 was sufficiently thorough?

I’m hoping that the action items from bug 1942877–and from other CAs following this incident!—will be a little more…holistic in terms of removing impediments to CPR delivery. It would be very disappointing to have another incident due to some other technically-not-identical type of email filtering, whether by GoDaddy or another CA.

I think it's almost impossible to "ensure that there is nothing that can block an email to the CPR address”. We would need a mail system that will accept gigabyte attachments of any form and doesn't do any malware or content scanning. Isn't it acceptable for the community that some mails get rejected? Of course the bounce mechanism has to work properly to inform the sender that the mail was not delivered and maybe even why it was blocked.

I personally think that accepting all emails puts the recipient at a much higher risk to get infected, to have mailboxes flooded (and real CPRs being overlooked)... than the small inconvenience of a sender to have to retry using a different attachment format or size.

-Roman

We have proposed a solution that will address the problems with email in the action items on the full report posted here - https://bugzilla.mozilla.org/show_bug.cgi?id=1942877. If there is further discussion required on the proposed solution we encourage feedback on that bug.

We have a full report drafted and are monitoring https://bugzilla.mozilla.org/show_bug.cgi?id=1942877, would it be appropriate to close this one as a duplicate?

Instead of closing this as a duplicate, I can make closure of this bug "depend on" closure of the other one. Unless there is anything particularly important for this bug, I will expect all activity to happen in Bug #1942877.

There's an expectation of weekly status updates to all non-closed incidents.
There have not been recent updates to Bug #1949895, Bug #1942241, Bug# 1924992
In similar cases, the lack of updates is itself cause to file a separate incident report.

We continue to monitor this thread daily for any questions or comments. A related bug has our full incident report and is also closely monitored. We have provided an update to our action items on this today.

Report Closure Summary

• Incident description: An early discussion to a full incident around email issues for reporting certificate problems
• Incident Root Cause(s): Email malware scanning blocked emails with certain file attachments
• Remediation description: See https://bugzilla.mozilla.org/show_bug.cgi?id=1942877 .
• Commitment summary: See https://bugzilla.mozilla.org/show_bug.cgi?id=1942877 .

All Action Items disclosed in this report have been completed as described, and we request its closure.

This is a final call for comments or questions on this Incident Report.

Otherwise, this bug will be closed on approximately 2025-05-08.