Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Incident Certificate signed with SHA1 Violation BR 7.3.1

503 views
Skip to first unread message

corneli...@gmail.com

unread,
Sep 6, 2017, 3:38:32 PM9/6/17
to mozilla-dev-s...@lists.mozilla.org
SwissSign has identified the following incident:
two Certificate signed with SHA1: Violation BR 7.3.1

1)
During an internal audit on 05.09.2017 we found out that there are two certificates issued after 16.01.2015 and signed with a SHA1 hash.
After the discovery of two certificates, the following actions where taken 05.09.2017
a) a security incident was opend
b) contact the customers to revoke the two certificates
c) identify the reason for the error
d) the source of the error has been eliminated

2)
On 06.09.2017 the Icident including a description of the treatment was reported to the community.

3)
By identifying the error, the configuration of the software has been changed in such a way that the issuing of certificates with a SHA1 signature is no longer possible.

4)
The following certificates were concerned:
a) CN=v05dua. pnet. ch/Email=betrie...@post.ch/OU=IT2/O=Post CH AG/L=Bern/ST=BE/C=CH
Certificate Identifier: CEC009CA9554D878F118F9582749B3
SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: E1:96: A4:9D: 05: EE
Issued: 16.01.2015
Revoked: 2017-09-05 15:37:10
b) CN=*. ari-ag. ch/Email=it...@ari-ag.ch/OU=ARI AG/O=ARAR Informatik AG/L=Herisau/ST=AR/C=CH
Certificate Identifier: 743DDD4855841D256DAFBD0448D957A439DEA593D
SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: E1:96: A4:9D: 05: EE
Issued 02/02/2017
Revoked 2017-09-06 08:42:42:42

5)
The following reasons for misissunace have been identified:
a) the correct configuration of the customer account to prevent the issuance of SHA1 certificates was activated delayed.
b) a new functionality was introduced in the CA software in January 2017, which made it possible to reissue the certificate signed with SHA1.

6)
The additional functionality introduced in January 2017 had a weak point.
This vulnerability was only found because of the detailed error analysis performed by finding the certificate that was misissued.
The misissued certificates where detected by the improved quality control. No further measures are currently planned.

7)
The error has been fixed. Configurative measures ensured that no more certificates can be signed using SHA1.

Best Regards Conny Enke

Rob Stradling

unread,
Sep 6, 2017, 3:47:54 PM9/6/17
to dev-secur...@lists.mozilla.org
Hi Conny. Are you able to post those 2 certificates to some CT logs and
provide crt.sh links?

You've said that both certs have the same SHA-1 Fingerprint. Are you
sure about that?
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Nick Lamb

unread,
Sep 6, 2017, 4:38:35 PM9/6/17
to mozilla-dev-s...@lists.mozilla.org
Thanks for writing this incident report.

The latter of the two certificates was issued after popular web browsers had ceased accepting SHA-1 as far as I understand it. As a result it seems likely that it would not have functioned as expected if a customer deployed it on a Web server. You mention that you reached out to the affected customer, did they indicate that they'd noticed any problem with their certificate? Do you have any reason to think that in practice it was not used? (e.g. customer ordered & received a SHA-256 cert for the same name shortly afterwards).

Gervase Markham

unread,
Sep 11, 2017, 6:38:38 AM9/11/17
to corneli...@gmail.com
Hi Connie,

On 06/09/17 20:38, corneli...@gmail.com wrote:
> SwissSign has identified the following incident:
> two Certificate signed with SHA1: Violation BR 7.3.1

Thank you for this report. There have been a couple of reasonable
follow-up questions here in the m.d.s.p. group; could you please answer
them?

> 6)
> The additional functionality introduced in January 2017 had a weak point.
> This vulnerability was only found because of the detailed error analysis performed by finding the certificate that was misissued.
> The misissued certificates where detected by the improved quality control. No further measures are currently planned.

Have automated tests been put in place to make sure the operation of
reissuing a SHA-1 certificate always fails, even after further updates
to the software?

Gerv

corneli...@gmail.com

unread,
Sep 15, 2017, 4:52:31 AM9/15/17
to mozilla-dev-s...@lists.mozilla.org
Hi Gerv,

yes automated test had put in place.
The outcome is monitored.

Best Regards Conny

corneli...@gmail.com

unread,
Sep 15, 2017, 4:54:08 AM9/15/17
to mozilla-dev-s...@lists.mozilla.org
Hi Rob,

no sorry my mistake.

The following certificates were concerned:
a) CN=v05dua. pnet. ch/Email=betrie...@post.ch/OU=IT2/O=Post CH
AG/L=Bern/ST=BE/C=CH
Certificate Identifier: CEC009CA9554D878F118F9582749B3
SHA1 Fingerprint:
75:E4:D8:02:5D:A2:3C:AA:83:73:41:69:06:DB:EE:E7:06:C3:C4:D8
Issued: 16.01.2015
Revoked: 2017-09-05 15:37:10

b) CN=*. ari-ag. ch/Email=it...@ari-ag.ch/OU=ARI AG/O=ARAR Informatik
AG/L=Herisau/ST=AR/C=CH
Certificate Identifier: 743DD4855841D256DAFBD0448D957A439DEA593D
SHA1 Fingerprint:
61:A6:DA:9A:3A:E7:F8:C0:E8:95:AC:26:EB:BD:E1:96:A4:9D:05:EE
Issued 02/02/2017
Revoked 2017-09-06 08:42:42:42


Regarding the publication I have requestet the operation team.

Best Regards Conny

corneli...@gmail.com

unread,
Sep 15, 2017, 4:55:38 AM9/15/17
to mozilla-dev-s...@lists.mozilla.org
Am Mittwoch, 6. September 2017 22:38:35 UTC+2 schrieb Nick Lamb:
> Thanks for writing this incident report.
>
> The latter of the two certificates was issued after popular web browsers had ceased accepting SHA-1 as far as I understand it. As a result it seems likely that it would not have functioned as expected if a customer deployed it on a Web server. You mention that you reached out to the affected customer, did they indicate that they'd noticed any problem with their certificate? Do you have any reason to think that in practice it was not used? (e.g. customer ordered & received a SHA-256 cert for the same name shortly afterwards).


In fact the customers did not use this certificates.

Best Regards Conny

corneli...@gmail.com

unread,
Sep 15, 2017, 8:52:57 AM9/15/17
to mozilla-dev-s...@lists.mozilla.org
to review the certificates:

https://crt.sh/?id=210694152
https://crt.sh/?id=210694153


/Conny

corneli...@gmail.com

unread,
Sep 15, 2017, 8:55:18 AM9/15/17
to mozilla-dev-s...@lists.mozilla.org
Am Montag, 11. September 2017 12:38:38 UTC+2 schrieb Gervase Markham:
Hi Gerv,

technically the CA now is disabled to sign certificates using SHA1

Conny

Gervase Markham

unread,
Sep 15, 2017, 10:25:36 AM9/15/17
to corneli...@gmail.com
On 15/09/17 13:55, corneli...@gmail.com wrote:
> technically the CA now is disabled to sign certificates using SHA1

But presumably you thought that was true before this incident? (And if
not, why not?)

Gerv

Reinhard Dietrich

unread,
Oct 2, 2017, 6:22:16 AM10/2/17
to mozilla-dev-s...@lists.mozilla.org
Sorry, Gerv, for the delay in answer – Conny is currently in holidays.

In fact, an SHA-1 signature for all operations was previously excluded on function level. Unfortunately, after this exclusion, a new "reissuing" function was developed, which was initially only operationally tested with a few customers. SwissSign had so far no reissuing on offer. The reissue was intended for SHA-2 leaf certificates only. But in this case, this reissue was incorrectly applied to an SHA-1 certificate.
Now we have also switched off the reissuing function, but additionally the entire Issuing CA is now configured in a way to prohibit SHA-1 exhibitions. This means the “lock” now operates at level Issuing CA and no longer at the level of a single function.

Reinhard Dietrich
SwissSign

0 new messages