1784820 - CFCA: Delayed reporting of intermediate CA certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[bixinlong]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0

Actual results:

We found this while dealing with another incident (https://bugzilla.mozilla.org/show_bug.cgi?id=1741497). We have reported the root certificate in the same day. CFCA has not issued any certificates after the root was created.

Comment 1

[bixinlong]

Incident report:

1. Problem Report:
   CFCA have not report CFCA DV OCA information in CCADB timely.

2. Timeline:
June 17, 2022: Ben Wilson asks whether reported CFCA DV OCA (SHA2 = B8BE2649AA518E943BF0FD1E34A240443E46E79EA7B562E09FCC830AC7D2F3FC) in the CCADB.
June 19, 2022: CFCA received this message and reported CFCA DV OCA in the CCADB on June 19.

3. Statement
CFCA have reported CFCA DV OCA.

4. Summary
CFCA has reported CFCA DV OCA (SHA2 = B8BE2649AA518E943BF0FD1E34A240443E46E79EA7B562E09FCC830AC7D2F3FC) in the CCADB. We didn’t issue any certificates after the intermediate certificate was created, this has not affected any institutions or individuals.

5. Explanation:
We misunderstood the rules, I mistakenly thought that we need report after we getting the audit report and before formally issuing certificate. We will never conduct unauthorized business without any information release, so CFCA has not issued any certificates after the root was created.

6. Steps:
We will add some relevant information or procedures as required.

Comment 2

[Ryan Dickson]

Hello CFCA,

Looking at the certificate for CFCA DV OCA, it appears to be in conflict with Section 7.1.2.2 of the Baseline Requirements ("Subordinate CA Certificate") - both the current Version (1.8.4) and the one in effect at the time of subordinate CA certificate issuance (1.7.5):

7.1.2.2 Subordinate CA Certificate
...
...
...

g. extKeyUsage (optional/required)
For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate operated in accordance with these Requirements, this extension MAY be present. If present, this extension SHOULD NOT be marked critical. This extension MUST only contain usages for which the issuing CA has verified the Cross Certificate is authorized to assert. This extension MAY contain the anyExtendedKeyUsage [RFC5280] usage, if the Root Certificate(s) associated with this Cross Certificate are operated by the same organization as the issuing Root Certificate.

For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates:
This extension MUST be present and SHOULD NOT be marked critical.

For Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The value
id-kp-clientAuth [RFC5280] MAY be present. The values id-kp-emailProtection [RFC5280], id-kp-codeSigning [RFC5280],
id-kp-timeStamping [RFC5280], and anyExtendedKeyUsage [RFC5280] MUST NOT be present. Other values SHOULD NOT be present.

For Subordinate CA Certificates that are not used to issue TLS certificates, then the value id-kp-serverAuth [RFC5280] MUST NOT be present. Other values MAY be present, but SHOULD NOT combine multiple independent key purposes (e.g. including id-kp-timeStamping [RFC5280] with id-kp-codeSigning [RFC5280]).

Specifically, concerning EKU, "For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates:
This extension MUST be present and SHOULD NOT be marked critical."

Can you please help us reconcile this difference?

Thanks,
Ryan

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:kwilson, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[bixinlong]

(In reply to Ryan Dickson from comment #2)

Hello CFCA,

Looking at the certificate for CFCA DV OCA, it appears to be in conflict with Section 7.1.2.2 of the Baseline Requirements ("Subordinate CA Certificate") - both the current Version (1.8.4) and the one in effect at the time of subordinate CA certificate issuance (1.7.5):

7.1.2.2 Subordinate CA Certificate
...
...
...

g. extKeyUsage (optional/required)
For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate operated in accordance with these Requirements, this extension MAY be present. If present, this extension SHOULD NOT be marked critical. This extension MUST only contain usages for which the issuing CA has verified the Cross Certificate is authorized to assert. This extension MAY contain the anyExtendedKeyUsage [RFC5280] usage, if the Root Certificate(s) associated with this Cross Certificate are operated by the same organization as the issuing Root Certificate.

For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates:
This extension MUST be present and SHOULD NOT be marked critical.

For Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The value
id-kp-clientAuth [RFC5280] MAY be present. The values id-kp-emailProtection [RFC5280], id-kp-codeSigning [RFC5280],
id-kp-timeStamping [RFC5280], and anyExtendedKeyUsage [RFC5280] MUST NOT be present. Other values SHOULD NOT be present.

For Subordinate CA Certificates that are not used to issue TLS certificates, then the value id-kp-serverAuth [RFC5280] MUST NOT be present. Other values MAY be present, but SHOULD NOT combine multiple independent key purposes (e.g. including id-kp-timeStamping [RFC5280] with id-kp-codeSigning [RFC5280]).

Specifically, concerning EKU, "For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates:
This extension MUST be present and SHOULD NOT be marked critical."

Can you please help us reconcile this difference?

Thanks,
Ryan

Hi Ryan,

Thanks for your reminding and sorry for the late reply. During this period, we are verifying and looking for solutions, we also communicated with our auditer and determined the solutions together.

The next step, we will re-sign the incorrect certificate and synchronize the information as soon as possible.

Comment 5

[Ben Wilson]

Please prioritize your efforts to comply with requirements for CA certificate profiles and your CCADB reporting requirements for such CAs.
Thanks,
Ben

Comment 6

[Gao Fei]

(In reply to Ben Wilson from comment #5)

Please prioritize your efforts to comply with requirements for CA certificate profiles and your CCADB reporting requirements for such CAs.
Thanks,
Ben

Hi Ben,

Thank you for your reminder. Once the certificate is re-signed and verified, we will synchronize the information as soon as possible.

Thanks,
Gao Fei

Comment 7

[Mathew Hodson]

(In reply to Ryan Dickson from comment #2)

Looking at the certificate for CFCA DV OCA, it appears to be in conflict with Section 7.1.2.2 of the Baseline Requirements ("Subordinate CA Certificate") - both the current Version (1.8.4) and the one in effect at the time of subordinate CA certificate issuance (1.7.5):

Looks like CFCA created bug 1793053 for this issue.

Comment 8

[Ben Wilson]

Regarding the statement in Comment #1, that the CA certificate was uploaded into the CCADB, I do not see it there. See also https://crt.sh/mozilla-disclosures Therefore, the CA certificate still needs to be uploaded to the CCADB, and then it needs to be marked as "revoked". This itself is another violation - of section 4 of the CCADB Policy, which says, "If an intermediate certificate is revoked, the CCADB must be updated to mark it as revoked, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason." https://www.ccadb.org/policy#4-intermediate-certificates
CFCA needs to do this as soon as possible, and I will open a new incident in Bugzilla for CFCA to prepare an incident report.

Comment 9

[Gao Fei]

(In reply to Ben Wilson from comment #8)

Regarding the statement in Comment #1, that the CA certificate was uploaded into the CCADB, I do not see it there. See also https://crt.sh/mozilla-disclosures Therefore, the CA certificate still needs to be uploaded to the CCADB, and then it needs to be marked as "revoked". This itself is another violation - of section 4 of the CCADB Policy, which says, "If an intermediate certificate is revoked, the CCADB must be updated to mark it as revoked, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason." https://www.ccadb.org/policy#4-intermediate-certificates
CFCA needs to do this as soon as possible, and I will open a new incident in Bugzilla for CFCA to prepare an incident report.

Hi Ben,
We have re-uploaded the intermediate certificate CFCA DV OCA (https://crt.sh/?id=6970868811) to CCADB on 2022-11-08 and marked it as revoked. Additionally, we have provided incident reports at https://bugzilla.mozilla.org/show_bug.cgi?id=1798812.

thanks,
Gao Fei

Comment 10

[Ryan Dickson]

Gao, in the spirit of helping close this bug, can you share a final (and complete) incident report for this bug (focused on the ICA disclosure failure) using the format described here - to include specific discussion on root cause analysis and the steps taken to prevent reoccurrence in the future)?

Comment 11

[Gao Fei]

(In reply to Ryan Dickson from comment #10)

Gao, in the spirit of helping close this bug, can you share a final (and complete) incident report for this bug (focused on the ICA disclosure failure) using the format described here - to include specific discussion on root cause analysis and the steps taken to prevent reoccurrence in the future)?

Hi Ryan,thanks for your suggestion. The complete incident report is as follows.

Comment 12

[Gao Fei]

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.

2022-06-17, Ben Wilson informed that CFCA DV OCA failed to report to CCADB within 7 days of creation, in the comments of https://bugzilla.mozilla.org/show_bug.cgi?id=1741497.

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.

2021-06-23:Create the new ICA--CFCA DV OCA (https://crt.sh/?id=6970868811).After the new ICA was created, we have not done any business or issued certificates.
2022-06-17:Received the notification that CFCA DV OCA failed to report to CCADB within 7 days of creation.
2022-06-19:Report CFCA DV OCA in the CCADB.

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.

CFCA reported CFCA DV OCA to CCADB on 2022-06-19.

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.

Number of certs:1
2021-06-23:Create the new ICA--CFCA DV OCA ,and failed to be reported to CCADB within 7 days of creation.
https://crt.sh/?id=6970868811

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.

Number of certs:1
2021-06-23:Create the new ICA--CFCA DV OCA ,and failed to be reported to CCADB within 7 days of creation.
https://crt.sh/?id=6970868811

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

Our previous person in charge Bi Xinlong misunderstood the rules, he mistakenly thought that it was necessary to report to CCADB after receiving the audit report and before officially issuing the certificate.

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.

1.Since September 2021, the arrangement: Gao Fei, Qiu Dawei, and Li Kairui jointly completed the review and comparison of PKI policies (RFC, BR, EVG, Root policy, CT policy, etc.), Bugzilla case review and reply, CCADB maintenance, CPS revision and audit, etc.
2.We implement a double-check mechanism. For CCADB operations, etc., Qiu Dawei or Li Kairui writes the operation steps and plans, and submits them to Gao Fei for review to ensure that the operation steps and time meet the requirements.
3.In October 2022, we updated the“CCADB Management Measures”.In order to more standardize the implementation of certificate operation and management.

Comment 13

[Gao Fei]

In the past year, CFCA has improved its work through the following measures:

1. Arrange multiple people to be responsible for PKI policy tracking, Bugzilla incident response and handling, CCADB maintenance, etc.;
2. Formulate and update some relevant documents of management norms;
3. Use Zlint to automate detection;
4. Actively promote ACME automation;

CFCA remains open and transparent, actively faces and solves problems, and will continue to improve our processes and technical means in the future.

This case has been discussed in detail and has been improved. There is no new content recently. Apply to close this case, thanks.

Comment 14

[Ben Wilson]

I will close this case on or about Friday, 30-June-2023, unless there are issues still to discuss.