1599484 - Entrust: EV Certificates Issued with Business Category "Non-Commercial" when it should have been set to "Private Organization"

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Dathan Demone]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

EV Certificates Issued with Business Category "Non-Commercial" when it should have been set to "Private Organization"

Comment 1

[Dathan Demone]

1. How your CA first became aware of the problem
   On Monday, November 25th, we received a notification through a third party that some Entrust issued EV SSL certificates may not have used the correct Business Category value. After further review, we confirmed that a total of 31 certificates for 4 organizations used the Business Category “Non-Commercial Entity” when they should have been set to “Private Organization”.

2. A timeline of the actions your CA took in response
   Nov 25, 2019, 1:30 pm: Entrust Customer support received the notification from the third party with the list of potentially mis-issued certificates

Nov 25, 2019, 2:30 pm: Internal review and investigation started after the notification we received was escalated to management

Nov 25, 2019, 3:30 pm – The internal review confirmed the issue. 4 customer accounts and a total of 31 certificates were impacted. The EV information for these 4 customer EV profiles was updated at this time to reflect the correct Business Category value “Private Organization” to prevent any additional certificates from being issued with the incorrect Business Category value.

Nov 25, 2019, 4:00 pm – A manual review of all Enterprise and Retail customers took place to confirm that no other accounts had this issue. We confirmed that the issue was isolated to the 31 certificates for 4 Enterprise customers.

Nov 25, 2019, 5:30 pm – Customers are notified of the issue and a deadline to revoke the problematic certificates is set to Friday, November 29th to comply with the CA/B forum policy.

Nov 26, 2019, 10:30 am - Further review completed to confirm that no other certificates were mis-issued and to review current process documentation for Business Category Verification.

3. Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem
   Confirmed – the incorrect information on 4 customer account EV profiles have been updated to use the correct Business Category value. We also manually reviewed all of the other accounts where “Non-Commercial Entity” is used in the Business Category field and found the issue to be isolated to these 4 customers and 31 certificates.

4. A summary of the problematic certificates
   31 EV SSL certificates were issued with the Business Category set to “Non-Commercial Entity” when “Private Organization” should have been used instead.

5. The complete certificate data for the problematic certificates
   https://crt.sh/?id=1516918136
   https://crt.sh/?id=1825322149
   https://crt.sh/?id=1105309743
   https://crt.sh/?id=211743667
   https://crt.sh/?id=211183454 (note: this certificate expires on November 27, 2019)
   https://crt.sh/?id=224806146 (note: this certificate expires on November 27, 2019)
   https://crt.sh/?id=217960827
   https://crt.sh/?id=247019639
   https://crt.sh/?id=284926819
   https://crt.sh/?id=326017535
   https://crt.sh/?id=300070486
   https://crt.sh/?id=710029636
   https://crt.sh/?id=300149770
   https://crt.sh/?id=613377107
   https://crt.sh/?id=339192794
   https://crt.sh/?id=481736357
   https://crt.sh/?id=414937445
   https://crt.sh/?id=445683396
   https://crt.sh/?id=469406049
   https://crt.sh/?id=527927839
   https://crt.sh/?id=502377026
   https://crt.sh/?id=737776704
   https://crt.sh/?id=803620284
   https://crt.sh/?id=1680494191
   https://crt.sh/?id=934184951
   https://crt.sh/?id=1003925417
   https://crt.sh/?id=1003911650
   https://crt.sh/?id=1003911650
   https://crt.sh/?id=1003931138
   https://crt.sh/?id=1113512972
   https://crt.sh/?id=1043721546

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   When a customer submits an EV SSL verification request to Entrust, a Verification Specialist will set the relevant EV data fields in our verification system based on the research they collect for that particular organization. The verification data is reviewed two separate times, once by a Verification Specialist who collects the evidence and approves the initial request, and then again by a Verification Audit Specialist who checks the EV data for accuracy and compliance. 4 account EV profiles were incorrectly set to Non-Commercial Entity instead of Private Organization. After an in-depth review, this was not related to any system issue but was due to human error and insufficient process documentation. In this case, the verification specialist/audit specialist made the wrong determination on the Business Category field based on the collected research data.

After a detailed review of our verification processes and training guides, it was determined that these guides did not include enough information regarding the compliance requirements for Non-Commercial entities.

7. List of steps your CA is taking to resolve the situation
   As this incident was due to human error and process documentation, updates to the process documentation and additional training/testing will be provided to ensure a correct understanding as to when the Non-Commercial Entity value should be used in the Business Category field. The process used for Non-Commercial Entities was reviewed and we determined that it must be modified to include additional information and examples to provide better clarity to our verification team. The verification process for non-commercial entities will be updated by November 29th, 2019 and we will provide training and testing to the global team by December 6th, 2019.

Comment 2

[Ryan Sleevi]

The qualifications for Non-Commercial Entity are very restricted (c.f. EV Guidelines 8.5.5 (A)), and thus expected to be exceedingly rare. It appears the extent of Entrust's remediation is "Train harder", but no details are provided about what that training or documentation is, to enable the ecosystem to benefit and improve.

For example, the EV Guidelines presage the possibility of the CA/B Forum explicitly enumerating entities that qualify, due to the anticipated small number of such entities.

What's more interesting, and more concerning, is that Sectigo reported a similar issue a month ago, as did QuoVadis. Why didn't Entrust proactively examine its practices then, given the error-prone nature? To what extent has Entrust reviewed these incidents, and to what extent does Entrust monitor CA incidents?

Comment 3

[Dathan Demone]

We do regularly monitor other CA issues in the Google discussion group -https://groups.google.com/forum/#!forum/mozilla.dev.security.policy
We do monitor the CA issues with Mozilla/Bugzilla but we primarily use the Google discussion group to monitor CA issues due to the volume of bugs that are posted in Bugzilla that are not always related to CA practices. The Quovadis and Sectigo issues were not posted to the Google discussion and we missed these posts. Thank you for pointing out these reports – there is a lot of good information there. If you have any suggestions as to how we should better monitor Bugzilla, that would be great.

After reviewing the posts from Sectigo and Quovadis, we are in favor of controlling this issue with a Non-Commercial list in addition to the training and process updates we mentioned in our original post. We have reached out to Sectigo to see if they will be sharing this list with other CAs as they have stated in their report. We will update this bug in the near future with additional information about how we would implement additional checking our system for Non-Commercial Entities. The addition of a known Commercial-Entities list to our verification system and the ability to flag these organizations should add an additional layer of protection to our process, so thank you for pointing us in this direction.

Comment 4

[Dathan Demone]

All 31 certificates were revoked on Nov 29, 2019.

Our process documentation has also been updated.

We will complete additional training for the team next week. I will follow up with a more detailed solution to help us automatically check non-commercial entities against a known list in our system.

Comment 5

[Ryan Sleevi]

When is a follow-up expected?

Comment 6

[Dathan Demone]

We have a design in place that will allow us to flag non-commercial entities in our verification process so that we can do additional checking on these organizations to confirm that they are in fact non-commercial entities. The piece that will take some time is obtaining a reliable list of non-commercial entities. As mentioned previously, we are in touch with some of our colleagues in the industry to see if we can share data to create a list. We are also working on obtaining a list from another third party who may have a reliable database we can use.

The design leverages our existing high-risk process where all organizations that go through our verification process are compared against a list and flagged as high risk. We just need to add the list of non-commercial entities that the list and leverage our existing workflow for high-risk organizations to verify them.

I will provide an update once the additional training and testing are completed later this week and I will also provide an update on the non-commercial entities list at the same time.

Comment 7

[Dathan Demone]

We completed our updated training and testing as planned for the entire global verification team on December 6th.

We are still working on a solution to create a list of non-commercial entities that we can use in our verification system. I will provide an update on this as soon as possible.

Comment 8

[Ryan Sleevi]

Dathan: While it may seem somewhat trivial, we try to look at concrete dates for delivery, rather than "as soon as possible". This helps build appropriate expectations and transparency. This is similar to the remarks in Comment #4/Comment #5.

This is captured in the "accompanied with a timeline of when your CA expects to accomplish these things." from https://wiki.mozilla.org/CA/Responding_To_An_Incident (Incident Report, #7).

The alternative here is weekly progress reports, as captured in https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed , which seems like more work. Helping clarify and manage expectations for remediations like this helps us better triage and respond to incidents, and helps the community better understand the challenges that CAs face.

Comment 9

[Dathan Demone]

Thanks for sharing these examples. We are finding that it is taking longer than expected to develop a comprehensive list of non-commercial entities. As such, we will provide weekly status updates on our progress to keep you informed.

Here are a set of steps of next steps we plan to take:

• We will continue to work with other CAs who have expressed interest in working together to coordinate a list of non-commercial entities
• We are also trying to work with a commercial source who may be able to provide us with a comprehensive list that we can use
• We plan to mine CT records to get a list of all issued EV certificates that are verified as non-commercial entities and will add this list to our high-risk organization verification process. While this list may include some certificates that have incorrect data, we can still use this to highlight potential non-commercial entities so that we can add additional scrutiny when verifying these organizations.

Our next status update will be posted on December 20th, 2019.

Comment 10

[Dathan Demone]

We were able to obtain a list of Non-Commercial Entities and have added those to our high-risk organization list today. Our system will flag these organizations moving forward. We obtained the organization list by mining the CT logs for all EV certificates issued as Non-Commercial Entities.
It turns out that the commercially available data I mentioned above was also based on CT logs and produced the same results as our own CT queries.

Please let us know if you need any other information or recommend any further actions.

Comment 11

[Ryan Sleevi]

Dathan: I'm not sure how Comment #10 really helps understand or address the issue, and I'm hoping you can expand on your process or how it worked.

That is, combined with your Comment #9, it seems the assertion in Comment #10 is "No Non-Commercial Entity has been misissued, ergo, what we find in CT is correct", but that's.... the furthest possible thing from the truth. It's equally and especially dangerous if the analysis with CT is done incorrectly (e.g. not accounting for expired or untrusted certificates)

The approach described in Comment #10 is unclear if it's a followup to this statement:

We will continue to work with other CAs who have expressed interest in working together to coordinate a list of non-commercial entities

Or this statement:

We plan to mine CT records to get a list of all issued EV certificates that are verified as non-commercial entities and will add this list to our high-risk organization verification process.

The reason this is ambiguous is because the following assertion:

It turns out that the commercially available data I mentioned above was also based on CT logs and produced the same results as our own CT queries.

Put differently, it sounds like you've reasoned yourself into a circular validation, and I believe that's more likely harmful than helpful. CAs apparently rely on commercial data sources, and based on Comment #10, commercial data sources rely upon CAs. Further, the steps to prevent future mistakes (Comment #9) appears to be "Don't repeat the same mistake" (Comment #10), by adding them to a high risk list. If the validation procedures are correct, and the system is designed appropriately, it should not be necessary to add any of these entities to any sort of "high risk" list, because it should be impossible for them to be validated as NCEs.

Of the steps proposed, there's only one concrete proposal that gives me any confidence or faith that the desired result can be obtained, and that was:

working together to coordinate a list of non-commercial entities

Everything else seems superfluous and unlikely to prevent the systemic issue. It only becomes actively harmful if those steps are seen as mitigating the issue, which they do not. I'm hoping you can share an update on providing a list, and presumably the rationale for entities on that list, in order to be transparent and address the systemic issues.

Comment 12

[Dathan Demone]

Ryan, here are some additional details to help explain my last update:

• I agree that the list we obtained from CT is not a reliable list of Non-Commercial entities, as Entrust Datacard and other CAs have issued these certificates incorrectly in the past. The intention was never to use this initial list as a trusted source of non-commercial entities. The list that I referred to in comment #10 does not tell an Entrust Datacard Verification Specialist that the organization is confirmed as a non-commercial entity. The list simply highlights the organization in our system as a potentially high-risk verification due to the rare nature of this business category and the mistakes that have been made in the past.

• The list we obtained from CT included every EV certificate logged in CT for the last 5 years that used the business category "Non-Commercial Entities". The list of certificates resulted in 191 distinct organizations. As this list includes organizations that were incorrectly labeled as Non-Commercial Entities and organizations that were verified by CAs that have been distrusted, I have arranged for our verification team to review each entry and verify if the organization is correctly identified as a non-commercial entity. We will share this list with all other CAs once we have completed our review. As I mentioned previously, we are working with other CAs (through Bruce Morton) to share information. We are aiming to have verification completed on these 191 organizations in early January 2020. Please let me know if there is a preferred method of sharing this list with the entire community.

• As mentioned in my initial report, our analysis on this incident revealed that one of our biggest contributing factors resulting in the incorrect use of the Non-Commercial Entity Business category was related to training. These types of verifications are rare and this topic does not come up very often in practice. In order to solve this, we created mandatory training on this topic and set a deadline for the global team to complete the training. We also required that agents complete an assessment at the end of the training. In addition to the training, we are using the exercise of reviewing all CT logged non-commercial entities as a good opportunity for the team to gain additional experience in this area.

Comment 13

[Ryan Sleevi]

Dathan: I'm not trying to be difficult, and hopefully I'm just misunderstanding, but I'm not particularly inspired by the response to date. I apologize for the length of the reply, but I am trying to work out how we, as an industry, and work together to prevent issues like this, and not just at Entrust.

I'm trying to understand what steps Entrust believes meaningfully addresses the issue, and which are, for lack of a better word, just 'housekeeping' inspired by this issue. That is, the discussion of CT - and anything related to CT or what other CAs do or have done - doesn't really seem like it either mitigates or prevents this, and so that's perhaps adding to my confusion. Similarly, the treatment of "high risk requests" is something that doesn't seem really to be related to addressing the underlying issue.

Put differently: Looking at existing organizations, rather than the businessCategory selection, seems to be learning the wrong lesson; it would seem like every Non-Commercial Entity validation should be treated as high risk, rather than previously encountered organizations. And if that's done, it shouldn't matter if it's a previous organization or not. It similarly doesn't seem to make sense to look at the previous organizations and treat them as high risk if, for example, they're applying as a private organization.

It'd be useful to understand if Entrust disagrees - that is, that it thinks the effort around CT either mitigates or prevents this, for example, or that treating certificates as high-risk does. Even if we disagree, it's at least a bit clearer how Entrust approaches incident response.

In terms of taking meaningful steps, I don't think we can really conclude "created mandatory training" as being sufficient detail for incident reports anymore. We rely on CAs to explain, systemically, how the training failed and how the new training is addressing that. For example, if mandatory training is simply regurgitating the BRs, then I think it shows both a lack of systemic analysis of the failures and a lack of awareness of the factors contributing here. Sharing your training material itself is, at least in that regard, useful to understanding how it's being approached.

These incident reports try to serve two goals: helping understand how the CA thinks about and responds to incidents, which we see a wide spectrum of "This CA responded so badly we should be distrusting them" (as has happened in the past) to "This CA responded so well we should make sure every CA has a chance to learn here", and to look at ways to systemically improve the ecosystem. The collaboration that we do on these bugs isn't meant to tell you what to do, but is meant to provide additional perspective and look for opportunities for improvement.

I mention this, because it seems the replies are focused on this specific issue (and perhaps because it's the immediate issue), but it's not clear much is being done to systemically understand. A systemic approach would look at not just where "non-commercial entities" failed, nor would it explore "just" the businessCategory field, but it would look for all places that human judgement is being made by teams, and look to see if there are ways to remove or reduce the humans in the loop, or provide them tools to support their efforts. While NCEs might be solvable by an allowlist, figuring out the distinction for things like Government Entities is also important. Examining Entrust's use of the businessCategory field as a whole, making sure all things are consistent. Going beyond that, looking through data sources they use and understanding what the validation process actually looks like, and not just what folks are trained to do.

Even if that seems extreme, sharing a bit about how these failures came to be: where in the validation process does the agent make the determination on the type of entity or other elements of the field, and how do they validate it, is useful. Is there a checklist process? Does the checklist have an order or sequence to it, to make sure the most meaningful stuff is captured? I understand the training failed, but I think in the incident responses, we're trying to understand what part of that training failed or why it failed, and what the new training is trying to do, so that we can learn and improve from everyone's experiences on what works and what doesn't work, and what parts of training are important.

Comment 14

[Dathan Demone]

Based on your last comment, Entrust does agree with the points you are making. Flagging CT logged NCEs does help us to potentially avoid bad verification for known NCEs (including mis-issued NCEs) but it does not mitigate the issue for NCEs in general. Up to my last comment, we were trying to solve the issue with increased emphasis on NCEs (through training and our flag list of know NCEs), as this is a very rare type of verification. I think there was some misunderstanding on our part based on what other CAs had posted as a result of the same issue and what we had discussed in this incident thread. Following your line of reasoning from your last post, it does not make sense to attempt to mitigate this issue by flagging known/good NCEs and increased training. We should instead look to put additional scrutiny on the unknown NCEs. Based on our discussion and your comments, I am in favor of moving to an allow list. We will create an allow list of NCEs based on the verification we are doing on existing NCEs logged in CT (some of which are incorrect) that I mentioned in my last comment. We will also create a process to add new NCEs to the allow list in the case that a new NCE applies for an EV SSL certificate. This process will require that the verification team present evidence from a valid check source about a potential NCE to a compliance manager at Entrust who is intimately familiar with the BRs/EVGLs for review before it can be added to our allow list. As I mentioned, we are hoping to have a verified list of NCEs based on CT data in January. Once we have that list, we will put a process in place that does not allow an agent to verify an NCE unless the organization is on the allow list. We will share this list with other CAs. We would hope that other CAs would participate in this ongoing effort. I will commit to having the allow list for NCEs in place by end of January (or sooner) depending on how quickly we are able to create the verified list. I will share this once it is ready later this month.

I wanted to respond to your comments about our training/processes and how they failed in this particular instance. Selecting the business category is one of the few areas where a value that goes into the certificate is based on human judgment. Most of the other values are pulled or copied from our validation check sources, such as the Organization name, Place of Business information, Jurisdiction information etc… In this case, there was an improper understanding as to how the NCE business category should be used for 2 reasons:

1. Our training did not properly explain EVGL 8.5.5. that required the international organization’s creation to be signed by multiple governments. There was also some confusion around non-profit organizations specifically, as some agents made the incorrect determinations that these were considered as NCEs.

2. Our training did not provide real-life examples of organizations that qualify as NCEs.

The training that we prepared after the incident was reported included training on all 4 business categories, with information such as reviews on the category definitions from the EV guidelines, real-world examples, acceptable documentation/evidence to prove a business category value for an organization, recommended escalation paths to help an agent to determine a particular business category, and assessment questions to make sure that the agent understands each topic. To be more specific, this is what we require for NCEs based on the training we provided:

• The Applicant is an International Organization Entity, created under a charter, treaty, convention or equivalent instrument that was signed by, or on behalf of, more than one country's government.
• Act of Creation/Decree obtained from an approved QGIS data source (date stamp and source URL visible)
• If the Act of Creation/Decree cannot be found, verbal/written confirmation can be obtained from the Parliament. A record of the contact details of the Parliament office must also be included.

We do have a system that simulates a “checklist process”, where agents enter information into various fields/dropdowns in our verification system and provide the supporting documentation that our auditors use to do the final verification check. One of the changes that we are making to our verification system (based on user feedback) is to move the Business Category drop down to the Jurisdiction information section instead of the General Organization Information section. This change was recommended because the Business Category is typically based on the Jurisdiction information that we collect and separating the Business Category drop down from the relevant information could lead to errors in judgment. We logged this enhancement on November 26th, the day after we reported this incident.

Comment 15

[Dathan Demone]

I just wanted to provide a quick update on this incident.

The process of verifying the list of NCEs we pulled from CT to create our allow list is taking longer than expected. We are hoping to have this process completed by the end of January, at which time we will implement an allow list for NCE verification. We will share our allow list with the CA/Browser community at this time.

Comment 16

[Ryan Sleevi]

Thanks for the update!

In the spirit of transparency, it'd be useful if you can also think, as you work to publish the list, some of the challenges you encountered in verifying the data. In past issues, we've seen reports like https://bugzilla.mozilla.org/show_bug.cgi?id=1551374#c13 or https://bugzilla.mozilla.org/show_bug.cgi?id=1575880#c16 which have helped share a lot of information about the challenges faced in implementing different requirements.

Regarding your update in Comment #14 for example, it'd be super useful to understanding when you need to pursue the verbal/written confirmation of the Parliament, for example. Sharing these sorts of challenges help us improve the requirements, or develop consistent requirements - for example, by refining the EVGLs to be more normative on both the objective of validating non-commercial entities and the acceptable means of validating that.

I'll set the Next-Update to represent January End-of-Month

Comment 17

[Dathan Demone]

Attachment: Verified List of Non Commercial Entities

Comment 18

[Dathan Demone]

We have completed our internal verification process for our NCE allow list, which I have attached. This list is based on the initial list we derived from CT for every organization that has ever been labeled as NCE. Our Verification team collected and reviewed the necessary supporting documentation and evidence to confirm these organizations as NCEs. We have also implemented the allow list process for NCEs that was discussed earlier in this thread. We will continue to work with other CAs on this list to see if there are additional organizations that should be added.

We did some investigation into our process for contacting Parliament for written/verbal confirmation and it turns out that this has never been used for NCE verification at Entrust Datacard. In fact, contacting Parliament does not make sense in this scenario given that NCEs are created by multiple government organizations. We are removing this option from our NCE process and will rely on the allow list/ available documentation that we can find using our online check sources.

Comment 19

[Ryan Sleevi]

Thanks Dathan.

I had been hoping that Entrust would have similarly identifies the sources for their determination that these meet the requirements set forth, which seems useful for cross-checking and independent verification. That said, I'm glad to hear that on further evaluation, an error-prone method was removed.

Wayne: While there's still follow-ups to be led by Entrust within the Forum and broader community, I think this issue is sufficiently explained. It would be great if Entrust provided the information sources used to support this allowlist, but I'm kicking to you.

Comment 20

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.