1. 4
  1.  

  2. 2

    I have so many questions. So they knew the cert would expire, and decided to let it happen, believing it would be okay.

    But when? Did they notice the expiration a month in advance and then sit on their hands? But why do nothing? Or was it only noticed one day before, where maybe it’s better not to do anything drastic? But then why was it noticed so late?

    Also, were they planning on ever renewing the cert? If it had worked as they thought, would we still be using an expired cert in 2020?

    1. 1

      This is addressed in the linked Technical Report:

      The server-side teams whose systems (e.g., Autograph) generate signatures knew the certificate was expiring, but did not see a problem because they had reason to believe that signing certificate dates were not checked by the client.

      The client-side teams whose code performs add-on validation knew that dates were not checked for end-entity certificates (we modified this behavior in a previous outage), but might not have realized that dates for intermediate certificates were still checked when invoking the nsIX509CertDB function in the core SSL library.

      Can highly recommend reading the full report.

      1. 1

        I’ve read it. It still lacks basic details like was the server side team ever planning to renew the cert? They didn’t see a problem with expiration and were willing to leave it expired forever?

        1. 1

          Afaiu, the idea is that an expired cert should not invalidate all existing addons. Saving us from a scenario where we resign the world and everyone needing to update all of their addons.