Re: New SHA-1 certificates issued in 2016
On Sat, Nov 05, 2016 at 09:09:49AM +, Gervase Markham wrote: > > If they had sent an incident report to Mozilla I would agree, but I do > > not think that CAs should be credited for noticing mistakes when they > > try to sweep them under the rug. This is particularly true in the case > > of SHA-1 misissuance, where revoking without broader notification > > demonstrates not competence but rather a lack of understanding of the > > risks. > > Your point being that if they do disclose, the community can then run > crypto analysis over the cert to see if it's likely to be constructed as > part of a collision attempt? I think in general we want to hear from CAs about any incident, including BR violations. For all the bugs we filed in bugzilla about SHA-1, 1024 bit RSA keys, and so on there should be an incident report, and it should _at least_ be mentioned in their audit. But they really should send such incident reports to all root programs at the moment they knew about it. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 04/11/16 23:51, Andrew Ayer wrote: > The March 2016 CA communication said[1]: > > "It has been pointed out in the mozilla.dev.security.policy forum that > a chosen-prefix attack on SHA-1 could be used to forge a certificate if > a CA's private key is used to sign *anything* with SHA-1." > > Therefore, CAs participating in the Mozilla program know that this > practice is dangerous. This is true; however, unfortunately, I don't believe this amounts to a requirement that CAs should not use SHA-1 at all any more. > Frankly, I'm disappointed that despite my efforts to draw attention to > this issue in March, both in the context of non-serverAuth certificates[2] > and OCSP responses[3], Mozilla took no further action, such as > amending Mozilla policy or proposing a CABF ballot to plug this hole. Your disappointment stings. > If they had sent an incident report to Mozilla I would agree, but I do > not think that CAs should be credited for noticing mistakes when they > try to sweep them under the rug. This is particularly true in the case > of SHA-1 misissuance, where revoking without broader notification > demonstrates not competence but rather a lack of understanding of the > risks. Your point being that if they do disclose, the community can then run crypto analysis over the cert to see if it's likely to be constructed as part of a collision attempt? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On Fri, 4 Nov 2016 10:30:00 + Gervase Markham wrote: > We need to recall that currently, SHA-1 issuance is not banned > directly by Mozilla policy, but only by the BRs. And so we don't have > a route to object to certs not covered by the BRs. The March 2016 CA communication said[1]: "It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1." Therefore, CAs participating in the Mozilla program know that this practice is dangerous. Frankly, I'm disappointed that despite my efforts to draw attention to this issue in March, both in the context of non-serverAuth certificates[2] and OCSP responses[3], Mozilla took no further action, such as amending Mozilla policy or proposing a CABF ballot to plug this hole. > >> D) Small numbers (1 or 2) of SHA-1 certs issued in early January. > >> One could perhaps charitably say that the CA or their subCA made a > >>mistake, realised, has fixed it, and hasn't made it since. Now > >> it's November, is this worth chasing? (4 CAs) > >> > >> Also, does it make it better if the CA has already revoked the > >> certificate before we report it to them? > > > > No. Revocation doesn't help because the forged/collided cert need > > not share the same serial number. Revocation would only help if it > > were based on the SHA-1 hash of the TBSCertificate. > > We are not _just_ looking at SHA-1 issuance through the lens of > collision; it's also a compliance and competence issue. I think a CA > which issues a SHA-1 cert and doesn't notice seems less competent than > one which does notice and immediately revokes it and doesn't issue > another. If they had sent an incident report to Mozilla I would agree, but I do not think that CAs should be credited for noticing mistakes when they try to sweep them under the rug. This is particularly true in the case of SHA-1 misissuance, where revoking without broader notification demonstrates not competence but rather a lack of understanding of the risks. Regards, Andrew [1] https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o00iHdtx [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/DEgLsxMfBAAJ [3] https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02999.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On Friday, November 4, 2016 at 4:49:28 AM UTC-7, Gervase Markham wrote: > On 03/11/16 18:09, Andrew Ayer wrote: > > This is just as bad as signing an actual cert with SHA-1. > > Add: > https://bugzilla.mozilla.org/show_bug.cgi?id=1315225 (Symantec) > > Gerv I updated the bug to say that this was disclosed back in March and discussed on https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/64$3Aa9$3A32$3A73$3Aa4$3A19$3Ad1$3A64/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 04/11/2016 11:21, Gervase Markham wrote: On 03/11/16 21:17, Jakob Bohm wrote: Note that the GlobalSign SHA-1 intermediaries chain only to their old SHA-1 root which is (I believe) not used for any SHA-256 certs, except a cross-cert that signs their current SHA-256 root. Nevertheless, it is still in Mozilla's trust store. As it needs to be until the last general usage BR-compliant SHA-1 certificates issued in 2015 expire on or before 2016-12-31 23:59:60 UTC So I suspect the intent of GlobalSign is that the old SHA-1 root should loose its ServerAuth trust bit around 2017-01-01, reducing it to a SHA-1-forever root trusted only by old SHA-1-only systems and maybe for e-mail (because some non-Mozilla e-mail clients were very late to supporting SHA-2 e-mail signatures). If this were true, a) that's not good enough, as SHA-1 issuance has been banned by the BRs since 2016-01-01, and b) they would have needed to file a bug for this trust change long ago, and I can't find one. I seem to recall the 3 certs were around new years (but on the wrong side). The names suggest they are administratively (but not technically) constrained to e-mail and similar certificates. They really should have been technically constrained, but to do so now would entail issuing at least one *new* SHA-1 cert with technical constraints, reissuing the all the derived certs then revoking the 3 technically unconstrained intermediaries that were issued near the start of 2016. Besides the administrative overhead of contacting all certificate holders, this would stop the risk that collisions are used to generate fake unrevokable certificates chaining to the intermediaries, but add one more SHA-1 value signed by the root and potentially attackable via 2nd preimage collision attacks. But I do not represent GlobalSign, I am only making informed guesses based on available public information. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 03/11/16 18:09, Andrew Ayer wrote: > This is just as bad as signing an actual cert with SHA-1. Add: https://bugzilla.mozilla.org/show_bug.cgi?id=1315225 (Symantec) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
We need to recall that currently, SHA-1 issuance is not banned directly by Mozilla policy, but only by the BRs. And so we don't have a route to object to certs not covered by the BRs. On 03/11/16 18:09, Andrew Ayer wrote: >> B) SHA-1 email certificates with no DNS names, although their lack of >>an EKU means they are valid for server auth (2 CAs) > > The more pertinent question is the issuing CA's EKU. In one case, I have now noticed that the intermediate is revoked in OneCRL. (Still learning how to use crt.sh.) In the other case, there are two certificates with the issuing key, and neither has an EKU. >> C) SHA-1 email certificates with EKU but no serverAuth (1 CA) > > Ditto. 2 certs with the issuing key, no EKU in either. >> D) Small numbers (1 or 2) of SHA-1 certs issued in early January. One >>could perhaps charitably say that the CA or their subCA made a >>mistake, realised, has fixed it, and hasn't made it since. Now it's >>November, is this worth chasing? (4 CAs) >> >> Also, does it make it better if the CA has already revoked the >> certificate before we report it to them? > > No. Revocation doesn't help because the forged/collided cert need not > share the same serial number. Revocation would only help if it were > based on the SHA-1 hash of the TBSCertificate. We are not _just_ looking at SHA-1 issuance through the lens of collision; it's also a compliance and competence issue. I think a CA which issues a SHA-1 cert and doesn't notice seems less competent than one which does notice and immediately revokes it and doesn't issue another. > The common thread in all of these answers is that the forged/collided > certificate need not look anything like the data that the CA signed > with SHA-1. Any time a CA trusted for serverAuth signs > attacker-controlled data using SHA-1 there is a risk of a forged > serverAuth certificate. Right. But if a CA has signed a cert or two in January and none since, one could perhaps surmise that SHA-1 issuance has ceased (albeit a few days after it should have). Which is why I question whether pursuing such cases now adds much value. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 03/11/16 21:17, Jakob Bohm wrote: > Note that the GlobalSign SHA-1 intermediaries chain only to their old > SHA-1 root which is (I believe) not used for any SHA-256 certs, except > a cross-cert that signs their current SHA-256 root. Nevertheless, it is still in Mozilla's trust store. > So I suspect the intent of GlobalSign is that the old SHA-1 root should > loose its ServerAuth trust bit around 2017-01-01, reducing it to a > SHA-1-forever root trusted only by old SHA-1-only systems and maybe for > e-mail (because some non-Mozilla e-mail clients were very late to > supporting SHA-2 e-mail signatures). If this were true, a) that's not good enough, as SHA-1 issuance has been banned by the BRs since 2016-01-01, and b) they would have needed to file a bug for this trust change long ago, and I can't find one. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 03/11/2016 18:53, Gervase Markham wrote: On 28/10/16 16:11, Patrick Figel wrote: I found a number of SHA-1 certificates chaining up to CAs trusted by Mozilla that have not been brought up on this list or on Bugzilla yet. Using the handy crt.sh link posted by Rob, I have gone through the 2016 SHA-1 issuances known to crt.sh to filter out those which chain up to a root trusted by Mozilla. (Handily, crt.sh contains this information as well.) There are a distressingly large number of them :-( ... and based on this additional research, I have filed: ... https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign) Note that the GlobalSign SHA-1 intermediaries chain only to their old SHA-1 root which is (I believe) not used for any SHA-256 certs, except a cross-cert that signs their current SHA-256 root. The recent "revocation runaway" incident was caused by GlobalSign revoking the cross signing of their old SHA-1 root by their current SHA-256 root. So I suspect the intent of GlobalSign is that the old SHA-1 root should loose its ServerAuth trust bit around 2017-01-01, reducing it to a SHA-1-forever root trusted only by old SHA-1-only systems and maybe for e-mail (because some non-Mozilla e-mail clients were very late to supporting SHA-2 e-mail signatures). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On Thu, 3 Nov 2016 17:53:01 + Gervase Markham wrote: > On 28/10/16 16:11, Patrick Figel wrote: > > I found a number of SHA-1 certificates chaining up to CAs trusted by > > Mozilla that have not been brought up on this list or on Bugzilla > > yet. > > Using the handy crt.sh link posted by Rob, I have gone through the > 2016 SHA-1 issuances known to crt.sh to filter out those which chain > up to a root trusted by Mozilla. (Handily, crt.sh contains this > information as well.) There are a distressingly large number of > them :-( > > Based on Patrick's report, I filed: > https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain) > https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert) > https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign) > > and based on this additional research, I have filed: > https://bugzilla.mozilla.org/show_bug.cgi?id=1315019 (TeliaSonera) > https://bugzilla.mozilla.org/show_bug.cgi?id=1315016 (Visa) > https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign) > https://bugzilla.mozilla.org/show_bug.cgi?id=1315035 (T-Systems) > > There may be more in the future. I would be interested in the group's > opinion on what to do about: > > A) SHA-1 precerts with no actual cert logged (1 CA) This is just as bad as signing an actual cert with SHA-1. RFC6962 says: "The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate)." This is not just a theoretical concern. When this came up earlier this year with Symantec, I explained that pre-certificates are a vector for exploiting a SHA-1 collision, since the forged/collided certificate need not contain the pre-certificate poison extension. > B) SHA-1 email certificates with no DNS names, although their lack of >an EKU means they are valid for server auth (2 CAs) The more pertinent question is the issuing CA's EKU. > C) SHA-1 email certificates with EKU but no serverAuth (1 CA) Ditto. > D) Small numbers (1 or 2) of SHA-1 certs issued in early January. One >could perhaps charitably say that the CA or their subCA made a >mistake, realised, has fixed it, and hasn't made it since. Now it's >November, is this worth chasing? (4 CAs) > > Also, does it make it better if the CA has already revoked the > certificate before we report it to them? No. Revocation doesn't help because the forged/collided cert need not share the same serial number. Revocation would only help if it were based on the SHA-1 hash of the TBSCertificate. The common thread in all of these answers is that the forged/collided certificate need not look anything like the data that the CA signed with SHA-1. Any time a CA trusted for serverAuth signs attacker-controlled data using SHA-1 there is a risk of a forged serverAuth certificate. Regards, Andrew ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 28/10/16 16:11, Patrick Figel wrote: > I found a number of SHA-1 certificates chaining up to CAs trusted by > Mozilla that have not been brought up on this list or on Bugzilla yet. Using the handy crt.sh link posted by Rob, I have gone through the 2016 SHA-1 issuances known to crt.sh to filter out those which chain up to a root trusted by Mozilla. (Handily, crt.sh contains this information as well.) There are a distressingly large number of them :-( Based on Patrick's report, I filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain) https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert) https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign) and based on this additional research, I have filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1315019 (TeliaSonera) https://bugzilla.mozilla.org/show_bug.cgi?id=1315016 (Visa) https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign) https://bugzilla.mozilla.org/show_bug.cgi?id=1315035 (T-Systems) There may be more in the future. I would be interested in the group's opinion on what to do about: A) SHA-1 precerts with no actual cert logged (1 CA) B) SHA-1 email certificates with no DNS names, although their lack of an EKU means they are valid for server auth (2 CAs) C) SHA-1 email certificates with EKU but no serverAuth (1 CA) D) Small numbers (1 or 2) of SHA-1 certs issued in early January. One could perhaps charitably say that the CA or their subCA made a mistake, realised, has fixed it, and hasn't made it since. Now it's November, is this worth chasing? (4 CAs) Also, does it make it better if the CA has already revoked the certificate before we report it to them? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 28/10/16 16:11, Patrick Figel wrote: > I found a number of SHA-1 certificates chaining up to CAs trusted by > Mozilla that have not been brought up on this list or on Bugzilla yet. > Apologies in case I missed prior discussion for any of these, and kudos > to censys for making this search incredibly easy. See also: https://crt.sh/?cablint=211&minNotBefore=2016-01-01 (Note: This shows all SHA-1 certs with notBefore dates in 2016 that are known to crt.sh. Some of these certs might not be trusted by Mozilla) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 03/11/16 04:25, c...@cem.me wrote: > Gerv, Given the discussions in the past about risks of SHA-1 issuance > for *any* cert type, and the responses from action #1c from the March > 2016 CA communication, are there any public plans for dealing type of > certificate yet? As in, do we have plans for banning SHA-1 issuance outright? Not at the moment, because there are lots of complex edge cases. A good step which provides much of the same protections is to simply stop accepting them, which we plan to do in January next year (for publicly-trusted roots). > Do these non-server-certs only fall under the BR's > sigAlg policy if a generated certificate collision has an EKU of > server auth? (And by that time, is it too late?) Like I said, the scope of the BRs is debateable. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On Saturday, October 29, 2016 at 12:02:54 PM UTC-5, Gervase Markham wrote: > The scope of the BRs is debateable. These certs are clearly in scope for > Mozilla policy, as they chain up to trusted roots; however Mozilla > policy does not (yet) ban SHA-1 issuance other than via the BRs. This > may be fixed in policy version 2.3. > > Without tls-server-auth and with other EKUs, these certs would not be > trusted in Firefox. The systemic risks from SHA-1 issuance remain, however. > > Gerv Gerv, Given the discussions in the past about risks of SHA-1 issuance for *any* cert type, and the responses from action #1c from the March 2016 CA communication, are there any public plans for dealing type of certificate yet? Do these non-server-certs only fall under the BR's sigAlg policy if a generated certificate collision has an EKU of server auth? (And by that time, is it too late?) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 28/10/16 16:11, Patrick Figel wrote: > I found a number of SHA-1 certificates chaining up to CAs trusted by > Mozilla that have not been brought up on this list or on Bugzilla yet. > Apologies in case I missed prior discussion for any of these, and kudos > to censys for making this search incredibly easy. Thank you for reporting these. Bugs filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert) https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign) https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 28/10/16 16:11, Patrick Figel wrote: > #7 > Some non-TLS-Server-Auth SHA-1 certificates chaining up to "Certum CA" > (Asseco Data Systems S.A.). Most appear to be S/MIME or TLS client auth > certificates, but I don't think the intermediates have any relevant > technical constraints. I'm not sure if they're in scope for BRs/Mozilla, > but here's the list in any case: > https://crt.sh/?id=26427662&opt=cablint > https://crt.sh/?id=32333872&opt=cablint > https://crt.sh/?id=19594797&opt=cablint > https://crt.sh/?id=24979702&opt=cablint The scope of the BRs is debateable. These certs are clearly in scope for Mozilla policy, as they chain up to trusted roots; however Mozilla policy does not (yet) ban SHA-1 issuance other than via the BRs. This may be fixed in policy version 2.3. Without tls-server-auth and with other EKUs, these certs would not be trusted in Firefox. The systemic risks from SHA-1 issuance remain, however. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On Friday, October 28, 2016 at 9:06:44 AM UTC-7, Ben Wilson wrote: > -Original Message- > Subject: RE: New SHA-1 certificates issued in 2016 > > Thank you, Patrick, for pointing these out to us. DigiCert has been in the > forefront pushing the move toward SHA-2. In fact, we've been issuing SHA-2 > certificates by default to our customers for a couple of years now. We've > communicated with these sub-CAs and requested that these certificates be > revoked. We'll follow up with a status report on our efforts sometime next > week. > Sincerely yours, > Ben Wilson > DigiCert VP of Compliance Ben, While it's useful that you've requested these certs been revoked, as has been pointed out during numerous discussions of SHA-1, a revocation does not mitigate the fact that a SHA-1 cert was issued, as an attacker can manipulate the contents in such a way to avoid any revocations. More important to the community would be understanding why these subordinate CAs are not complying with the Baseline Requirements, as required by the Mozilla Root Certificate Program policies, and as required by the Baseline Requirements. As these are not technically constrained sub-CAs, what we have is demonstrable evidence of several possibilities, most seriously: 1) That these CAs may not be adhering to the Baseline Requirements as part of their policies - an indicator that their auditors may be derelict in their professional duties to ensure that the policies and practices are consistent with the BRs 2) If their policies document adherence, as they're required to, then these CAs are not issuing according to their CP/CPS Could you indicate what steps DigiCert is taking to assure members of the public that these subordinate CAs will be operated in a manner consistent with expectations? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: New SHA-1 certificates issued in 2016
Resending without a digital signature. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Ben Wilson Sent: Friday, October 28, 2016 10:01 AM To: Patrick Figel ; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: New SHA-1 certificates issued in 2016 Thank you, Patrick, for pointing these out to us. DigiCert has been in the forefront pushing the move toward SHA-2. In fact, we've been issuing SHA-2 certificates by default to our customers for a couple of years now. We've communicated with these sub-CAs and requested that these certificates be revoked. We'll follow up with a status report on our efforts sometime next week. Sincerely yours, Ben Wilson DigiCert VP of Compliance -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Patrick Figel Sent: Friday, October 28, 2016 9:12 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: New SHA-1 certificates issued in 2016 I found a number of SHA-1 certificates chaining up to CAs trusted by Mozilla that have not been brought up on this list or on Bugzilla yet. Apologies in case I missed prior discussion for any of these, and kudos to censys for making this search incredibly easy. #1 https://crt.sh/?id=32335005&opt=cablint Common Name: portalcsg.siemens.com Serial: 1518050245 Not Before: Jul 12 14:01:45 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - Siemens Issuing CA Class Internet Server 2013 - Siemens Internet CA V1.0 #2 https://crt.sh/?id=32335007&opt=cablint Common Name: downloada.industrysoftware.automation.siemens.com Serial: 2087556804 Not Before: May 10 15:54:05 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - Siemens Issuing CA Class Internet Server 2013 - Siemens Internet CA V1.0 #3 https://crt.sh/?id=32331581&opt=cablint Common Name: VPN-PDC1.vodafone.com Serial: 77:00:1c:7f:f6:f8:7e:5d:d6:48:bf:72:4d:00:01:00:1c:7f:f6 Not Before: Jun 23 09:39:53 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - Vodafone (Corporate Services 2009) - Vodafone (Corporate Domain 2009) #4 https://crt.sh/?id=20279777&opt=cablint Common Name: styles.ag2rlamondiale.fr Serial: 11:21:79:9c:b3:3b:51:dd:43:a5:40:b5:a2:4b:81:38:b8:4a Not Before: May 23 12:02:20 2016 GMT Chains to: "Class 2 Primary CA" (DocuSign (OpenTrust/Keynectis)) via: - CLASS 2 KEYNECTIS CA #5 https://crt.sh/?id=23099350&opt=cablint Common Name: enterprisevault.dnb.no Serial: 7e:c3:58:c6:d5:0a:4a:7f:c6:be:ea:19:f3:f4:98:e5:9d:cd:df:41 Not Before: May 19 13:15:04 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - DnB NOR ASA PKI Class G - Eurida Primary CA #6 Don't know what to make of this one. It's a CA:true SHA-1 certificate. Not sure what the BRs/Mozilla's policies have to say about this: https://crt.sh/?id=2199&opt=cablint Common Name: ACCV-CA3 Serial: 1246797330 Not Before: May 23 10:00:00 2016 GMT Chains to: "Root CA Generalitat Valenciana" (Government of Spain) #7 Some non-TLS-Server-Auth SHA-1 certificates chaining up to "Certum CA" (Asseco Data Systems S.A.). Most appear to be S/MIME or TLS client auth certificates, but I don't think the intermediates have any relevant technical constraints. I'm not sure if they're in scope for BRs/Mozilla, but here's the list in any case: https://crt.sh/?id=26427662&opt=cablint https://crt.sh/?id=32333872&opt=cablint https://crt.sh/?id=19594797&opt=cablint https://crt.sh/?id=24979702&opt=cablint ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: New SHA-1 certificates issued in 2016
Thank you, Patrick, for pointing these out to us. DigiCert has been in the forefront pushing the move toward SHA-2. In fact, we've been issuing SHA-2 certificates by default to our customers for a couple of years now. We've communicated with these sub-CAs and requested that these certificates be revoked. We'll follow up with a status report on our efforts sometime next week. Sincerely yours, Ben Wilson DigiCert VP of Compliance -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Patrick Figel Sent: Friday, October 28, 2016 9:12 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: New SHA-1 certificates issued in 2016 I found a number of SHA-1 certificates chaining up to CAs trusted by Mozilla that have not been brought up on this list or on Bugzilla yet. Apologies in case I missed prior discussion for any of these, and kudos to censys for making this search incredibly easy. #1 https://crt.sh/?id=32335005&opt=cablint Common Name: portalcsg.siemens.com Serial: 1518050245 Not Before: Jul 12 14:01:45 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - Siemens Issuing CA Class Internet Server 2013 - Siemens Internet CA V1.0 #2 https://crt.sh/?id=32335007&opt=cablint Common Name: downloada.industrysoftware.automation.siemens.com Serial: 2087556804 Not Before: May 10 15:54:05 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - Siemens Issuing CA Class Internet Server 2013 - Siemens Internet CA V1.0 #3 https://crt.sh/?id=32331581&opt=cablint Common Name: VPN-PDC1.vodafone.com Serial: 77:00:1c:7f:f6:f8:7e:5d:d6:48:bf:72:4d:00:01:00:1c:7f:f6 Not Before: Jun 23 09:39:53 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - Vodafone (Corporate Services 2009) - Vodafone (Corporate Domain 2009) #4 https://crt.sh/?id=20279777&opt=cablint Common Name: styles.ag2rlamondiale.fr Serial: 11:21:79:9c:b3:3b:51:dd:43:a5:40:b5:a2:4b:81:38:b8:4a Not Before: May 23 12:02:20 2016 GMT Chains to: "Class 2 Primary CA" (DocuSign (OpenTrust/Keynectis)) via: - CLASS 2 KEYNECTIS CA #5 https://crt.sh/?id=23099350&opt=cablint Common Name: enterprisevault.dnb.no Serial: 7e:c3:58:c6:d5:0a:4a:7f:c6:be:ea:19:f3:f4:98:e5:9d:cd:df:41 Not Before: May 19 13:15:04 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - DnB NOR ASA PKI Class G - Eurida Primary CA #6 Don't know what to make of this one. It's a CA:true SHA-1 certificate. Not sure what the BRs/Mozilla's policies have to say about this: https://crt.sh/?id=2199&opt=cablint Common Name: ACCV-CA3 Serial: 1246797330 Not Before: May 23 10:00:00 2016 GMT Chains to: "Root CA Generalitat Valenciana" (Government of Spain) #7 Some non-TLS-Server-Auth SHA-1 certificates chaining up to "Certum CA" (Asseco Data Systems S.A.). Most appear to be S/MIME or TLS client auth certificates, but I don't think the intermediates have any relevant technical constraints. I'm not sure if they're in scope for BRs/Mozilla, but here's the list in any case: https://crt.sh/?id=26427662&opt=cablint https://crt.sh/?id=32333872&opt=cablint https://crt.sh/?id=19594797&opt=cablint https://crt.sh/?id=24979702&opt=cablint ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
New SHA-1 certificates issued in 2016
I found a number of SHA-1 certificates chaining up to CAs trusted by Mozilla that have not been brought up on this list or on Bugzilla yet. Apologies in case I missed prior discussion for any of these, and kudos to censys for making this search incredibly easy. #1 https://crt.sh/?id=32335005&opt=cablint Common Name: portalcsg.siemens.com Serial: 1518050245 Not Before: Jul 12 14:01:45 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - Siemens Issuing CA Class Internet Server 2013 - Siemens Internet CA V1.0 #2 https://crt.sh/?id=32335007&opt=cablint Common Name: downloada.industrysoftware.automation.siemens.com Serial: 2087556804 Not Before: May 10 15:54:05 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - Siemens Issuing CA Class Internet Server 2013 - Siemens Internet CA V1.0 #3 https://crt.sh/?id=32331581&opt=cablint Common Name: VPN-PDC1.vodafone.com Serial: 77:00:1c:7f:f6:f8:7e:5d:d6:48:bf:72:4d:00:01:00:1c:7f:f6 Not Before: Jun 23 09:39:53 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - Vodafone (Corporate Services 2009) - Vodafone (Corporate Domain 2009) #4 https://crt.sh/?id=20279777&opt=cablint Common Name: styles.ag2rlamondiale.fr Serial: 11:21:79:9c:b3:3b:51:dd:43:a5:40:b5:a2:4b:81:38:b8:4a Not Before: May 23 12:02:20 2016 GMT Chains to: "Class 2 Primary CA" (DocuSign (OpenTrust/Keynectis)) via: - CLASS 2 KEYNECTIS CA #5 https://crt.sh/?id=23099350&opt=cablint Common Name: enterprisevault.dnb.no Serial: 7e:c3:58:c6:d5:0a:4a:7f:c6:be:ea:19:f3:f4:98:e5:9d:cd:df:41 Not Before: May 19 13:15:04 2016 GMT Chains to: "Baltimore CyberTrust Root" (DigiCert) via: - DnB NOR ASA PKI Class G - Eurida Primary CA #6 Don't know what to make of this one. It's a CA:true SHA-1 certificate. Not sure what the BRs/Mozilla's policies have to say about this: https://crt.sh/?id=2199&opt=cablint Common Name: ACCV-CA3 Serial: 1246797330 Not Before: May 23 10:00:00 2016 GMT Chains to: "Root CA Generalitat Valenciana" (Government of Spain) #7 Some non-TLS-Server-Auth SHA-1 certificates chaining up to "Certum CA" (Asseco Data Systems S.A.). Most appear to be S/MIME or TLS client auth certificates, but I don't think the intermediates have any relevant technical constraints. I'm not sure if they're in scope for BRs/Mozilla, but here's the list in any case: https://crt.sh/?id=26427662&opt=cablint https://crt.sh/?id=32333872&opt=cablint https://crt.sh/?id=19594797&opt=cablint https://crt.sh/?id=24979702&opt=cablint ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
