1526099 - IdenTrust: Discrepancy in values of address fields within CN of SSL Certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[IdenTrust]

1. How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
IdenTrust:
On 02/04/2019 during an internal systems review, our engineering team discovered a discrepancy in the values of the Locality, State and Country of the Subject field for some SSL certificates when compared to the same values we had on record for the applicant organization. Immediately on the same day, we started to investigate the issue and confirmed that the discrepancy exited in 12 SSL certificates. We determined that the discrepancy was introduced during a renewal request with very specific set of actions by the applicant during the renewal process. All 12 certificates were reviewed and the discrepancy for each certificate was determined to not warrant revocation within 24 hours; however, all 12 certificates were revoked within 4 days.
2. Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
IdenTrust:
As of 02/04/2019, we have stopped issuing any certificates with this discrepancy. A procedural fix was implemented on 02/04/2019 with a permanent production system fix implemented on 02/05/2019 as described in item #6 below.
3. Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
IdenTrust:
Below is the list of 11 certificates's crt.sh ID plus one attached as .cer file. All of them are revoked at this time.
1119671865; 1119666862; 1078914111; 1078905183; 1078896499; 1078885688; 1078698472; 1078688677; 216515295; 179499444; 181538487.
crt.sh ID
4. Summary of the problematic certificates. For each problem listed below:
number of certs, date first and last certs with that problem were issued.
IdenTrust:
The 12 certificates were issued between 3/17/2017 and 1/17/2019
5. Explanation about how and why the mistakes were made, and not caught and fixed earlier.
IdenTrust:
During renewal request, the subscriber is presented with two addresses: the organization main address and a mailing address. The subscriber has the option to update the mailing address. Due to incorrect system configuration, an update to the mailing address triggered an update to the certificate data used to issue the certificate. This issue was not caught earlier as updates of mailing address during renewal are very rare as demonstrated by the fact that only 12 certificates had this discrepancy.
6. 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.
IdenTrust:
Effective 02/05/2019 we implemented an update in our system to ensure that for any renewal request only the organization main address Locality, State and Country will be minted in the certificate.

Comment 1

[IdenTrust]

Attachment: IDT-11.cer.txt

Comment 2

[Wayne Thayer]

Thank you for this incident report.

Will Identrust be performing and reporting the results of a root cause analysis? In order to best learn from this issue, I would like to understand the complete timeline from the introduction of this bug, the engineering, testing, leadership, and cultural practices that allowed it to enter production, and the learnings and changes that resulted from the investigation.

Comment 3

[IdenTrust]

Hers is the missing CT Entry ID for the attached certificate: https://crt.sh/?id=1182567728

Comment 4

[IdenTrust]

We will be supplying a further investigation analysis update early next week

Comment 5

[IdenTrust]

Root Cause Analysis Report:
IdenTrust hosts many disparate PKI platforms with varying policy requirements. Some of these policies and certification authorities require verified address information from the organization and some require verified address information of the applicant’s mailing address.
This requires that for a given policy and associated certification authority, we ensure that we have the identity proofing procedures, configuration, and application all set to conform to policy and reflect in the certificate the appropriate and verified address data. Related to this incident, we identified an inconsistency in some publicly trusted SSL certs between the address data that is bound to the certificate in the case of a certificate produced as a result of an authenticated renewal request.
There is a data field in our application that can be set from the organization main address or from the subscriber mailing address, depending on certain configuration and method of request (e.g. initial registration or renewal request). The use of this varying data field and a combination of specific actions by the requester during a renewal request is ultimately, what caused this issue to manifest. We have identified a more reliable configuration approach and implemented this on February 5, 2019. The way that we have corrected this is to update the configuration on our SSL certificate profiles to specifically pull this data from the organization’s main address in all cases. With this change implemented, going forward in all cases the certificate will contain the relevant data elements from the organization main address. Further, we have performed a detailed review of data mappings of all fields for creation of publicly trusted certificates. No further issues were identified.
As part of our root cause analysis investigation, we determined that the configuration that caused the mis-issuance has been in place prior to the effective date of Baseline Requirements v1.0 (July 1, 2012) (BR). In order to understand the impact, we examined all certificates issued since BR v1.0 effective date and identified that a total of 43 SSL certificates have this issue. This includes the 12 certificates that were active at the time of discovery of the issue – all of which have been disclosed in the incident report. The remaining 31 SSL certificates were either expired or already revoked at the point of discovery of the issue on February 4, 2019.
At this point we have concluded our investigation and no further activity is scheduled related to this incident.

Comment 6

[Wayne Thayer]

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