Found something I can't understand in these cerificates.

https://crt.sh/?id=7040227 https://crt.sh/?id=30328289 I am confused for those reasons. 1. the CN of two cerificates are same. So it is not necessary to issue two certificates in just 2 minutes. 2. second one used SHA1, though is consistent with BR, but first one used SHA256. 3. first one has

Symantec: Draft Proposal

So Mozilla think Symantec's issues are on t serious enough to lose trust entirely? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

A question:How would a domain holder express denial for certain certificate requests? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Find a 5-year certificate

I have found this: https://crt.sh/?id=6885329 I don't know whether Mozilla had allowed the certificate valid more than 39 months, so I am here to verify it. I have searched on Github but found nothing. ___ dev-security-policy mailing list

Re: Does Heartbleed count for the purposes of BR 4.9.1.1 point 11? ("proven or demonstrated method")

在 2019年5月27日星期一 UTC+8上午10:05:25，Matt Palmer写道： > On Sun, May 26, 2019 at 06:57:08PM -0700, Han Yuwei via dev-security-policy > wrote: > > If malloc() is correctly implemented, private keys are secure from > > Heartbleed. So > > I think it doesn't meet the criteria. &g

Re: Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")

If malloc() is correctly implemented, private keys are secure from Heartbleed. So I think it doesn't meet the criteria. CAs can't revoke a certificate without noticing subscriber in advance. But if any bugs found in future which can retrieve private keys from TLS endpoints, you can just use

Reported Digicert key compromise but not revoked

Hi m.d.s.p I have reported a key compromise incident to digicert by contacting support(at)digicert.com at Apr.13, 2019 and get replied at same day. But it seems like this certificate is still valid. This certificate is a code signing certificate and known for signing malware. So I am here to

Re: CAA record checking issue

This raised a question: How can CA prove they have done CAA checks or not at the time of issue? 在 2019年5月10日星期五 UTC+8上午10:05:36，Jeremy Rowley写道： > FYI, we posted this today: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1550645 > > > > Basically we discovered an issue with our

Re: Reported Digicert key compromise but not revoked

Thanks for that. So now I should send another email to rev...@digicert.com or just wait for revocation? And who should I contact if this address doesn't work? 在 2019年5月10日星期五 UTC+8上午8:26:09，Jeremy Rowley写道： > No argument from me there. We generally act on them no matter what. > Typically any