Closed Bug 1648997 Opened 6 years ago Closed 5 years ago

Actalis: inaccurate value in stateOrProvinceName

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: adriano.santoni, Assigned: adriano.santoni, NeedInfo)

Details

(Whiteboard: [ca-compliance] [ov-misissuance] [ev-misissuance])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Actual results:

This is a preliminary report.

  1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

On Sat, 27 Jun 2020 12:14 (CEST), we received a email from some George (george@fozzie.dev) alerting us of a few SSL Server certificates containing "München" (instead of "Bayern") in stateOrProvinceName.

  1. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

(all times are CEST)
27 Jun 2020 13:21 We replied to the reporter and started investigating the issue.
27 Jun 2020 15:09 We found that the reported issue was true; we then informed the Subscriber about the case, reminding them of the rules and the deadline for revocation.
27 Jun 2020 16:20 We planned a call with the Subscriber on June 29 morning to define the timing for revocation of the affected certificates.

  1. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

This is still under investigation.

  1. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

Three certificates were affected, all related to the same subscriber; the first was issued on July 4, 2019, the last was issued on July 16, 2019. All of them had a 1-year validity, so they are all close to expiration.

  1. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

https://crt.sh/?id=1979521051&opt=cablint
https://crt.sh/?id=1979521042&opt=cablint
https://crt.sh/?id=1707856388&opt=cablint

  1. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

This is still under investigation.

  1. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

This is pending completion of our investigation.

Next update planned by June 29, EOB.

Assignee: bwilson → adriano.santoni
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance] Next Update - 29-June 2020

I received your preliminary report on Sunday 28th June at 12:52 UTC (25 hours and 30 minutes after the initial report), is there a reason why you didn't send your preliminary report when you contacted the subscriber (or at least within 24 hours)?

Sorry George, my bad. It was Sunday, it was difficult to get in touch with some of our internal stakeholders, and I also had a connectivity outage at some point; I sent you our preliminary report as soon as I could.

We have ascertained that the root cause was a human error: a vetting operator evidently accepted "München" instead of "Bayern" as the stateOrProvince name, probably misled by the inaccurate application form submitted by our customer, thereby generating an inaccurate organization record in our database. Our procedure requires carefully checking all the address details, but apparently on that particular occasion there was an oversight; therefore the value "München" remained stored in our database for some time and was re-used for all the certificates connected to that organization record until it was corrected.

The employee who made the initial error is no longer part of our vetting team.

To mitigate the risk of the same problem occurring again, we planned integration of a third-party online geographical database with our registration authority management system to make sure that the triple { locality, stateOrProvince, country } be accurate without relying on human judgement only. This enhancement was already part of our roadmap, but in view of this incident we have changed our priorities, so we expect it to be released by October, and will attempt to make it earlier.

Our customer (a large banking group) asked us to postpone just a couple of days the revocation of the single certificate https://crt.sh/?id=1680024891, on the grounds that revoking it earlier (i.e. tomorrow) would disrupt a critical internal service, and they cannot schedule the replacement on working days. Having considered that, plus the nature of the defect and the fact that the said certificate is only used on their internal network, we have decided to allow this slight delay.

Whiteboard: [ca-compliance] Next Update - 29-June 2020 → [ca-compliance]

(In reply to Adriano Santoni from comment #5)

Our customer (a large banking group) asked us to postpone just a couple of days the revocation of the single certificate https://crt.sh/?id=1680024891, on the grounds that revoking it earlier (i.e. tomorrow) would disrupt a critical internal service, and they cannot schedule the replacement on working days. Having considered that, plus the nature of the defect and the fact that the said certificate is only used on their internal network, we have decided to allow this slight delay.

Thanks. Please create a new incident report for this delayed revocation, so that we can appropriately track the steps Actalis is taking to prevent future delays in revocation, however slight, from happening.

Flags: needinfo?(adriano.santoni)
Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 1-October 2020

Sorry for the delay. I have filed bug 1670861 to track the delayed revocation that I mentioned in comment 5.

I intend to close this bug on or about 9-Dec-2020 unless there are other matters to discuss.

Flags: needinfo?(bwilson)

(In reply to Adriano Santoni from comment #4)

To mitigate the risk of the same problem occurring again, we planned integration of a third-party online geographical database with our registration authority management system to make sure that the triple { locality, stateOrProvince, country } be accurate without relying on human judgement only. This enhancement was already part of our roadmap, but in view of this incident we have changed our priorities, so we expect it to be released by October, and will attempt to make it earlier.

Was this completed in October as planned?

Yes, Mathew. We integrated our registration authority management system with GeoNames.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] - Next Update - 1-October 2020 → [ca-compliance] [ov-misissuance] [ev-misissuance]
You need to log in before you can comment on or make changes to this bug.