1825232 - SwissSign: Invalid CT data in issued certs (SABRE.CT misconfiguration)

Status: RESOLVED INVALID

(CA Program :: CA Certificate Compliance, task)

Description

[Roman Fischer]

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 the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.

One of our employees became aware of the following article and noticed that SwissSign is mentioned https//sslmate.com/blog/post/march_2023_ct_blunders
He informed the compliance team to have a look at the article.

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

Date / time description
20230328, 09:00 CEST E-Mail of the employee to compliance
20230328, 09:30 CEST Internal compliance incident is opened
20230328, 13:15 CEST Operations team investigated if we issued certificates with less than three correct Signed Certificate Timestamps (SCTs) and confirmed the misissuance
20230329, 12:35 CEST Publishing this incident report
20230329, 14:00 CEST Contact involved customers and revocation will be done latest 20230401 18:00 CEST

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.

The misissuance stopped at March 16 at 1228 UTC when Sectigo corrected the wrong software configuration from private key of test log "Dodo" back to the public key.

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.

4 SSL certificates (March 15-16)

5. In a case involving TLS server 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. It is also recommended that you use this form in your list "https//crt.sh/?sha256=[sha256-hash]", unless circumstances dictate otherwise. When the incident being reported involves a SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

Certificate serial number Leaf certificate Pre-certificate
56847961d410399658c6045cdda7277473b9845e https://crt.sh/?id=8899904540 https://crt.sh/?id=8899904593
3e5e25c03222457b6fea5981e8233f2d0af9a1c3 https://crt.sh/?id=8899629504 https://crt.sh/?id=8899629437
4236e71f214b92b9011209ccdaf7f2293ad11b8b https://crt.sh/?id=8900106967 https://crt.sh/?id=8900106886
76e904c58f9aa76b36be8301c412302c505c7abe https://crt.sh/?id=8900976417 https://crt.sh/?id=8900976548

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

The signature validation on SCTs was not performed properly.

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. The steps should include the action(s) for resolving the issue, the status of each action, and the date each action will be completed.

a. Revocation of the affected certificates: 01 April 2023, 18:00 CEST latest
b. Analysis why the SCT signature validation check failed. Define improvement measures: 2023-04-06 16:00 CEST
c. Implementation of improvement measures: Date to be determined

Comment 1

[Andrew Ayer]

Although these certificates contain SCTs from a test log, they nevertheless comply with RFC6962, the BRs, and Mozilla/Apple/Chrome Root Store Policies, since none of these policies mandate that certificates be logged to particular logs. Therefore, revocation and an incident report aren't required, and this bug should be closed as INVALID.

Of course, these certificates won't be accepted by CT-enforcing user agents, so it's definitely a good idea to fix the problem, and any insights on the cause of the issue would certainly be helpful for other members of the ecosystem.

Comment 2

[Ben Wilson]

I'll close this as "Invalid" on Friday, 31-March-2023, unless there are other reasons not to.