Camerfirma: certificate with an incorrect OrganizationName
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: eusebio.herrera, Assigned: eusebio.herrera)
Details
(Whiteboard: [ca-compliance] [ov-misissuance])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Steps to reproduce:
Camerfirma: certificate with an incorrect OrganizationName
On November 30th morning our quality control detected a certificate with the organization field incorrectly filled.
The certificate was revoked on November 30th afternoon.
We will disclose the incident report as soon as possible.
|
||
Updated•3 years ago
|
|
Assignee | |
Comment 1•3 years ago
|
||
Yesterday I've made a typo. We detected the certificate with the wrong organization name on November 27th morning.
Here follows the report for the misissuance of a TLS certificate with an error on the Organization name.
The certificate is https://crt.sh/?id=3254959244 and has a wrong prefix : (characters sequence 0x3A 0x20) on the Organization DN field
organizationName = : Hospital da Senhora da Oliveira - Guimarães EPE
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.
Camerfirma reported us by email their Quality Department found a wrong Organization name in certificate https://crt.sh/?id=3254959244
2. 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.
2020-11-27 08:34 WET - Camerfirma reported us the error with the certificate
2020-11-27 09:46 WET - problem confirmed, investigation started
2020-11-27 10:49 WET - confirmed this certificate is the only occurrence
2020-11-30 18:00 WET - old certificate revoked
3. Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.
We have not stopped issuance of certificates. The error was an isolated case and not due to a systematic failure on the systems or procedures.
4. In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
1 certificate affected.
5. In a case involving certificates, 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. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
https://crt.sh/?id=3254959244 (serial number: 3905e62b98125f03129b2883ab8c1aca)
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The backoffice operated by the Validation Team presents the registration data in the format of label: value
In this specific case, the validation officer did not noticed the incorrect value in the backoffice:
Organization: : Hospital da Senhora da Oliveira - Guimarães EPE
7. List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
- Today the case has been shared with the Validation Team, as an example of possible data incorrections to pay particular attention for.
- We will be updating the backoffice interface design to have clear visual distinction of the label and corresponding value (e.g. different font type, shadow colouring, etc). This is included in the roadmap and is being planned for a next sprint with the development team. The initial estimate date will be included in the next update to this bug report.
Finally, it was considered whether this particular case should be handled through the data sanitization regular expression. We concluded that an organization name like : My Weird Prefix Company is theoretically allowed by most Incorporating Agencies, therefore we are not in favour of introducing a specific control for the prefix :, therefore we are not taking action at this point in time, unless we see a repeated pattern of similar errors.
- We will be updating the backoffice interface design to have clear visual distinction of the label and corresponding value (e.g. different font type, shadow colouring, etc). This is included in the roadmap and is being planned for a next sprint with the development team. The initial estimate date will be included in the next update to this bug report.
Status update: we are targeting this change for the sprint to be deployed on 2021-01-28.
The change fix was deployed today.
The UI has been enhanced to better distinguish between labels and values. The validation regex was also changed to further restrict occurrences of special characters.
There are no more planned actions for this issue.
If there are no further questions, I believe it can be closed.
|
|
||
Comment 9•3 years ago
|
||
I will close this on or after 12-Feb-2021 unless there are reasons why this bug should remain open.
|
|
||
Updated•3 years ago
|
|
||
Updated•10 months ago
|
|
||
Updated•7 months ago
|
Description
•