1744722 - FNMT: Invalid localityName

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[alain]

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

Steps to reproduce:

On December 6th (15:32), FNMT received a certificate problem report indicating that one certificate was issued with invalid localityName data:
https://crt.sh/?id=5016687590

After a preliminary investigation, we have confirmed that the certificate must be revoked.
On December 7th, at 11:05 the certificate has been revoked.

We are analyzing the causes of the problem. A full report will be posted here in the coming days.

Comment 1

[Brox]

We keep informing:
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.
FNMT became aware of the problem via our incident reporting email by a third party. This email was received on December 6th 2021, 15:32:16 CET

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.
• December 6th 2021 16:15 CET: The FNMT TSP Management Committee is informed and decides to suspend the certificate issuance service under “AC Componentes” until the reasons that have generated the incidence are clarified.
• December 7th 2021 9:00 CET: The technical and compliance team confirms that the certificate was issued with an incorrect locality name and requests its revocation.
• December 7th 2021 11:05 CET: The certificate reported (https://crt.sh/?id=5016687590) is revoked. The technical and compliance team begins analysing the reasons about how and why the mistake was made.
• December 9th 2021 17:00 CET: The technical and compliance team concludes that the issuance of the certificate with an incorrect locality name was due to a mis-validation by our validation specialist. The FNMT TSP Management Committee holds an internal meeting with the technical and compliance team to agree on next steps and to discuss about technical controls that could be implemented to reduce the possibility of future mistakes and typos with the locality field.
• December 10th 2021 09:00:00 CET: Until the effective implementation of technical controls, a greater effort will be required in the verification by our validation specialists of these fields. The FNMT TSP Management Committee agrees to reactivate the issuance service.
• December 14th 2021 18:00:00 CET: As a result of a deep analysis on the localityName of the TLS certificates issued to date, the technical and compliance team discovers another 10 certificates affected. The FNMT TSP Management Committee is informed and decides to notify the subscribers about this incidence and to offer them to apply for a new certificate. The 10 certificates affected will be revoked within 5 days maximum.
• December 14th 2021: We are exploring different technical solutions and will provide updates on our approach to ensure that these human errors do not occur again.

3. 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.
No additional certificates with an incorrect locality field were issued.

4. 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.
11 certificates in total have been issued with an incorrect localityName value.
Certificates issued by “AC Componentes Informáticos”: 9 certificates
Certificates issued by “AC Administración Pública”: 2 certificates

5. 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.

AC Administración Pública
https://crt.sh/?id=4442085483
https://crt.sh/?id=4274570580

AC Componentes Informáticos
https://crt.sh/?id=5417538613
https://crt.sh/?id=5016687590
https://crt.sh/?id=4913821753
https://crt.sh/?id=4862820824
https://crt.sh/?id=4344428618
https://crt.sh/?id=2673437452
https://crt.sh/?id=2696884240
https://crt.sh/?id=2337273924
https://crt.sh/?id=2337149617

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Our TLS request application uses a text input field for the locality value. The request includes the locality value that is supplied by the subscriber during the enrolment process. The verification team is required to verify these values exactly as they appear in the official records and to avoid any mistakes or typos. If a locality value with mistakes/typos is supplied by the subscriber, the validation specialist shall reject the request and inform the subscriber.
Our verification system includes a validation process of the country and state fields that are returned as per the postal code supplied by the subscriber but not for the localityName.

7. 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.
We are exploring different technical solutions in order to obtain the localityName from a trusted source and will provide updated information on the coming days on the solution adopted.

Comment 2

[Brox]

Updating of information:
The 10 remaining affected certificates were revoked on December 18th 2021

Comment 3

[Brox]

Updating of information:
A technical control will be implemented in the request TLS certificate applications so that the postal code entered by the user will return a valid locality value, along with the corresponding province value.
For such implementation, we are at the moment evaluating 2 different official registries as trusted sources of information: The Spanish National Institute of Statistics – “INE” and the Spanish Mail Service - “Correos”. We will provide an update on our approach as soon as a decision is taken.
With regard to the planned implementation of the necessary technical controls, it is estimated that they will be operational in the production environment by 31/03/2022.
In the meanwhile, all registry officers and validation specialists have been reminded and made aware of the importance of re-verifying and confirming the accuracy of all information provided against the official consultation sources, with particular emphasis on fields likely to contain typos.

Comment 4

[Brox]

Updating of information:
The evaluation of the 2 selected official registries sources of information has been completed and for both technical and operational reasons it has been decided to integrate the The Spanish National Institute of Statistics – “INE”. Likewise, the analysis and design phase has been completed in order to carry out the necessary modifications in the different components involved. Development is currently underway and to date no delays have been identified with respect to the initial forecast.

Comment 5

[Brox]

Updating of information - Actions completed
After performing the test suite in the pre-production environment, all the planned controls to ensure the locality correctness for the issuance of TLS certificates were successfully installed in the production environment yesterday (22 feb)

Comment 6

[Ben Wilson]

Unless there are additional questions to pose to FNMT, I am suggesting that this be closed as of Wed. 13-Apr-2022.