CA Certificate Compliance

I reported the following batch of certificates to incidentes@camerfirma.comhttps://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.

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)

  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.

Read More

ترك الرد

من فضلك ادخل تعليقك
من فضلك ادخل اسمك هنا