eMudhra: emSign CA Invalid OrganizationalUnitName
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: vijay, Assigned: vijay)
Details
(Whiteboard: [ca-compliance] [dv-misissuance])
Summary:
Two DV SSL certificates were wrongly issued with OrganizationUnitName, containing value as ‘Domain Control Validated’.
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 07-Dec-2021 18:11 (Indian Time), we received an email reporting a certificate with invalid OrganizationalUnitName.
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 in Indian Time / UTC+5:30)
13-Sep-2021 The reported certificate was issued
07-Dec-2021 18:11 We received the reporting email.
07-Dec-2021 18:30 We have confirmed the certificate is actually mis-issued and start the investigation.
07-Dec-2021 20:00 The system configuration inspection and resolution to mitigate the issue is initiated.
07-Dec-2021 20:05 The system was scanned for additional affected certificates, and found one more DV certificate with similar issue.
07-Dec-2021 20:56 The reported certificate was revoked.
07-Dec-2021 20:57 The system configuration changes are confirmed to be completed towards mitigate the issue.
07-Dec-2021 20:58 The replacement certificate was issued for the domain without OrganizationalUnitName.
07-Dec-2021 21:05 Additional affected certificate (one) was also revoked and replacement certificate was issued.
08-Dec-2021 18:50 We have completed the investigation and internal reporting processes towards Policy Authority review.
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.
We have stopped issuing certificates with the problem, and resolved this for future issuances.
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.
We have checked all the valid certificates and found only 2 DV SSL certificates with OrganizationalUnitName containing invalid value (Domain Control Validated). The OU field should not have been part of these 2 certificates. The affected certificates were issued to the websites managed by us (eMudhra). There were no external customers impacted due to the certificate revocation.
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=5211081879
https://crt.sh/?id=5714095347
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
For issuance of these 2 certificates, an unused certificate profile was used while generation of certificate, due to a human error. Given that this issue was not reflected as part of system checks / results, the issue went undetected.
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.
There have been quite a few OrganizationalUnitName related incidents in Bugzilla reported by various CAs in previous bugs. These have been learning to us in our regular trainings to the team. However, a human error possibility of causing this issue was unexpected and unforeseen. Hence, considering the severity of such mistakes, an immediate system change request has been initiated to disable such possibilities technically in our RA system towards technical controls thereby avoiding human errors. Additionally the system shall also be bringing this as a finding in certificate verification stage during generation. Until this upgrade (of complete automated control), the profiles have been scrutinized in detail to not result into this issue, as well as additional training is provided to all personnel involved in such operation.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Hi Vijay,
A few questions regarding the next steps:
Hence, considering the severity of such mistakes, an immediate system change request has been initiated to disable such possibilities technically in our RA system towards technical controls thereby avoiding human errors.
Can you describe, specifically, what changes were requested, when they'll be applied, and how eMudhra expects that they will prevent future instances of this issue? What steps has eMudhra taken to review other existing configurations such that a similar type of issue does not exist for other fields or extensions?
Thanks,
Ryan
Assignee | ||
Comment 2•3 years ago
|
||
Can you describe, specifically, what changes were requested, when they'll be applied, and how eMudhra expects that they will prevent future instances of this issue?
The change in the system is specific to adding technical validation for DV certs to not include OU fields. This is a tighter control, compared to existing configuration level controls leading to possible human error. The change is expected for release by 31-Dec-2021. Similar technical controls have been already in place for the fields (as per BR / etc) either at linting stage, or at certificate (TBS) data validation stage. The non-DV TLS certs will also have similar validation by their applicable dates for OU fields.
What steps has eMudhra taken to review other existing configurations such that a similar type of issue does not exist for other fields or extensions?
This is as per internal defined process / function, where the audit officers lead by lead auditor review the existing configurations and present it. Post this incident, each certificate profile configurations were reviewed at item level and presented for consistency as per compliance requirements.
Comment 3•3 years ago
|
||
Please provide an update on your remediation efforts.
Assignee | ||
Comment 4•3 years ago
|
||
Hi. The change in the system to technically validate OU removal is deployed in the last week of Dec-2021. The certificates issued till date have been verified to work as expected, and no issues were found in OU field. Please consider this as an update on our remediation efforts.
Assignee | ||
Comment 5•3 years ago
|
||
We confirm that all remediation's identified in this bug have now been completed. We request for this bug to please be marked as Resolved, in case there are no other comments.
Updated•3 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•