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 firstname.lastname@example.org 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.
- 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.
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
- 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.
- 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.
- 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
- Microsec introduced the automatic CABLINT and ZLINT checks for each TLS certificates which replaced the former manual checks.
- 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.
- 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
- 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.