Hello ALL
Please find our incident report below.
1. How your CA first became aware of the problem and the time and date.
1) 3 February 2018, 12:06 CET - Certum receives the message from
[email protected] to [email protected].
2. A timeline of the actions CERTUM took in response.
1) 3 February 2018, 12:06 CET - Certum receives the message from
[email protected] to [email protected].
2) 5 February 2018, 15:37 CET and 15:56 CET - Certum informs
subscribers (owners of *.orix.pl and ftp.gavdi.pl domains)
about the obtained problem report.
3) 5 February 2018, 15:37 CET and 15:56 CET - Certum request
subscribers to provide private keys checksums.
4) 5 February 2018, 16:03 CET - Certum informs Hanno Boeck that
received the problem report.
5) 6 February 2018, 16:03 CET - Certum revokes certificates SHA1 -
6E8B5A67417FDBDE2871A28ED7A2C30FEE686390 and SHA1 -
882AE1C8660BB75E3311ACB0CEBCD3C3FF9167E3.
6) 6 February 2018 - Certum scans certificates database. No weak
keys was found.
7) 6 February 2018 - Certum scans certificates database. The
problem with validation against Debian weak key was found.
8) 8 February 2018 - Certum deploys a new version of the weak keys
validation system.
9) 8 February 2018 - Certum Certum scans certificates database.
The problem with validation against Debian weak key was not
found.
3. A summary of the problematic certificates.
The total number of certificates with the problem is 2:
1) https://crt.sh/?id=308392091&opt=ocsp
2) https://crt.sh/?id=6888863&opt=ocsp
4. Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.
The issue was caused by incorrect calculation of the SHA1 fingerprint
of public key.
Public keys hashes stored in Certum's database was calculated from the
Modulo key value with the Modulus prefix and a line ending character while the
value of public key from CSR was calculated and returned without these
additional characters.
So, this is the reason why the calculated fingerprint did not match the
value from Certum's database.
Weak keys verification is tested each time before the new version of
the software is deployed and also periodically as part of the test schedule.
Unfortunately, the database of weak keys that served the tests
contained keys hashes in incorrect formats, the parsed key was also in an
incorrect format. Therefore we could not recognize weak key in its
"original" OpenSSL form. So each test returned false positives.
5. List of steps your CA is taking to resolve the situation and ensure
such issuance will not be repeated in the future
Certum standardized formats of the validated and stored weak keys to be
compliant with the following sources:
https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/tags/0.5-2/blacklists/le64/blacklist-4096.db?view=co
https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/tags/0.5-2/blacklists/le32/blacklist-4096.db?view=co
https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/tags/0.5-2/blacklists/be32/blacklist-4096.db?view=co
https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/be32/blacklist-2048.db?view=co
https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/le32/blacklist-2048.db?view=co
https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/le64/blacklist-2048.db?view=co
https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/be32/blacklist-1024.db?view=co
https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/le32/blacklist-1024.db?view=co
https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/le64/blacklist-1024.db?view=co
--
Arkadiusz Ławniczak
Analyst
Security and Trust Services Division
Asseco Data Systems S.A.
Biuro w Szczecinie
ul. Królowej Korony Polskiej 21
70-486 Szczecin
phone + 48 91 480 12 32
mob. +48 669992104
[email protected]
assecods.pl
Asseco Data Systems S.A. Headquarters: Podolska 21, 81-321 Gdynia/Poland. Tax
Identification Number (NIP): 517-035-94-58. Statistical ID number (REGON):
180853177. National Court Register: 0000421310 District Court in Gdańsk, VIII
Commercial Department of the National Court Register. Share capital: 120 002
940,00 PLN.
This information is intended only for the person or entity to which it is
addressed and may contain confidential and/or privileged material. Unauthorised
use of this information by person or entity other than the intended recipient
is prohibited by law. If you received this by mistake, please immediately
contact the sender by e-mail or by telephone and delete this information from
any computer. Thank you. Asseco Data Systems S.A.
-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+arkadiusz.lawniczak=assecods...@lists.mozilla.org]
On Behalf Of Hanno Böck via dev-security-policy
Sent: Monday, February 5, 2018 5:08 PM
To: [email protected]
Subject: Certificates with 2008 Debian weak key bug
Hi,
I searched crt.sh for valid certificates vulnerable to the 2008 Debian weak key
bug. (Only 2048 bit.)
Overall I found 5 unexpired certificates.
Two certificates by Certum (reported on Saturday, Certum told me "We have taken
necessary steps to clarify this situation as soon as possible", they're not
revoked yet):
https://crt.sh/?id=308392091&opt=ocsp
https://crt.sh/?id=6888863&opt=ocsp
Wosign:
https://crt.sh/?id=30347743
StartCom:
https://crt.sh/?id=54187884
https://crt.sh/?id=307753186
As we all know these are no longer trusted by Mozilla, I reported them
nevertheless. No reply yet.
Old bugs never die, I recommend every CA adds a check for the Debian bug to
their certificate issuance process.
--
Hanno Böck
https://hboeck.de/
mail/jabber: [email protected]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
