Hi, For what it's worth, I think this kind of intentional end-to-end testing is good, and what testing CT logs and roots are for. Like negative tests, it demonstrates your pipeline actually works (and is not rejecting the bad certificates just because it's broken), and as a side effect it allowed us to test the community's ability to catch certificates issued from bad public keys.
I'm mentioning this because I want you and other CAs to feel encouraged to, not discouraged from, this kind of testing. Agreed on maybe surfacing public trust information in crt.sh, which is available behind the Issuer click. https://crt.sh/?caid=251252 Cheers, Filippo 2022-10-24 14:05 GMT+02:00 'Lahtiharju, Pekka' via [email protected] <[email protected]>: > Hi Ben, > > We are not using Debian at all. We just took one random vulnerable key from > vulnerable key archive from Debian weak key list because we wanted to test > what will happen in our test code with such key. The purpose of this test was > to use seriously bad key when bypassing our normal ways to detect and prevent > it. > > We didn’t expect this test key/certificate to go to any CT log that is used > for CT monitoring. > > Br Pekka > > *From:* Ben Laurie <[email protected]> > *Sent:* maanantai 24. lokakuuta 2022 12.04 > *To:* Lahtiharju, Pekka <[email protected]> > *Cc:* Hanno Böck <[email protected]>; [email protected] > *Subject:* Re: Certificate with Debian OpenSSL bug issued > > > > > On Mon, 24 Oct 2022 at 07:07, 'Lahtiharju, Pekka' via > [email protected] <[email protected]> wrote: >> Hi Hanno, >> >> This is not publicly trusted TLS certificate but only Telia's test >> certificate. Issuer is our test issuer "Telia PreProd Server CA v3" (not >> publicly trusted). >> >> Telia was testing new Badkeys/Lint implementation and we wanted to do also >> one test without Badkeys/Lint with vulnerable key to see if anything else >> would prevent such key. According to our information CT log "Dodo" that was >> used is non-production CT log and could be used for such tests with >> non-trusted TLS certificates (Mammoth and Sabre are Sectigo's production CT >> logs). I hope this kind of testing is OK? Or should we keep such test >> certificates internal only without any CT publishing? >> > > The certificate aside, having the problem suggests you were running a very > ancient version of Debian - is that wise, even in test environments? > >> >> Best Regards >> >> Pekka Lahtiharju >> Senior Development Manager | Trust Services >> Telia Finland >> +358407061299 <tel:+358%2040%207061299> >> [email protected] >> www.telia.fi >> Telia Finland Oyj, Helsinki 1475607-9 >> >> >> >> -----Original Message----- >> From: [email protected] <[email protected]> On >> Behalf Of Hanno Böck >> Sent: sunnuntai 23. lokakuuta 2022 16.15 >> To: [email protected] >> Subject: Certificate with Debian OpenSSL bug issued >> >> Hi, >> >> A few days ago a certificate with a key vulnerable to the 2008 Debian >> OpenSSL bug was issued by Telia: >> https://crt.sh/?id=7799145606 >> >> It's a 4096 bit RSA key generated with a vulnerable debian version on >> 64 bit. >> >> -- >> Hanno Böck >> https://hboeck.de/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:dev-security-policy%[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20221023151433.7002479b%40computer. >> >> This email may contain information which is privileged or protected against >> unauthorized disclosure or communication. If you are not the intended >> recipient, please notify the sender and delete this message and any >> attachments from your system without producing, distributing or retaining >> copies thereof or disclosing its contents to any other person. >> >> Telia Company processes emails and other files that may contain personal >> data in accordance with Telia Company’s Privacy >> Policy<https://www.teliacompany.com/en/about-the-company/privacy/>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:dev-security-policy%[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AS1PR07MB8688F4317AE188F9EFCE44C1E12E9%40AS1PR07MB8688.eurprd07.prod.outlook.com. >> > > > -- > You received this message because you are subscribed to the Google Groups > "[email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AS1PR07MB8688A78506942360543FF0D4E12E9%40AS1PR07MB8688.eurprd07.prod.outlook.com > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AS1PR07MB8688A78506942360543FF0D4E12E9%40AS1PR07MB8688.eurprd07.prod.outlook.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6a844802-74ac-4026-8e32-72dd083fd506%40app.fastmail.com.
