Closed Bug 1550575 Opened 7 months ago Closed 5 months ago

Asseco DS / Certum: commonName not from subjectAltName entries

Categories

(NSS :: CA Certificate Compliance, task)

3.37
task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wtrapczynski, Assigned: wtrapczynski)

Details

(Whiteboard: [ca-compliance])

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

Actual results:

This is an incident report for the issue according to https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

  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.

We became aware during our regular crt.sh lint tools review.

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

May 6, 2019 16:51 GMT – The first certificate with Common Name value not from Subject Alternative Name was issued.
May 7, 2019 12:41 GMT – The second certificate with Common Name value not from Subject Alternative Name was issued.
May 8, 2019 05:00 GMT – We became aware of these two misissuances.
May 8, 2019 05:50 GMT – We found the reason for these two misissuances.
May 8, 2019 06:00 GMT – We blocked possibilities of issuance of further certificates with such error by disallowing the possibility of making a correction (workaround).
May 8, 2019 14:00 GMT – We finished scan our certificates database. We did not find any other certificates with such error.
May 8, 2019 16:00 GMT – We prepared fix for software and decided to deploy it on production in the next scheduled deployment (at the end of May).

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

May 8, 2019 06:00 GMT.

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

Two certificates.

First certificate notBefore date: May 6 16:51:00 2019 GMT.
Last certificate notBefore date: May 7 12:41:31 2019 GMT.

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

https://crt.sh/?id=1442328124&opt=cablint
https://crt.sh/?id=1442458558&opt=cablint

These certificates have been revoked.

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

This mistake is the result of software bug. For the two profiles of our SSL certificates the process of data correction was not implemented correctly. If registration inspector had to change some data in certification request, like Locality Name or Organizational Unit Name, the value from Common Name was removed from Subject Alternative Name.

The bug avoided detection until now because there was no proper test scenario for such case.

  1. 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 fixed the bug in the software. We plan to deploy it on production at the end of the May 2019.

We added the test scenario for verify whether value from Common Name is present in Subject Alternative Name.

We are in progress of developing the pre-issuance linting and as I mentioned in the other thread, we plan to run it by the end of June 2019.

Assignee: wthayer → wtrapczynski
Whiteboard: [ca-compliance] - Next Update - 01-June 2019
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Type: defect → task

Today (03.06.2019) we  fixed our software, this bug no longer appears. As Wojciech mentioned above we are in progress of developing the pre-issuance linting.

Is it correct that the estimated timeline is 30-June-2019?

We already have the pre-issuance linting service done. What we need to do is to finish an integration the pre-issuance linting service with the main application for issuing SSL certificates and it is almost done. Initially, the production installation was scheduled on 30 June 2019. Now, we know that it will be next month. The reason for the delay is that the implementation of pre-issuance linting will be part of a larger update and we must to give our partners some time to become familiar with the changes. We plan to install it on test environment next week.

Until we have implemented it, we keep follow the procedure of periodic verification I have described in bug 1495518.

Do you have an update?

Flags: needinfo?(wtrapczynski)
Flags: needinfo?(wthayer)

I can confirm that our plan does not change. I will keep you informed.

Flags: needinfo?(wtrapczynski)

Wojciech: Your plan from Comment #3 describes production installation by 30 June 2019 originally scheduled, but then does not provide a new date. It states testing would be done a week following Comment #3, but there have been no updates on the results of such test, nor further clarification about new dates.

I'm trying to get a clear picture of specific dates as to when progress is to be made, so that we can assess appropriate next steps. I appreciate periodic verification, but at present, it sounds like that is your only proposed remediation, in the absence of binding commitments to concrete timelines for remediation steps.

Flags: needinfo?(wtrapczynski)

My apologies for not notifying you about the test results. I can confirm that test was done according to the schedule and was successful.

Now, we are ready to deploy pre-issuence linting to production. We will do it before 27th July. I will keep you informed.

Flags: needinfo?(wtrapczynski)
Flags: needinfo?(wthayer)
Whiteboard: [ca-compliance] - Next Update - 01-June 2019 → [ca-compliance] - Next Update - 28-July 2019

We deployed fully automatic pre-issuance linting for SSL certificates in production on 17th July, 2019.

It appears that all questions have been answered and remediation is complete.

Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Whiteboard: [ca-compliance] - Next Update - 28-July 2019 → [ca-compliance]
You need to log in before you can comment on or make changes to this bug.