1534145 - SSL.com: P-384 curve / ecdsa-with-SHA256 certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Fotis Loukos posted the following incident report to the mozilla.dev.security.policy list:

Problem description

SSL.com has issued a limited number of ECDSA certificates with
curve-hash pairs that are no longer allowed by the Mozilla Root Store
Policy.

In particular, section 5.1 states that:

Root certificates in our root program, and any certificate which
chains up to them, MUST use only algorithms and key sizes from the
following set:

• ECDSA keys using one of the following curve-hash pairs:
  • P‐256 with SHA-256
  • P‐384 with SHA-384

A number of certificates which do not use these pairs have been issued.
In particular, certificates were issued using the P-384 curve /
ecdsa-with-SHA256 pair.

It should be noted that all of these certificates are compliant with the
CA/B Forum Baseline Requirements, but not with the current Mozilla Root
Store Policy, as it was amended at version 2.4 the 1st of March 2017.

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.

On Monday, 25 February 2019, a manual review of some certificates that
were going to be issued was conducted by multiple teams within SSL.com
instead of the compliance team only, and the problem was identified.

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.

• 01/03/2017 - Version 2.4 of the Mozilla Root Store Policy was
  published which limits the allowed curve-hash pairs for the ECDSA algorithm.
• 01/03/2017 - The differences between version 2.3 and 2.4 of the Policy
  were communicated between the different departments of SSL.com, without
  including the limits on the allowed curve-hash pairs.
• 25/02/2019 - A manual review of some certificates that were going to
  be issued was conducted by multiple teams within SSL.com. It was
  identified that the curve-hash pair was illegal and no certificates were
  issued.
• 25/02/2019 - As a result an investigation was performed and found that
  additional certificates had been issued using the same curve-hash pair.
  The incident response process formally began.
• 25/02/2019 - In addition to the end-user certificates this
  investigation found several CAs certificates that were created with this
  set of parameters.
• 26/02/2019 - Issuance of all ECDSA certificates was suspended and a
  plan of action for remediation of this issue begun.
• 26/02/2019 - Mozilla was contacted and was made aware of the issue.
• 26/02/2019 - We reviewed all linters and we found that we had none for
  the Mozilla Root Store Policy requirements.
• 26/02/2019 - To improve both pre-issuance and post-issuance auditing,
  we reviewed all Mozilla technical requirements and implemented linters
  for each one to ensure continued compliance.
• 26/02/2019 - These linters were executed against the entire corpus of
  certificates to ensure all associated certificates were identified.
• 27/02/2019 - Restructuring of the mode of operation of the compliance
  team begun in order to ensure better monitoring of browser policies.
• 07/03/2019 - The configuration of all production CAs was modified to
  prevent the future issuance of certificates using these parameters.
• 07/03/2019 - All misissued end-user certificates were revoked.
• 07/03/2019 - To mitigate this issue we took the decision to revoke all
  associated CAs including those created before the Mozilla policy was
  created prohibiting these curves to ensure we meet the highest possible
  level of security and compliance.
• 07/03/2019 - Issuance of ECDSA certificates was resumed.

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.

All issuance of ECDSA certificates was suspended when we realized the
Mozilla Root Store Policy compliance issue.

After fixing the certificate profiles to limit the curve-hash pairs,
revoking the old SubCAs and issuing new ones using the P-384 curve and
ecdsa-with-SHA384, ECDSA certificate issuance was resumed.

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.

The total number of certificates that were issued using curve-hash pairs
not compliant with the Mozilla Root Store Policy are:

• CA Certificates: 10 certificates from Dec 17 2018 to Feb 14 2019
• SSL Certificates: 15 certificates from Apr 24 2018 to Feb 25 2019
• OCSP Responder certificates: 11 certificates from May 29 2018 to Feb
  20 2019

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.

Please find attached the files cacerts.csv, sslcerts.csv and
ocspcerts.csv that contain a full list of all problematic certificates.

Please note that this is not the complete list of the certificates that
were revoked, but only the ones that were not in compliance with the
Mozilla Root Store Policy.

Explanation about how and why the mistakes were made or bugs

introduced, and how they avoided detection until now.

Before version 2.4 of the Mozilla Root Store Policy there were no
restrictions on the possible allowed curve-hash pairs when using P-256
and P-384 with SHA256 and SHA384. Thus, our initial set up included the
P-384 with SHA-256 pair. This changed with version 2.4 and was clarified
at 2.4.1. Unfortunately, the change was not communicated to the
technical team. When this was clarified at 2.4.1, it seemed as a
clarification to a practice which we already implement.

Furthermore, SSL.com implements linting of the tbsCertificate structure
before using the CA key to perform any signing operation (either
pre-certificate or certificate). However, the set of linters we use
(certlint/cablint and zlint) lint against RFC5280 and the CA/B Forum
Baseline Requirements, and not the Mozilla Root Store Policy.

The issue was not identified during any of the audits, since it is not
an auditable criteria being part only of the Mozilla Root Store Policy.

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 have taken several different steps to ensure that we will not have
such issues again in the future.

• We have introduced changes in the compliance department, and our team
  will monitor closely all changes in the Mozilla Root Store Policy as
  they are reflected at the github repository. These changes will be
  handled in a similar fashion to the CA/B Forum Baseline Requirements and
  other similar compliance requirements.
• We have already created a linter that checks against the specific
  requirements set by the Mozilla Root Store Policy. This linter is set up
  to lint the tbsCertificates at the same time as the aforementioned linters.
• The compliance department will provide feedback to the team that
  maintains the linter in order to keep it up to date.

Comment 1

[Wayne Thayer]

All remediation has been completed and it appears there there are no questions on the incident report.