SHA1 certs issued this year chaining to included roots

[Charles Reiss]

Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
which chain to root CAs in Mozilla's program:

- https://crt.sh/?id=12089828 -- chains to Baltimore CyberTrust Root [DigiCert]
via subCA "Eurida Primary CA" via subCA "DnB NOR ASA PKI Class G"

Also, the OCSP responder for this certificate appears to not include a
nextUpdate field.


- https://crt.sh/?id=12090324 -- chains to Security Communication RootCA1
[SECOM] via subCA "YourNet SSL for business"

Also, this certificate is also missing OCSP information and appears to be being
served without OCSP stapling support.

[Kurt Roeckx]

On Tue, Jan 19, 2016 at 01:49:21AM +0000, Charles Reiss wrote:
> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
> which chain to root CAs in Mozilla's program:

I also have some from C=US,O=VeriSign\, Inc.,OU=VeriSign Trust
Network,OU=Terms of use at https://www.verisign.com/rpa
(c)10,CN=VeriSign Class 3 International Server CA - G3". I'm not
sure that CA is still included, but I think it it.

It includes certificates like C=US,ST=California,L=Mountain
View,O=Symantec Corp.,CN=psslnoov.symantec.com

I didn't have time to file bugs for this yet.


Kurt

[Charles Reiss]

https://crt.sh/?id=11876802 would be an example then.

The Class 3 Internal Server CA - G3 appears to have a cert issued from "VeriSign
Class 3 Public Primary Certification Authority - G5", which is an included CA
with the websites trust bit enabled.

[Charles Reiss]

On 01/19/16 03:37, Charles Reiss wrote:
> On 01/19/16 03:23, Kurt Roeckx wrote:
>> On Tue, Jan 19, 2016 at 01:49:21AM +0000, Charles Reiss wrote:
>>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
>>> which chain to root CAs in Mozilla's program:
>>
>> I also have some from C=US,O=VeriSign\, Inc.,OU=VeriSign Trust
>> Network,OU=Terms of use at https://www.verisign.com/rpa
>> (c)10,CN=VeriSign Class 3 International Server CA - G3". I'm not
>> sure that CA is still included, but I think it it.
>>
>> It includes certificates like C=US,ST=California,L=Mountain
>> View,O=Symantec Corp.,CN=psslnoov.symantec.com
>
> https://crt.sh/?id=11876802 would be an example then.

On further investigation, this certificate is revoked, at 4 Jan 2016 17:42 UTC
according to the CRL (and the OCSP server also responds accordingly). (Its
notBefore datetime is 4 Jan 2016 00:00 UTC.)

[Reed Loden]

https://cabforum.org/pipermail/public/2016-January/006519.html has
more information on these certs.

~reed

On Mon, Jan 18, 2016 at 10:23 PM, Kurt Roeckx <ku...@roeckx.be> wrote:
> On Tue, Jan 19, 2016 at 01:49:21AM +0000, Charles Reiss wrote:
>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
>> which chain to root CAs in Mozilla's program:
>
> I also have some from C=US,O=VeriSign\, Inc.,OU=VeriSign Trust
> Network,OU=Terms of use at https://www.verisign.com/rpa
> (c)10,CN=VeriSign Class 3 International Server CA - G3". I'm not
> sure that CA is still included, but I think it it.
>
> It includes certificates like C=US,ST=California,L=Mountain
> View,O=Symantec Corp.,CN=psslnoov.symantec.com
>

> I didn't have time to file bugs for this yet.
>
>
> Kurt
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Eric Mill]

On Mon, Jan 18, 2016 at 10:45 PM, Reed Loden <re...@reedloden.com> wrote:

> https://cabforum.org/pipermail/public/2016-January/006519.html has
> more information on these certs.
>

I don't think that includes the Digicert one, though?

--
konklone.com | @konklone <https://twitter.com/konklone>

[Reed Loden]

Correct. Sorry, I meant to say "on the Symantec-issued certs".

~reed

[Kurt Roeckx]

On Mon, Jan 18, 2016 at 10:45:17PM -0500, Reed Loden wrote:
> https://cabforum.org/pipermail/public/2016-January/006519.html has
> more information on these certs.

Thanks, that seems to list the same 5 I already had.

I'm currently also seeing:
https://crt.sh/?id=12090324


Kurt

[Jakob Bohm]

On 19/01/2016 02:49, Charles Reiss wrote:
> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
> which chain to root CAs in Mozilla's program:
>
> - https://crt.sh/?id=12089828 -- chains to Baltimore CyberTrust Root [DigiCert]
> via subCA "Eurida Primary CA" via subCA "DnB NOR ASA PKI Class G"
>
> Also, the OCSP responder for this certificate appears to not include a
> nextUpdate field.
>

Does the OCSP spec say what "no nextUpdate" should default to? Like
maybe "dontcache, expires instantly".

>
> - https://crt.sh/?id=12090324 -- chains to Security Communication RootCA1
> [SECOM] via subCA "YourNet SSL for business"
>
> Also, this certificate is also missing OCSP information and appears to be being
> served without OCSP stapling support.
>

If there is no OCSP, it obviously cannot be stapled.

In addition to the above, note that *code signing* and *document
signing* certificates may be issued after the deadline for SSL SHA-1
certificates, because some important relying party software cannot be
upgraded to support modern signature hash algorithms (most notably
Microsoft platforms released before 2009).

Such compatibility SHA-1 certificates typically have to chain to
existing roots too (again because of relying party software
limitations).


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

[Charles Reiss]

On 01/19/16 11:49, Jakob Bohm wrote:
> On 19/01/2016 02:49, Charles Reiss wrote:
>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
>> which chain to root CAs in Mozilla's program:
>>
>> - https://crt.sh/?id=12089828 -- chains to Baltimore CyberTrust Root [DigiCert]
>> via subCA "Eurida Primary CA" via subCA "DnB NOR ASA PKI Class G"
>>
>> Also, the OCSP responder for this certificate appears to not include a
>> nextUpdate field.
>>
>
> Does the OCSP spec say what "no nextUpdate" should default to? Like maybe
> "dontcache, expires instantly".
>
>>
>> - https://crt.sh/?id=12090324 -- chains to Security Communication RootCA1
>> [SECOM] via subCA "YourNet SSL for business"
>>
>> Also, this certificate is also missing OCSP information and appears to be being
>> served without OCSP stapling support.
>>
>
> If there is no OCSP, it obviously cannot be stapled.

The CA/Browser forum BRs contemplate OCSP stapling without an OCSP responder
being listed in the certificate in section 7.1.2.2.c ("The HTTP URL of the
Issuing CA’s OCSP responder MAY be omitted, provided that the Subscriber
“staples” the OCSP response for the Certificate in its TLS handshakes
[RFC4366].") I assume the idea is that the OCSP responder URL would be manually
configured in the server and that this would make the certificate slightly smaller.

> In addition to the above, note that *code signing* and *document
> signing* certificates may be issued after the deadline for SSL SHA-1
> certificates, because some important relying party software cannot be
> upgraded to support modern signature hash algorithms (most notably
> Microsoft platforms released before 2009).
>
> Such compatibility SHA-1 certificates typically have to chain to
> existing roots too (again because of relying party software
> limitations).

I would hope such issuance is occurring under technically constrained subCAs so
that a Flame-style chosen-prefix collision attack cannot result in a rogue
certificate that Mozilla would trust for TLS servers so long as Mozilla does not
disable SHA-1 certificates entirely.

>
>
> Enjoy
>
> Jakob

[Rob Stradling]

On 19/01/16 21:13, Charles Reiss wrote:
> On 01/19/16 11:49, Jakob Bohm wrote:

<snip>

>> If there is no OCSP, it obviously cannot be stapled.
>

> The CA/Browser forum BRs contemplate OCSP stapling without an OCSP responder
> being listed in the certificate in section 7.1.2.2.c ("The HTTP URL of the
> Issuing CA’s OCSP responder MAY be omitted, provided that the Subscriber
> “staples” the OCSP response for the Certificate in its TLS handshakes
> [RFC4366].") I assume the idea is that the OCSP responder URL would be manually
> configured in the server and that this would make the certificate slightly smaller.

IIRC, the original motivation for this text was to make it possible to
suppress OCSP requests directly from TLS clients (that don't support
OCSP Stapling). In particular, there was a concern that some OCSP
responders might not be able to cope with the OCSP traffic generated by
certs used by sites with extremely high numbers of users.

At the time, Firefox didn't support OCSP Stapling, and it was much less
common for CAs to use CDNs for their OCSP responders. (Indeed, some CAs
didn't even support OCSP back then).

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Charles Reiss]

I also found this recent SHA-1 cert that appears to chain to "IGC/A"
(Government of France) -- https://crt.sh/?id=12129393

In addition to being a SHA-1 certificate issued this year:
- the OCSP responder for this certificate does not seem to respond to
GET requests;
- the signing certificate used by the OCSP responder appears to be
signed by a different subCA (https://crt.sh/?id=115 instead of
https://crt.sh/?id=11159611) than the one that issued this certificate;
- the signing certificate used by the OCSP responder does not include
the id-pkix-ocsp-nocheck extension;
- the OCSP response does not include a nextUpdate field; and
- the CRL referenced by the subCA certificate
(https://crt.sh/?id=11159611) has a nextUpdate 18 months after its last
update date. (The BRs require at most 12 months.)

[Charles Reiss]

On 01/19/16 01:49, Charles Reiss wrote:

> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
> which chain to root CAs in Mozilla's program:

[snip]

And here are a couple more, from different subCAs:

- https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA 2
[T-Systems] via subCA "Shared Business CA 3"


- https://crt.sh/?id=12203339 -- chaining to Baltimore CyberTrust Root
(again) this time via (presumably external) subCA "Postecom CS3"

Also, the OCSP responder for this certificate appears to use an OCSP
responder certificate for some subCA with CN=Postecom CA3 (instead of CS3).

Even SHA-256 certificates from this subCA (e.g.
https://crt.sh/?id=12138276) appear to have an Authority Key Identifier
extension that specifies the serial number of the subCA cert instead of
the keyid:

X509v3 Authority Key Identifier:
DirName:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
serial:07:27:52:62

Does this mean they couldn't be used with a SHA-256 version of the subCA
certificate?

[Ben Wilson]

Thanks for spotting this Charles. We've reached out to Postecom.it for an explanation and with a request that they revoke the certificate immediately and reissue it with the proper contents.
Ben Wilson
DigiCert VP of Compliance

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On Behalf Of Charles Reiss
Sent: Monday, January 25, 2016 1:23 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: SHA1 certs issued this year chaining to included roots

On 01/19/16 01:49, Charles Reiss wrote:

> Via censys.io, I found a couple SHA-1 certs with notBefore dates from
> this year which chain to root CAs in Mozilla's program:

[snip]

And here are a couple more, from different subCAs:

- https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA 2 [T-Systems] via subCA "Shared Business CA 3"


- https://crt.sh/?id=12203339 -- chaining to Baltimore CyberTrust Root
(again) this time via (presumably external) subCA "Postecom CS3"

Also, the OCSP responder for this certificate appears to use an OCSP responder certificate for some subCA with CN=Postecom CA3 (instead of CS3).

Even SHA-256 certificates from this subCA (e.g.
https://crt.sh/?id=12138276) appear to have an Authority Key Identifier extension that specifies the serial number of the subCA cert instead of the keyid:

X509v3 Authority Key Identifier:
DirName:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
serial:07:27:52:62

Does this mean they couldn't be used with a SHA-256 version of the subCA certificate?

[Andrew Ayer]

On Mon, 25 Jan 2016 08:22:57 +0000
Charles Reiss <wogg...@gmail.com> wrote:

> - https://crt.sh/?id=12203339 -- chaining to Baltimore CyberTrust Root
> (again) this time via (presumably external) subCA "Postecom CS3"

This certificate also contains two SANs for internal names:

DNS:vm-exfe01.postecom.local
DNS:vm-exfe02.postecom.local

-- Andrew

[Ben Wilson]

The SHA1 certificate issued by Postecom.it with serial number 35:6c:f3:ee:ae:90:77:cd:11:aa:11:ec:1d:62:fd:e5:16:b7:ef:09 has been revoked.
Here is the corresponding CRL:
http://postecert.poste.it/postecomcs3/crl.crl
Ben

-----Original Message-----
From: Marco Bongiovanni [mailto:marco.bo...@postecom.it]
Sent: Tuesday, January 26, 2016 6:05 AM

we communicate that we have revoked the certificate referred to
https://crt.sh/?id=

-----Original Message-----
From: Ben Wilson
Sent: Monday, January 25, 2016 10:08 AM
To: 'Charles Reiss' <wogg...@gmail.com>; mozilla-dev-s...@lists.mozilla.org
Subject: RE: SHA1 certs issued this year chaining to included roots

Thanks for spotting this Charles. We've reached out to Postecom.it for an explanation and with a request that they revoke the certificate immediately and reissue it with the proper contents.
Ben Wilson
DigiCert VP of Compliance

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On Behalf Of Charles Reiss
Sent: Monday, January 25, 2016 1:23 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: SHA1 certs issued this year chaining to included roots

On 01/19/16 01:49, Charles Reiss wrote:

> Via censys.io, I found a couple SHA-1 certs with notBefore dates from
> this year which chain to root CAs in Mozilla's program:

[snip]

And here are a couple more, from different subCAs:

- https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA 2 [T-Systems] via subCA "Shared Business CA 3"

- https://crt.sh/?id=12203339 -- chaining to Baltimore CyberTrust Root
(again) this time via (presumably external) subCA "Postecom CS3"

[Kathleen Wilson]

On 1/25/16 12:22 AM, Charles Reiss wrote:
> On 01/19/16 01:49, Charles Reiss wrote:
>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
>> which chain to root CAs in Mozilla's program:
> [snip]
>
> And here are a couple more, from different subCAs:
>
> - https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA 2
> [T-Systems] via subCA "Shared Business CA 3"
>

I received email from Bernd of T-Systems saying that from 1 January
2016, 8 SHA‐1 subscriber certificates (SSL) were issued via sub-CA
"Shared Business CA 3" (chaining to “Deutsche Telekom Root CA 2”) –
because of converging use cases. Other T-Systems CAs were not affected.
The problem has been fixed, so SHA-1 certs can no longer be issued.
The 8 certs will be revoked on February 5 and the corresponding CRL will
be updated/published.

Thanks,
Kathleen

[Richard Barnes]

On Fri, Jan 29, 2016 at 4:43 PM, Kathleen Wilson <kwi...@mozilla.com>
wrote:

> On 1/25/16 12:22 AM, Charles Reiss wrote:
>

>> On 01/19/16 01:49, Charles Reiss wrote:
>>
>>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from
>>> this year
>>> which chain to root CAs in Mozilla's program:
>>>
>> [snip]
>>
>> And here are a couple more, from different subCAs:
>>
>> - https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA 2
>> [T-Systems] via subCA "Shared Business CA 3"
>>
>>
>

> I received email from Bernd of T-Systems saying that from 1 January 2016,
> 8 SHA‐1 subscriber certificates (SSL) were issued via sub-CA "Shared
> Business CA 3" (chaining to “Deutsche Telekom Root CA 2”) – because of
> converging use cases. Other T-Systems CAs were not affected.
> The problem has been fixed, so SHA-1 certs can no longer be issued.
> The 8 certs will be revoked on February 5 and the corresponding CRL will
> be updated/published.
>

February 5th? Allow me to quote the BRs:

"""
4.9.1.1 Reasons for Revoking a Subscriber Certificate

The CA SHALL revoke a Certificate within 24 hours if one or more of the
following occurs: ...

The CA is made aware that the Certificate was not issued in accordance with
these Requirements
"""



>
> Thanks,
> Kathleen

[Charles Reiss]

On 01/26/16 20:33, Ben Wilson wrote:
> The SHA1 certificate issued by Postecom.it with serial number 35:6c:f3:ee:ae:90:77:cd:11:aa:11:ec:1d:62:fd:e5:16:b7:ef:09 has been revoked.
> Here is the corresponding CRL:
> http://postecert.poste.it/postecomcs3/crl.crl

How about this one? https://crt.sh/?id=12501194&opt=cablint

Has/Will PosteCom scanned their logs for other misissued certificates?

[Charles Reiss]

On 01/19/16 01:49, Charles Reiss wrote:

> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
> which chain to root CAs in Mozilla's program:

[snip]

and even more, from different subCAs than have come up yet:

- https://crt.sh/?id=12501241&opt=cablint -- Baltimore CyberTrust Root
[DigiCert] via Verizon Public SureServer CA G14-SHA1

- https://crt.sh/?id=12309564&opt=cablint -- Baltimore CyberTrust Root
[DigiCert] via TI Trust Technologies Global CA

- https://crt.sh/?id=12501254&opt=cablint -- RSA Security 2048 V3 via
RSA Corporate CA v2 via RSA Corporate Server CA v2

[Bernd.N...@t-systems.com]

Hello Kathleen,

we revoked all SHA-1 certificates issued this year:

00a5401e9bafb23523 (Tuesday, February 2, 2016, 11:35:53)
009d79636c84ece62a (‎Tuesday, February 2, 2016, 11:37:25)
008e6c17cd66006c11 (Tuesday, February 2, 2016, 11:38:45)
2318da5c1485012e (Friday, January 29, 2016, 12:37:36)

6dfb9ccc0c5333c6 (‎Friday, January 29, 2016, 15:10:30)

7d5e244530e38c13 (‎Friday, January 29, 2016, 13:54:00)
00bdcda1e1e9b358e8 (Friday, January 29, 2016, 13:55:09)
008ab83981f725ff48 (Friday, January 29, 2016, 13:57:51)

The corresponding CRL:
http://crl.sbca.telesec.de/rl/Shared_Business_CA_3.crl

Best regards,

Bernd

T-Systems International GmbH
Trust Center Applications



-----Ursprüngliche Nachricht-----
Von: dev-security-policy [mailto:dev-security-policy-bounces+bernd.nakonzer=t-syst...@lists.mozilla.org] Im Auftrag von Kathleen Wilson
Gesendet: Freitag, 29. Januar 2016 22:44
An: mozilla-dev-s...@lists.mozilla.org
Betreff: Re: SHA1 certs issued this year chaining to included roots

On 1/25/16 12:22 AM, Charles Reiss wrote:

> On 01/19/16 01:49, Charles Reiss wrote:
>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from
>> this year which chain to root CAs in Mozilla's program:
> [snip]
>
> And here are a couple more, from different subCAs:
>
> - https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA
> 2 [T-Systems] via subCA "Shared Business CA 3"
>

I received email from Bernd of T-Systems saying that from 1 January 2016, 8 SHA‐1 subscriber certificates (SSL) were issued via sub-CA "Shared Business CA 3" (chaining to “Deutsche Telekom Root CA 2”) – because of converging use cases. Other T-Systems CAs were not affected.
The problem has been fixed, so SHA-1 certs can no longer be issued.
The 8 certs will be revoked on February 5 and the corresponding CRL will be updated/published.

Thanks,
Kathleen

[Richard Barnes]

Hi Bernd,

Could you comment on what steps you are taking to prevent further
violations of this type?

Thanks,
--Richard

Sent from my iPhone. Please excuse brevity.

> On Feb 2, 2016, at 09:07, "Bernd.N...@t-systems.com" <Bernd.N...@t-systems.com> wrote:
>
> Hello Kathleen,
>
> we revoked all SHA-1 certificates issued this year:
>
> 00a5401e9bafb23523 (Tuesday, February 2, 2016, 11:35:53)
> 009d79636c84ece62a (‎Tuesday, February 2, 2016, 11:37:25)
> 008e6c17cd66006c11 (Tuesday, February 2, 2016, 11:38:45)
> 2318da5c1485012e (Friday, January 29, 2016, 12:37:36)
>
> 6dfb9ccc0c5333c6 (‎Friday, January 29, 2016, 15:10:30)
>
> 7d5e244530e38c13 (‎Friday, January 29, 2016, 13:54:00)
> 00bdcda1e1e9b358e8 (Friday, January 29, 2016, 13:55:09)
> 008ab83981f725ff48 (Friday, January 29, 2016, 13:57:51)
>
> The corresponding CRL:
> http://crl.sbca.telesec.de/rl/Shared_Business_CA_3.crl
>
> Best regards,
>
> Bernd
>
> T-Systems International GmbH
> Trust Center Applications
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy [mailto:dev-security-policy-bounces+bernd.nakonzer=t-syst...@lists.mozilla.org] Im Auftrag von Kathleen Wilson
> Gesendet: Freitag, 29. Januar 2016 22:44
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: Re: SHA1 certs issued this year chaining to included roots
>
>> On 1/25/16 12:22 AM, Charles Reiss wrote:

>>> On 01/19/16 01:49, Charles Reiss wrote:
>>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from
>>> this year which chain to root CAs in Mozilla's program:
>> [snip]
>>
>> And here are a couple more, from different subCAs:
>>
>> - https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA
>> 2 [T-Systems] via subCA "Shared Business CA 3"
>
>

[Bernd.N...@t-systems.com]

Hello Richard,

only a small business unit was affected by this problem. We fixed a bug in the software configuration. SHA-1 certs can no longer be issued.

Best regards,
Bernd

-----Ursprüngliche Nachricht-----
Von: dev-security-policy [mailto:dev-security-policy-bounces+bernd.nakonzer=t-syst...@lists.mozilla.org] Im Auftrag von Richard Barnes
Gesendet: Dienstag, 2. Februar 2016 15:46
An: Nakonzer-Lotz, Bernd
Cc: mozilla-dev-s...@lists.mozilla.org; kwi...@mozilla.com
Betreff: Re: AW: SHA1 certs issued this year chaining to included roots

Hi Bernd,

Could you comment on what steps you are taking to prevent further violations of this type?

Thanks,
--Richard

Sent from my iPhone. Please excuse brevity.

> On Feb 2, 2016, at 09:07, "Bernd.N...@t-systems.com" <Bernd.N...@t-systems.com> wrote:
>
> Hello Kathleen,
>
> we revoked all SHA-1 certificates issued this year:
>
> 00a5401e9bafb23523 (Tuesday, February 2, 2016, 11:35:53)
> 009d79636c84ece62a (‎Tuesday, February 2, 2016, 11:37:25)
> 008e6c17cd66006c11 (Tuesday, February 2, 2016, 11:38:45)
> 2318da5c1485012e (Friday, January 29, 2016, 12:37:36)
>
> 6dfb9ccc0c5333c6 (‎Friday, January 29, 2016, 15:10:30)
>
> 7d5e244530e38c13 (‎Friday, January 29, 2016, 13:54:00)
> 00bdcda1e1e9b358e8 (Friday, January 29, 2016, 13:55:09)
> 008ab83981f725ff48 (Friday, January 29, 2016, 13:57:51)
>
> The corresponding CRL:
> http://crl.sbca.telesec.de/rl/Shared_Business_CA_3.crl
>
> Best regards,
>
> Bernd
>
> T-Systems International GmbH
> Trust Center Applications
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy

> [mailto:dev-security-policy-bounces+bernd.nakonzer=t-systems.com@lists

> .mozilla.org] Im Auftrag von Kathleen Wilson
> Gesendet: Freitag, 29. Januar 2016 22:44
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: Re: SHA1 certs issued this year chaining to included roots
>
>> On 1/25/16 12:22 AM, Charles Reiss wrote:

>>> On 01/19/16 01:49, Charles Reiss wrote:
>>> Via censys.io, I found a couple SHA-1 certs with notBefore dates
>>> from this year which chain to root CAs in Mozilla's program:
>> [snip]
>>
>> And here are a couple more, from different subCAs:
>>
>> - https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA
>> 2 [T-Systems] via subCA "Shared Business CA 3"
>
>

[dave....@gmail.com]

Hello-

Regarding:

> - https://crt.sh/?id=12501254&opt=cablint -- RSA Security 2048 V3 via
> RSA Corporate CA v2 via RSA Corporate Server CA v2

All certificates issued with SHA-1 post 1 January 2016 have been revoked and replaced with SHA-2 compliant Certificates as of 4 Feb 2016.
The configuration of the CA was amended to only issue SHA-2 certificates going forward.
The issuing CA was a deprecated CA that was effectively retired in Q1 of 2015. As a result, it was not included in our SHA-2 conversion efforts.
Due to a fielded application that had embedded explicit trust only to this CA, when the certificates came up for renewal, they were issued in error. As soon as the error was brought to our attention, the certificates were revoked and replaced with SHA-2 certificates.