1670894 - SwissSign: Invalid stateOrProvinceName field

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[George [:fozzie]]

SwissSign has issued one certificate with a stateOrProvinceNameField value of "CH":

• https://crt.sh/?q=44168BA54324E06889855DF501F5176D518F96D867ADD75B640CEAB73702192A

This is quite worrying as in bug 1551364 SwissSign assured us that they did not require any technical constraints to limit the values in this field.

Comment 1

[Mike Guenther]

This is the inital report by SwissSign

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.

Bugzilla 1670894 posted by George on 20201013

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.

20201013 02:12 PDT Posting by George
20201013 10:54 CEST Mail from George informing us about the misissuance
20201013 Internal investigation started
20201014 10:30 CEST Implementation of policies for localityName and stateOrProvinceName for the involved customer
20201014 11:41 CEST Responding to George's mail
20201014 14:07 CEST revoked the certificate
20201014 17:53 CEST posting this incident report

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 matter is still under investigation so the root cause is still unclear. Therefore we cannot make this pledge at this time

We can confirm that for this customers there will be no more mis-issuances (see 6).

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.

See 5 and 6

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.

5e4134e69ba74a3cb59a171f7e0dfaec28254f4c (found by George). The certificate is revoked

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

Our initial analysis revealed that this customer does not have a policy for the fields localityName and stateOrProvinceName in place. This has been remediated immediately.

Why these policies were missing is currently being investigated.

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.

a) Looking for the root cause of the missing policies
b) as soon as root cause is known: check for potentially additional customers with the same issue
c) Set policies for identified additional customers
d) revoke possible mis-issued certificates of these additional identified customers

Comment 2

[Ryan Sleevi]

Thanks for the update. However, I note that there isn't a "binding timeline of when your CA expects to accomplish each of these remediation steps"

I realize this is probably a preliminary report, since it's lacking quite a bit of deal, but I'm hoping you can clarify when we can expect the actual/proper incident report.

Comment 3

[Mike Guenther]

@Ryan: At the time of the initial report we did not have enough information to give a binding timeline. With this update we are able to commit to specific dates.

Update to initial report
2 Timeline Update
20201016 List of all customers that were able to issue certificates without a policy for localityName and/or stateOrProvinceName
20201016 Implementation of policies for all identified customers (will be done eob)

3 Stopped issuance of certificates
We can confirm that we have implemented the policies for the localityName and/or stateOrProvinceName of 35 identified customers (eob today).

4/5 Summary of problematic certificates/ List of certificates
We are now looking into all certificates of the identified customers. We will update this post on Monday.

6 Explanation
In https://bugzilla.mozilla.org/show_bug.cgi?id=1613334 we introduced an additional technical control which is implemented in a new service. Our first guess was that the new service had a undetected bug.

Therefore, we developed an independent tool to create a report which delivered us the identified customers. Based on this information we are now remediating this bug.

After this is done we will look into the reason why these specific customers were not identified by the service.

7 Steps to be taken
a) Ongoing
b) done, we identified 35 customers where policies were only partly implemented
c) Will be done eob 20201016
d) Revocation: we will have a confirmed list on Monday. All identified certificates will be revoked at the latest on Friday, 23 October 2020

Next Update on Monday, 19 October 2020 by Torsten

Comment 4

[Ben Wilson]

Thank you, Mike

Comment 5

[Torsten Kahlstadt]

Update to report by SwissSign

2. Timeline Update
20201019 Results of certificates with false localityName and/or stateOrProvinceName
20201019 Contacting all affected customers: Informing them that we will revoke the certificates until Friday, 23 October 2020.

4. Summary of problematic certificates
We identified a total of 21 certificates from 7 customers that had either a false locality and/or state

5. List of certificates
https://crt.sh/?id=2166368604
https://crt.sh/?id=2370542447
https://crt.sh/?id=2365797488
https://crt.sh/?id=3112450404
https://crt.sh/?id=2891735042
https://crt.sh/?id=3192556161
https://crt.sh/?id=2897420657
https://crt.sh/?id=2897450024
https://crt.sh/?id=2975311105
https://crt.sh/?id=2388418071
https://crt.sh/?id=2180123883
https://crt.sh/?id=2180113472
https://crt.sh/?id=2180105048
https://crt.sh/?id=1721704376
https://crt.sh/?id=1679991947
https://crt.sh/?id=2388432226
https://crt.sh/?id=2180153367
https://crt.sh/?id=2180139004
https://crt.sh/?id=3080684051
https://crt.sh/?id=2181076311
https://crt.sh/?id=2392208643

7. Steps to be taken
a. Ongoing
b. done, we identified 7 customers where policies were only partly implemented
c. Done
d. Revocation:

1. Done: Info to customers
2. Revocation at the latest on Friday, 23 October 2020

Comment 6

[Torsten Kahlstadt]

Final Report SwS

2. Timeline Update
   20201023 All 7 customers were contacted, and the revocation agreed
   20201023 All 21 identified certificates were revoked
   20201023 We checked once again the certificates for any wrong or missing data

The identified 21 certificates were revoked in consultation with the 7 customers.

Comment 7

[Ben Wilson]

In Comment #3, your Incident Report item 7 said you were:
a) Looking for the root cause of the missing policies
b) as soon as root cause is known: check for potentially additional customers with the same issue
c) Set policies for identified additional customers
d) revoke possible mis-issued certificates of these additional identified customers

Comment #5 stated:
a. Ongoing
b. done, we identified 7 customers where policies were only partly implemented
c. Done
d. Revocation

However, I do not believe that the incident report can be considered final without addressing: (a) the root cause (stated as "ongoing") and (c) those policies that were adopted and now enforced for such customers ("done", but unclear what "done" means). What has actually been done in these areas?

Comment 8

[Mike Guenther]

Hi Ben Sorry for being late to update this post. The problem has been solved some time ago and we are coming back to you with our latest update to address your requests concerning a) and c).

Concerning the point a) Looking for the root cause of the missing policies:
In our systems the localityName and stateOrProvinceName are defined in policies for each customer. When we decided to implement the technical workflow we searched for existing policies for each customer. Here is where the mistake happened. The query was built in such a way that only policies with content in the corresponding field were shown. These policies were then corrected. The customers affected by this bug had policies with the fields localityName and stateOrProvinceName in place but they were empty and did not show in our search which then lead to these misissuances.

Concerning c): c) Set policies for identified additional customers
This means that all affected customers have now the correct policy set. Therefore only the configured localityName and stateOrProvinceName can be used by the customers.

I hope this addresses your questions.

Comment 9

[Ben Wilson]

I will close this on next Wednesday 3-Feb-2021 unless there are additional questions or issues to discuss.