Open Bug 1728384 Opened 3 months ago Updated 3 months ago

Microsec: Misissuance of one OV certificate with Key Usage KeyEncipherment

Categories

(NSS :: CA Certificate Compliance, task)

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: szoke.sandor, Assigned: szoke.sandor)

Details

(Whiteboard: [ca-compliance])

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

Steps to reproduce:

MICROSEC INCIDENT REPORT - Misissuance of 1 OV certificate with Key Usage KeyEncipherment


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

Microsec received an email based incident report to info@e-szigno.hu at Tuesday, August 31, 2021 9:36 AM


II -- 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-08-31 07:36 UTC
  • receive a notification email about the incorrectly issued TLS certificate
2021-08-31 08:27 UTC
  • Microsec customer service officer processed the incoming email and opened an internal Bug
2021-08-31 08:42 UTC
  • initiating an investigation to identify the cause(s) of the error and to prevent further similar errors
2021-08-31 09:54 UTC
  • contacting the site owner and informing them about the planned revocation
2021-08-31 10:12 UTC
  • revocation of the incorrect certificate

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

The quick investigation confirmed that the current policy documents and certificate profiles are OK and that there is no need to suspend the certificate issuance.


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

2020-03-09
  • One OV certificate with ECC key was issued with an incorrent Key Usage bit setting

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

domain crt.sh link
v2x-pki.com https://crt.sh/?id=2730469679

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

We performed the initial investigation and we found the following

2018-04-21
  • Microsec installed an automatic check in the CA software which limits the usability of the different certificate profiles according to the type of the public key in the enduser certificate. The operation is based on a configuration file, which lists the allowed certificate profiles for a given key type in a given ICA.
2020-03-05
  • version 2.13 of our public policies was released. This included the correct requirement for KU bits in case of ECC key.
  • certificate profiles were updated according to the CP change to use version 2.13 CP OID values. Certificate profiles included the appropriate KU setting for ECC based certificates.
2020-03-09
  • The OV certificate was issued under our RSA based ICA "e-Szigno SSL CA 2014", but for an ECC end-entity key. Microsec does not usually mix different key types, it was an exception event that we have issued a certificate for en ECC key from an RSA based CA hierarchy.
  • The RO officer issued the certificate using the default RSA certificate profile
  • The CA allowed the issuance of the certificate for the ECC key with an RSA certificate profile due to a configuration problem
  • The certificate became faulty because an improper certificate profile was used for issuance, which resulted the incorrect KU setting
  • The manual immediate post issuance quality control check did not recognize the fault
2021-01-07
  • Microsec introduced the automatic CABLINT and ZLINT checks for each TLS certificates which replaced the former manual checks.
2020-2021
  • Microsec developed its certificate policy management system in two steps during 2020 and 2021. It results higher accountability and minimize the risk of misissuance.

Summary of the findings

The misissuance was caused by a configuration problem in the certificate profile management system

  • RO officer selected the standard RSA based certificate profile for the ECC key in the RSA based CA (it is not her/his task to check the key type)
  • the RSA based certificate profile was allowed for ECC keys in the RSA based CA due to a configuration problem (configuration fault)
  • the certificate was issued with improper KU bits
  • the manual immediate post issuance quality control check did not identify the problem
  • the following quarterly quality control check did not select this specific certificate to re-check in April 2020

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

Immediate actions

  • Microsec revoked the affected OV TLS certificate within 3 hours.
  • Microsec has verified all active certificate profiles, they were OK at the time of misissuance, and they are still OK.
  • Microsec has verified all active policy documents, they were OK at the time of misissuance and they are still OK.
  • A quick initial investigation was made to find out the reason of the misissuance.
  • Microsec identified the causes of the misissuance as you see it above.
  • Microsec has verified the configuration of the certificate profiles in the CA software, it is OK.
  • Microsec checked all the valid certificates for this type of problem, there is no more certificate with this problem.
  • Microsec opened an incident bug in Mozilla's Bugzilla with the present report.

Further planned actions

Deadline: 2021-09-15
  • Microsec will check wether the present controls are sufficient to prevent a misissuance with this problem again.
  • Microsec will keep a training for the RO operators how to use the proper certificate profiles according to the type of the enduser key.

Assignee: bwilson → szoke.sandor
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance]

STATUS REPORT 2021-09-15


New activities and results

2021-09-15 - Training for Registration Officers

Microsec held a short reminder training for Registration Officers.
The training covered the importance of the end-user key type (ECC or RSA) and, for some certificate types, the different KU requirements.
The Registration Officer should pay more attention to selecting the appropriate certificate profile according to the type of key.

2021-09-15 - Checking existing controls

Microsec has reviewed existing measures to see if they are sufficient to prevent similar incidents or not.

The internal investigation found that a number of measures have been put in place since the misissuance, which together provide sufficient protection to avoid further issuance with a similar problem.
Some of them are:

  • each RSA-based certificate profile has an ECC-based pair that has the same profile name but begins with "e-" prefix. None of the RSA-based profiles begin with "e-".
  • a certificate profile configuration has been introduced in each CA hierarchy that lists the acceptable profile names in that CA hierarchy. If the selected certificate profile is not included in the configuration, the CA will refuse to issue the certificate.
  • both the CA program code and the CA configuration data are managed from SVN, and checked regularly
  • certificate profiles are also managed from SVN and checked regularly
  • cablint and zlint checks have been introduced on all certificates issued prior to publication

Further planned actions

No furter action is planned according to this incident.

You need to log in before you can comment on or make changes to this bug.