Closed Bug 1667430 Opened 4 years ago Closed 3 years ago

Camerfirma: Invalid stateOrProvinceName field

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: fozzie, Assigned: ana.lopes)

Details

(Whiteboard: [ca-compliance] [ov-misissuance])

Attachments

(7 files)

A further 429 certficiates with "Italia" as a stateOrProvinceName value
27.65 KB, text/plain
Details
serial_InfoCert Organization Validation 2019 CA 3.txt
2.91 KB, text/plain
Details
serial_InfoCert Organization Validation CA 3.txt
9.43 KB, text/plain
Details
serial_Intesa Sanpaolo Organization Validation CA.txt
35.60 KB, text/plain
Details
serial_Intesa Sanpaolo Organization Validation 2019 CA.txt
127 bytes, text/plain
Details
27certs.txt
1.11 KB, text/plain
Details
8 Fingerprints
526 bytes, text/plain
Details

I reported the following batch of certificates to incidentes@camerfirma.com - https://misissued.com/batch/179/

They replied stating that "Italy" is valid here under "If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with Section 7.1.4.2.2(g), the subject:stateOrProvinceName field MAY contain the full name of the Subject’s country information as verified under Section 3.2.2.1." in the Baseline Requirements.

This seems to be a systematic misunderstanding of the definition of a "user-assigned" code and I feel there may be even more certificates issued with this problem.

Camerfirma,

If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with Section 7.1.4.2.2(g), the subject:stateOrProvinceName field MAY contain the full name of the Subject’s country information as verified under Section 3.2.2.1.

In the BR sections 7.1.4.2.2(f) and 7.1.4.2.2(h), 'XX' is not a placeholder, but a verbatim country code, that ISO 3166-1 specifies as a user-assigned country code. A user-assigned country code is one that is given meaning by the user, and has no given meaning/designation in the standard. To make this exception found in 7.1.4.2.2(f) apply, one would need subject:countryName = XX, and the supplied batch does not include such certificates.

Also note that section 7.1.4.2.2(g) mentions:

If the subject:organizationName field is present, the
subject:countryName MUST contain the two-letter ISO 3166-1 country code
associated with the location of the Subject verified under Section 3.2.2.1. If the
subject:organizationName field is absent, the subject:countryName field MAY
contain the two-letter ISO 3166-1 country code associated with the Subject as verified
in accordance with Section 3.2.2.3. If a Country is not represented by an official ISO
3166-1 country code, the CA MAY specify the ISO 3166-1 user-assigned code of XX
indicating that an official ISO 3166-1 alpha-2 code has not been assigned.

Ergo, XX in the subject:countryName is only valid when the country does not have an ISO 3166-1 country code assigned (Italy has one assigned: IT). And subsequently, only then may the subject:stateOrProvence field contain the country's name verbatim (which is probably to indicate which country is indicated with the country code XX).

Assignee: bwilson → ana.lopes
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance]

Assigning to Ana Lopez, cc'ing Eusebio Herrera and Juan Angel Martin.

I have attached a further 429 leaf certificate fingerprints discovered with the stateOrProvinceName field of "Italia"

Hi all,

We are investigating the case and the number of affected certificates fo the CAs:

  • InfoCert Organization Validation CA 3
  • InfoCert Organization Validation 2019 CA 3
  • Intesa Sanpaolo Organization Validation CA
  • Intesa Sanpaolo Organization Validation 2019 CA

First of all, we want to restate that this problem has happened because of a misinterpretation of the Baseline Requirements because there is not express prohibition for the value of the field subject:stateOrProvinceName. A rewording is needed from our point of view in order to avoid future misunderstandings.

For the moment, we want to inform you that some of the certificates are high level ones and we will not be able to substitute and revoke them within the deadlines.

We will include more information about the problem when we finish the complete study of the case.

Thanks for the initial response.

The Baseline Requirements do state:

If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under Section 3.2.2.1.

Are you looking for an explicit prohibitation of a country name in the stateOrProvinceName field? In the case of Italy this seems pretty clear as "Italy" is not a province. These certificates also include a localityName and a organizationName field so a stateOrProvinceName field is not required.

To echo George's comments, I do not see how one can claim, given these certificates, that this is an ambiguity of the Baseline Requirements.

If you will not be revoking as you have publicly committed to, within your CP/CPS and which was the basis for trusting Camerfirma, then a separate incident will be required for that separate violation of the CA's CP/CPS and the Baseline Requirements. Please ensure such a new incident is filed before any appropriate deadlines have elapsed, and before your study has completed, as it is essential for continued trust in a CA that they promptly notify any failures to adhere to the Baseline Requirements. Simply stating you'll be ignoring your CP/CPS is not an appropriate substitute for notification.

Flags: needinfo?(eusebio.herrera)

It is also extremely important that now this issue has been discovered, Camerfirma do not issue any more certificates with this problem. Camerfirma has already issued a Precertificate with this problem today - https://crt.sh/?id=3439396046.

(In reply to Eusebio Herrera from comment #4)

For the moment, we want to inform you that some of the certificates are high level ones and we will not be able to substitute and revoke them within the deadlines.

(In the new incident report,) can you please point to where in your CP(S) or the BR "high level certificates" are defined and exempt from revoking within the deadlines? Additionally, you already seem to be able to, in advance, identify certificates, where you will not be able to comply with the BR. Why did you issue these certificates at all? Intentionally planning to break the BRs is not very trustworthy.

George: From our point of view, an explicit prohibition would clarify the text of the BR a lot. We know that this field is not mandatory, and we did not have to complete it, in fact, we have other SSLs profiles where this field has not been used. This problem gives us an idea about the possible improving of the profile approval for all the SubCAs to harmonize profiles. Besides, we want to restate that the term “State” is not the same in all countries and in Italy state is a synonym of country and is not used for provinces.

Referring to the revocation that Ryan mentions, we are going to open a new bug for the delay, giving more details about the reason and the plan, so we think is not necessary opening a bug for the non-compliance of our CPS or the BR because we are going to revoke the certificates to comply with them.

Regarding the pre-certificate that was issued, we are working to stop the issuance of those certificates and to change the profiles in order to eliminate that field.

Paul: With the term “high level” we tried to refer the certificates that affect a big number of domains and machines. Sorry for using such a confusing term. The revocation of this kind of certificates is more complicated than in other cases because we need to define the substitution plan and it involves more people and resources. Those kinds of SSL and the number of certificates affected take us to think that the 5-day period is not enough. We try not to impact in our customers activity. We need their collaboration to replace the SSL certificates before being revoked. It is difficult to explain them why we need to revoke so urgently when there is not a security issue. That is for sure that we do not have the intention of breaking the BR. And, of course we have never considered the possibility to issue any certificates violating the CPS or BR and this problem was involuntary due to a misinterpretation.

Can Camerfirma provide an explanation as to why they continue to issue certificates with this issue after this bug has been opened and they have acknowledged it?

This is quite concerning.

Camerfirma, if you cannot be certain that you have fully remediated this problem, I would encourage you to immediately cease all certificate issuance unless and until you can ensure that your certificates will comply with the Baseline Requirements and the Mozilla Root Store Policy.

Flags: needinfo?(ana.lopes)

Please refer to Mozilla's policy on this issue - https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation

  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.

We were conscious about the problem for the first time when George opened this bug and reported the problem on September 25th.

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

• September 25th: When we received the notification of this bug, we contacted the affected CAs immediately to inform them about the situation,
• September 28th: Study the case and what the possible misinterpretation with the help of the reporters who added comments in the bug
• September 29th: detect all the affected certificates with the problem and
• September 30th: stop issuing certificated with the affected profiles
• September 30th: Change of the profiles with error
• September 30th: Establish a plan for their substitution and revocation
• October 1st: Beginning of the substitution process
• October 14th: Revocation of all the affected certificates
Due to the fact that this problem affects a big number of domains and machines and The revocation of this kind of certificates is more complicated than in other cases because we need to define the substitution plan and it involves more people and resources, we will not be able to meet the deadlines, so, we are going to open another bug for this delay in the revocation.

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

Despite we have had problems and some certificates were issued after the first communication of the problem, the CA stopped issuing certificates and it has not issued any from September 30th.

  1. 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.
    InfoCert Organization Validation CA 3 -> 334
    InfoCert Organization Validation 2019 CA 3 -> 80
    Intesa Sanpaolo Organization Validation CA -> 1222
    Intesa Sanpaolo Organization Validation 2019 CA -> 4
  1. 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.

We’ll add this info this week.

  1. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

As we explained in the previous comments, the problem has happened because of a misinterpretation of the point 7.1.4.2.2.f) belonged to Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.
In this case, we misunderstood the requirement that indicates that the subject:stateOrProvinceName field MAY contain the full name of the Subject’s country information as verified under Section 3.2.2.1. but it can only be applied if the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX because we thought that XX was the sample of the field format.
We think that an express prohibition for the value of the field subject:stateOrProvinceName would have been useful to avoid this kind of problems in the future.
And, just to clarify, we want to inform that the meaning of the term “State” is not the same in all countries and in Italy state is a synonym of country and is not used for provinces.

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

With the situation caused by this problem, we have noticed that we do not have enough information and control about the profiles created by our SubCAs and need to establish a review process of the profiles created by them.
So, from now on, we are going to create a test plan for every new SubCA created to harmonize profiles.

Can you explain more about how it took Camerfirma 5 days to stop issuing certificates with this issue and why Camerfirma decided not to halt issuance until this issue was fixed? As per Immediate Actions:

In misissuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI. In situations not involving misissuance, there also may be processes that need to be stopped until you have diagnosed the source of the problem.

Once the problem is diagnosed, you may restart the process even if a full fix is not rolled out, if you are able to put in place temporary or manual procedures to prevent the problem from re-occurring. You should not restart the process until you are confident that the problem will not re-occur.

Hi George, Ryan.

The SubCA affected is from an external PKI belonging to our parent firm Infocert. Infocert issue SSL certificates with their own technical infrastructure. Infocert is one of the biggest European TSP with a broad expertise in trust services compliance.
We notify immediately the problem to them in order to stop the certificate issuing. They initially were reluctant to accept that this was a misissuing because the BR misunderstanding. George you know we have been interchanging emails about this subject.
We finally order to stop issuing or otherwise removing the problematic extension in the certificate profile. This obviously was not executed immediately, fact that we are going to investigate internally and fix any procedural mismatch. We also will proceed with more extreme decision if it was necessary to guarantee the fulfilment of the BR and Mozilla Policy.

Updated number of certs:

InfoCert Organization Validation CA 3 -> 230
InfoCert Organization Validation 2019 CA 3 -> 71
Intesa Sanpaolo Organization Validation CA -> 868
Intesa Sanpaolo Organization Validation 2019 CA -> 3

Thanks Juan, is this list finalised or is the scan ongoing?

Flags: needinfo?(martin_ja)

George, we think that they're the final lists.

We're still studying it cause some issues with censys.io queries.

https://censys.io/certificates?q=issuer.province=Italy+and+authority_key_id=8832BF09FB4239F472432068B8CFAC8A92785D0C+and+precert=0

It explicitly exclude precerts and returns 9 unexpired certs.

But we have 8 unexpired certs.

I found that the query returns one precert :-( https://censys.io/certificates/5d1d86ffeb9dd2fde765ff08388ea0f4ec3fa019ca059b0bf41654393e264899

Flags: needinfo?(martin_ja)

We want to update items #2 and #7 of the Incident Report:

Item #2
(Updated timeline) :

• September 25th (done): When we received the notification of this bug, we contacted the affected CAs immediately to inform them about the situation,
• September 28th (done): Study the case and what the possible misinterpretation with the help of the reporters who added comments in the bug
• September 29th (done): detect all the affected certificates with the problem and
• September 30th (done): stop issuing certificated with the affected profiles
• September 30th (done): Change of the profiles with error
• September 30th (done): Establish a plan for their substitution and revocation
• October 1st (done): Beginning of the substitution process
• October 15th: Revocation of 202 certificates relating to the sub CAs "InfoCert Organization Validation 2019 CA 3" and "InfoCert Organization Validation CA 3"
• January 15th, 2021: Revocation of the remaining 970 certificates, relating to the two major customers, an energy supplier and the main Italian bank.

Revocation in a short time in these two customers could cause an incident with a relevant impact on the customer's business. Safe replacement couldn’t be done in a shorter period of time.
The certificates involved in this case are used in many mission critical customer services, used by millions of end users.
The replacement of certificates in the production environment will be realized in small blocks, with a test phase following installation, so it will take a long time to complete the activities.
The revocation will therefore be carried out progressively, from October 1st to January 15th 2021, starting with the least critical services. As soon as possible, in agreement with the customers, we will provide a detailed plan with the expected revocation dates for the certificates. We also will keep you informed on a periodical basis on the progress of the plan.

Item #7

In order to prevent this error from happening again we took two new measures:

  1. InfoCert instructed the Validation Specialists to avoid issuing new certificates with an invalid stateOrProvinceName field. ( September 29th)
  2. Implementation of a software change to prevent the issuance of new invalid certificates (October 1st)
Flags: needinfo?(eusebio.herrera)

I'm concerned with a revocation timeline that takes more than 2 months to complete. What in particular makes these certificates so hard to replace? Echoing Ryan's comment in bug 1668523, large companies such as these should be able to replace these certificates within a few hours/days through automation. What is Camerfirma doing to ensure that these companies will be able to quickly replace certificates if another revocation event occurs?

How do these companies deal with regular renewals?

Flags: needinfo?(eusebio.herrera)

(In reply to Ramiro Muñoz Muñoz from comment #15)

We notify immediately the problem to them in order to stop the certificate issuing. They initially were reluctant to accept that this was a misissuing because the BR misunderstanding. George you know we have been interchanging emails about this subject.

In bug 1556806, Camerfirma's lack of control of SubCAs was already an issues. It seems this didn't improve at all.

Regarding revocation, bug 1556806 comment 13 is relevant: "7. Provide a contingency plan for certificate revocation and replacing with end users. Define different scenarios to face a hypothetical situation of multiple revocation. (new)". This didn't actually happen?

(In reply to paul.leo.steinberg from comment #25)

(In reply to Ramiro Muñoz Muñoz from comment #15)

We notify immediately the problem to them in order to stop the certificate issuing. They initially were reluctant to accept that this was a misissuing because the BR misunderstanding. George you know we have been interchanging emails about this subject.

In bug 1556806, Camerfirma's lack of control of SubCAs was already an issues. It seems this didn't improve at all.

Regarding revocation, bug 1556806 comment 13 is relevant: "7. Provide a contingency plan for certificate revocation and replacing with end users. Define different scenarios to face a hypothetical situation of multiple revocation. (new)". This didn't actually happen?

Hi Paul
As you said we have previously faced several scenarios with the Camerfirma SubCAs, and we are still improving all procedures and tools to control their activities. An annual Webtrust Audit report obviously is not enough. Just to give an idea of our structure, we currently have 5 SubCAs, only 3 of them issuing SSL certificate, and using their own PKI technology: two of them from Infocert, our parent company and Multicert.
We have been improving in different ways.

1.- Camerfirma not only have adapted its customers terms and conditions in order they were aware and fully aligned with the BR and Mozilla policy, but has reinforced resources involved in SubCA control. We have improved the contractual commitment with our customers accepting a possible unilateral certificate revocation from Camerfirma. Nevertheless, we think that we should not create a bigger damage than one we try to avoid.

As a result of this new scenario, last week we have revoke one of our SubCA (affected by the OCSP EKU issue), after a complex process since it was issuing certificates for the Spanish medical services. No security impact has been detected during this process.

2.- All SubCAs already use our local Camerfirma Lint and Zlint controls service, pre and post issuing. We also need to improve this controls since it has not been enough, for example to avoid this bug.

3.-We already have a SubCA request protocol to be accepted and fulfilled by our customers before proceed, revocation contingency plan included. It is true that this contingency plan is not completely deployed in all our SubCAs, but we are working on detecting high critical services where our SSL certificates are installed to ask for a specific contingency plan.

lesson learned in this bug is about profiles harmonization in all our SubCA, mainly those which we do not run our PKI infrastructure. Scenario we plan to avoid in future projects.

(In reply to george from comment #24)

I'm concerned with a revocation timeline that takes more than 2 months to complete. What in particular makes these certificates so hard to replace? Echoing Ryan's comment in bug 1668523, large companies such as these should be able to replace these certificates within a few hours/days through automation. What is Camerfirma doing to ensure that these companies will be able to quickly replace certificates if another revocation event occurs?

How do these companies deal with regular renewals?

The long period for remediation is only referred to the big bank that use two of the involved CA and the certificates are 870.

Few customers, as in this case, due to the type of activity, for some certificates cannot use automation for certificate replacement. For some services, they have complex installation cases (firewalls, balancers, web servers, applications, and so on). In addition, often large customers have legacy applications that don’t allow high automation.

Regular renewals, with many departments engaged and different installation types, usually are made manually or partially automated by internal organization teams, and they are planned in time to avoid the expiration of the certificate before the new one is installed.

Emergency procedures are always defined by customers, able to revoke certificates and replace them in a short time, but with high risks on the service availability. A standard change approach by project was chosen, which advantage the service availability over the time required and does not affect the capacity of the customer's internal structures, with a progressive replacement and revocation of certificates.

However we have planned a revision of the contingency plan to include also the worst scenario in which all certificates or a great number of them must be revoked, to improve customers automation, in order to install certificates in a shorter time.

Flags: needinfo?(eusebio.herrera)

I'd like to keep the revocation discussion focused on Bug 1668331, but I'd like to highlight that Camerfirma's current plan really fails to meet the expectations, especially in line with the continued pattern of issues we're seeing here. I am further deeply disturbed by Comment #15, specifically:

We notify immediately the problem to them in order to stop the certificate issuing. They initially were reluctant to accept that this was a misissuing because the BR misunderstanding.

and

We finally order to stop issuing or otherwise removing the problematic extension in the certificate profile. This obviously was not executed immediately

This suggests a lax oversight of the third-parties that Camerfirma is bringing into the Mozilla program, and that's concerning. I realize you highlighted that:

We also will proceed with more extreme decision if it was necessary to guarantee the fulfilment of the BR and Mozilla Policy.
and
We have improved the contractual commitment with our customers accepting a possible unilateral certificate revocation from Camerfirma. Nevertheless, we think that we should not create a bigger damage than one we try to avoid.

However, those were already expected of Camerfirma. Camerfirma should have been designing its PKI to ensure that robustness. There are a number of technical approaches that Camerfirma could have taken to supervise the third-party and minimize damage.

I think my deep unease here is that these were things Camerfirma knew ahead of time, which have existed as requirements for the better part of 7 years, and thus needs to design controls. In particular, I think of all the statements offered by Camerfirma, this one is the most bothersome to me:

And, of course we have never considered the possibility to issue any certificates violating the CPS or BR and this problem was involuntary due to a misinterpretation.

This should have been the forefront of the design, and should be the forefront of the design.

I'd like to focus the revocation delay discussion on Bug 1668331, and request Camerfirma post appropriate updates and a complete and full incident report on that bug. I'd like to keep this focused on the situation that originally lead to the issue. I can see a number of issues that need addressing by Camerfirma:

  • Supervision of Sub-CAs is lacking. We need a full analysis of root causes and mitigations being applied.
  • Understanding of the BRs is lacking. We need a full analysis of root causes and mitigations being applied.
  • Understanding of why repeated promises from Camerfirma, as captured in Comment #25, failed to prevent this issue. We need a full analysis of root causes and mitigations being applied.

Regarding the revocation status:

  1. 172 of the 202 certificates issued by "InfoCert Organization Validation 2019 CA 3" and "InfoCert Organization Validation CA 3" has been revoked. For the revocation of the remaining certificates we are in contact with customers who have asked us to wait so that they can proceed with the replacement of certificates without undermining the availability of their processes and the security of their users.
  2. 109 of the 871 certificates issued by "Intesa Sanpaolo Organization Validation 2019 CA" and "Intesa Sanpaolo Organization Validation CA" has already been revoked.

Eusebio: As mentioned in Comment #28, please continue the revocation process discussion within Bug 1668331

This is so that we can appropriately keep this issue focused on the invalidity issue and resolution, and separately the issues with revocation.

(In reply to Ryan Sleevi from comment #28)
Hi Ryan
I will try to answer your questions:

Supervision of Sub-CAs is lacking. We need a full analysis of root causes and mitigations being applied.

In case of SubCAs that issue certificates using our own platform, we can guarantee that no certificate is issued after giving the order to stop.
This SubCAs issue certificates using a different platform that does not belong to Camerfirma. We found that the order to stop was not applied at that moment because their own personnel and procedures restrictions.

We have added some actions to enhance the SubCA control:

a) Before the order was understood by the SuBCA we were discussing about if it was really a misissuing. A preventive action procedure will be incorporate in our contract to stop immediately when any issue appear (we are studying with our legal department the possibility of introduction of some legal penalty clauses). Once this was clarified we can order either to start again or stop definitely. This will help us to mitigate the impact in case a real misissuing were produced.

b) The SubCA SSL certificate profile was not harmonized with the Camerfirma design. We will Improve he control over their profiles by making a Camerfirma quality control approvement of all the new profiles before passing them into production.

Understanding of the BRs is lacking. We need a full analysis of root causes and mitigations being applied.

It's really complicated to establish controls to avoid BR misundestanding in the future. There have been many cases and discussion about BR interpretations and misunderstandings. BR is continuously improving its wording precisely because of that. Nevertheless, we will be involved in the different user cases raised by CABFORUM members to learn from real situations.

In this specific cases AC Camerfirma interpretation about this stateorprovicename attribute was different form our SubCA profile designers maybe because we are in different countries and different legal concepts about the term "state".

We were not able to detect this different interpretation during this time. It is true that the lint tool is not enough to detect it, therefore we are going to review all profiles issued from our external SuBCA and force to validate by camerfirma. Any new profile or any modification of them.

Understanding of why repeated promises from Camerfirma, as captured in Comment #25, failed to prevent this issue. We need a full analysis of root causes and mitigations being applied.

We already have implemented some measures that we explained in old bugs:
Addendum for all the clients indicating that we can revoke the certificates in case of error to comply with the BR.
Our new massive revocation and substitution process that permits perform the tasks more easily and quickly.
You can find the diagram with the steps of the process attached in the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1623384
Regarding the contingency plan it’s not been easy to deploy since we need the collaboration from the final customer, this is especially difficult when we are dealing with big companies as it’s the case. We are also planning to implement ACME solution to automate the substitution process, but I insist this is complex to deploy in these systems with numerous environments and technologies.

We have the technical tools to execute a massive revocation to fulfil the BR requirement we also are covered by the contractual agreements. We also have the tools to issue the new certificates in a short period of time to substitute the misissued ones. Our challenge is to make this substitution when the customer is not able (because different and comprehensive reasons) to do it in the period requested. We are working with our customer to be aware of a quick revocation so a quick substitution process must be put in place in order to avoid damages when revocation was produced.

We expect that all this measures we are implementing are efectives in the shortest period of time.

Regards
Ramiro

This weekend, after some aditional checks we have detected 27 aditional certificates with this issue. All of these 27 certificates were issued by "InfoCert Organization Validation CA 3".
Please, find attached the list of certificates.

We keep the revocation deadline that was given in the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1668331

Attached file 27certs.txt —

Serials

We have just published this batch of certificates on misissued.com

https://misissued.com/batch/192/

There is no update regarding this matter from our part since 2020-12-22.

Do you consider this bug could be closed or do you need extra information about it?

(In reply to Eusebio Herrera from comment #32)

This weekend, after some aditional checks we have detected 27 aditional certificates with this issue. All of these 27 certificates were issued by "InfoCert Organization Validation CA 3".
Please, find attached the list of certificates.

1.) Could you elaborate why it took 2 months between the batches of Comment 20 and this new batch[0] to be discovered?
This seems like a very long time without any indication that a search for misissued certificates is still ongoing; or any research whatsoever without intermediate updates of ongoing searches, and especially after the following:

(In reply to Juan Angel Martin from comment #22)

George, we think that they're the final lists.

2.) Have you finished your search for certificates that have been misissued with this problem?

[0] https://misissued.com/batch/192/

Hi Matthias,

(In reply to your comment #36)

It took us as much time to have the definitive list of affected certificates because of some discrepancies with the lists obtained by us and our CA.

When the problem was detected we notified the problem and ask Infocert and Intesa Sanpaolo to investigate the number of affected certificates.

In the meantime, we obtain the list from our systems to verify and compare, but our list and theirs were not the same and both of us had to confirm the data obtained.

Finally, they discover that their query had an error and did not include alll the parameters needed and that was why they detected fewer certificates.

After the query was corrected, we compared the list and they contained the same number of certificates, so we verified that we had obtained the correct list to revoke.

However, we are now performing a manual review for all the StateOrProvince included in all the certificates issued by Infocert and Intesa Sanpaolo just to confirm that there are not any more cases and we will inform you about it as soon as we finish it.

Flags: needinfo?(ana.lopes)

(In reply to Ana Lopes from comment #37)

However, we are now performing a manual review for all the StateOrProvince included in all the certificates issued by Infocert and Intesa Sanpaolo just to confirm that there are not any more cases and we will inform you about it as soon as we finish it.

Thanks for your reply, it helps me understand the current situation. If I understand correctly, you're currently still analyzing the certificates in your CA hierarchy to confirm that no other unrevoked and unexpired certificates exist with this issue.

If my understanding is correct, could you explain why Comment #35 (albeit indirectly) asked to close this issue? Asking for an issue to be closed seems out of place while your analysis is still ongoing.

Attached file 8 Fingerprints —

We want to inform that we have already finished our manual review.

During this review we detected 8 more affected certificates (January 12th). You can find the list on: fingerprints.txt

Those certificates were issued for San Marino and their StateOrProvince was Borgo Maggiore instead of Città di San Marino due to a misinterpretation of the regions of San Marino (castles are the districts equivalent to the Italian provinces). After the detection of the error, they were immediately revoked (January 12th).

Regarding the revocation progress of the pending ones (27), up to date we have already revoked 19 and we have only 8 more pending to revoke. We continue with the planification to have them revoked by January 15th.

(In response to Matthias Comment #38) We gave that information by mistake. At that time, we had finished the first review but we had started the manual review to confirm that we had obtained the complete list of certificates affected.

As we informed in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1668331#c22 we have already revoked all the affected certificates (January 15th)

We do not have more updates for this bug.

We do not have more updates for this bug.

We do not have more updates for this bug.

We do not have more updates for this bug.

We do not have more updates for this bug.

We do not have more updates for this bug.

We do not have more updates for this bug.

We do not have more updates for this bug.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ov-misissuance]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: