Closed Bug 1525710 Opened 10 months ago Closed 10 months ago

Amazon: Test revoked certificates with invalid validity period


(NSS :: CA Certificate Compliance, task)

Not set


(Not tracked)



(Reporter: ryan.sleevi, Assigned: trevolip)


(Whiteboard: [ca-compliance])

On, Amazon disclosed the following misissuance

Hi Wayne,

This is a report about the certificates used by software vendors for testing. Specifically the "revoked" ones we make for Amazon Trust Services.

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

When creating the certificates that software vendors can use to test revoked certificates we set the validity period to incorrectly be 39 months and included an incorrect subject which makes the certificates appear to be EV certificates. As part of our post ceremony validation we ran cablint on all certificates on 2/1/2019. After doing this we discovered that our revoked certificates had been incorrectly formatted.

  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.
  • 1/28/2019 - We created 5 certificates for the purpose of providing test revoked certificates. Upon creation of each certificate, they were revoked about a minute later.
  • 2/1/2019 - While going through the steps to verify the ceremony artifacts we ran cablint on the certificates and discovered that the revoked certificates were being identified as EV certs and were valid for 39 months.
  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.

We will not issue test revoked certificates with an incorrect validity or subject again.

  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.

5 certificates, all created on 1/28/2019

  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 IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

I will send out a link to the certs once we have uploaded them. All 5 have the same issue.

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

When the validity period for certificates changed with ballot 193 to 825 days we didn't update the default validity period or the guardrail that limits the maximum validity period for test revoked certificate generation. This didn't impact other certificates, such as our test "good" certificates which already defaulted to 13 months and the guardrail already limited the validity period to not be longer than 825 days.

  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've updated the script to default to 13 months for test revoked certificates and the guardrail so that these types of test certs cannot have a validity period of longer than 825 days.
  • We've updated the commands template to have the correct subject.
Assignee: wthayer → trevolip
QA Contact: kwilson → wthayer
Whiteboard: [ca-compliance]

Test certificates from these CAs were first generated in October 2015 with 39 month validity. While we had ceremonies since that time as part of the controls for WebTrust audit, we did not include renewal of these certificates until 2019. We did and do have a process for updating our CP/CPS when CA/B Forum and root program requirements change. Our CPS correctly contained the 825 day change from Ballot 193. However, we didn't have a step in our off-line issuance to review artifacts prior to signing against our CPS.

We have updated our off-line issuance process to require review of artifacts both prior to and following issuance against our CPS. We have also added a requirement to lint artifacts both prior to and following issuance. Either of these two changes would have caught the fact we had not changed the template for these test certificates to comply with Ballot 193.

Flags: needinfo?(wthayer)

It appears that remediation is complete.

Closed: 10 months ago
Flags: needinfo?(wthayer)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.