info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Mis-issuance of certificate with https in CN/SAN
496 views
Skip to first unread message
Ben Wilson
Mar 16, 2018, 12:28:53 AM3/16/18
to mozilla-dev-s...@lists.mozilla.org
This mis-issuance incident was reported by Cybertrust Japan (CTJ), an intermediate CA of DigiCert. (https://bugzilla.mozilla.org/show_bug.cgi?id=1445857)
Here's the incident report:
1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
CTJ found a misissued certificate through its regular quality-control checking using cablint on cert.sh.
https://crt.sh/?id=353098570&opt=cablint
2. A timeline of the actions your CA took in response.
A. Mar 12, 2018 13:02:22 (JST) - The certificate was issued
B. Mar 13, 2018 10:38 (JST) - Found the certificate during our daily check on cert.sh
C. Mar 13, 2018 11:00 (JST) - Contacted the customer
D. Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
E. Mar 14, 2018 - patched and tested issuance system
3. Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.
CTJ patched its system to reject the problematic request on Mar 14.
4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
Number of the affected certificate is one (1). CTJ scanned all certificates issued in the past and only found the one reported above.
5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
Please see https://crt.sh/?id=353098570&opt=cablint
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The bug was not previously found by CTJ QA. The affected certificate was issued through an enterprise RA system. CTJ's front-end system rejects incorrect FQDN if request is for additional SAN(s) in certificate. However, this checking function was missed for the CN.
7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
A. CTJ scanned already-issued certificates to see if they contained the incorrect string in the FQDN and to investigate if any additional problematic certificates existed.
B. CTJ patched its system on Mar 14.
Ben Wilson, JD, CISA, CISSP
DigiCert VP Compliance
Here's the incident report:
1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
CTJ found a misissued certificate through its regular quality-control checking using cablint on cert.sh.
https://crt.sh/?id=353098570&opt=cablint
2. A timeline of the actions your CA took in response.
A. Mar 12, 2018 13:02:22 (JST) - The certificate was issued
B. Mar 13, 2018 10:38 (JST) - Found the certificate during our daily check on cert.sh
C. Mar 13, 2018 11:00 (JST) - Contacted the customer
D. Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
E. Mar 14, 2018 - patched and tested issuance system
3. Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.
CTJ patched its system to reject the problematic request on Mar 14.
4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
Number of the affected certificate is one (1). CTJ scanned all certificates issued in the past and only found the one reported above.
5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
Please see https://crt.sh/?id=353098570&opt=cablint
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The bug was not previously found by CTJ QA. The affected certificate was issued through an enterprise RA system. CTJ's front-end system rejects incorrect FQDN if request is for additional SAN(s) in certificate. However, this checking function was missed for the CN.
7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
A. CTJ scanned already-issued certificates to see if they contained the incorrect string in the FQDN and to investigate if any additional problematic certificates existed.
B. CTJ patched its system on Mar 14.
Ben Wilson, JD, CISA, CISSP
DigiCert VP Compliance
Jakob Bohm
Mar 16, 2018, 1:18:36 AM3/16/18
to mozilla-dev-s...@lists.mozilla.org
On 16/03/2018 05:28, Ben Wilson wrote:
> This mis-issuance incident was reported by Cybertrust Japan (CTJ), an intermediate CA of DigiCert. (https://bugzilla.mozilla.org/show_bug.cgi?id=1445857)
>
> Here's the incident report:
>
> 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
>
> CTJ found a misissued certificate through its regular quality-control checking using cablint on cert.sh.
> https://crt.sh/?id=353098570&opt=cablint
>
> 2. A timeline of the actions your CA took in response.
>
> A. Mar 12, 2018 13:02:22 (JST) - The certificate was issued
> B. Mar 13, 2018 10:38 (JST) - Found the certificate during our daily check on cert.sh
> C. Mar 13, 2018 11:00 (JST) - Contacted the customer
> D. Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
> E. Mar 14, 2018 - patched and tested issuance system
>
> 3. Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.
>
> CTJ patched its system to reject the problematic request on Mar 14.
>
> 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
>
> Number of the affected certificate is one (1). CTJ scanned all certificates issued in the past and only found the one reported above.
>
> 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
>
> Please see https://crt.sh/?id=353098570&opt=cablint
>
Note: This is the CT precertificate.
> This mis-issuance incident was reported by Cybertrust Japan (CTJ), an intermediate CA of DigiCert. (https://bugzilla.mozilla.org/show_bug.cgi?id=1445857)
>
> Here's the incident report:
>
> 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
>
> CTJ found a misissued certificate through its regular quality-control checking using cablint on cert.sh.
> https://crt.sh/?id=353098570&opt=cablint
>
> 2. A timeline of the actions your CA took in response.
>
> A. Mar 12, 2018 13:02:22 (JST) - The certificate was issued
> B. Mar 13, 2018 10:38 (JST) - Found the certificate during our daily check on cert.sh
> C. Mar 13, 2018 11:00 (JST) - Contacted the customer
> D. Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
> E. Mar 14, 2018 - patched and tested issuance system
>
> 3. Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.
>
> CTJ patched its system to reject the problematic request on Mar 14.
>
> 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
>
> Number of the affected certificate is one (1). CTJ scanned all certificates issued in the past and only found the one reported above.
>
> 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
>
> Please see https://crt.sh/?id=353098570&opt=cablint
>
Note 2: According to crt.sh, the OCSP response for this precertificate
is not correct. (error message: "OCSP response contains bad number of
certificates").
> 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
>
> The bug was not previously found by CTJ QA. The affected certificate was issued through an enterprise RA system. CTJ's front-end system rejects incorrect FQDN if request is for additional SAN(s) in certificate. However, this checking function was missed for the CN.
>
> 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
>
> A. CTJ scanned already-issued certificates to see if they contained the incorrect string in the FQDN and to investigate if any additional problematic certificates existed.
> B. CTJ patched its system on Mar 14.
>
> Ben Wilson, JD, CISA, CISSP
> DigiCert VP Compliance
>
>
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
Rob Stradling
Mar 16, 2018, 6:28:31 AM3/16/18
to Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote:
<snip>
"is just a bit limited and doesn't have support for more complex
responses" [1].
It's not "incorrect" for an OCSP response to contain superfluous CA
certificates. However, it is suboptimal (in terms of bytes on the wire).
[1] https://github.com/golang/go/issues/21527
--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
<snip>
>> Please see https://crt.sh/?id=353098570&opt=cablint
>>
>
> Note: This is the CT precertificate.
>
> Note 2: According to crt.sh, the OCSP response for this precertificate
> is not correct. (error message: "OCSP response contains bad number of
> certificates").
The crt.sh feature relies on Go's crypto/ocsp library, which currently
>>
>
> Note: This is the CT precertificate.
>
> Note 2: According to crt.sh, the OCSP response for this precertificate
> is not correct. (error message: "OCSP response contains bad number of
> certificates").
"is just a bit limited and doesn't have support for more complex
responses" [1].
It's not "incorrect" for an OCSP response to contain superfluous CA
certificates. However, it is suboptimal (in terms of bytes on the wire).
[1] https://github.com/golang/go/issues/21527
--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
Matt Palmer
Mar 20, 2018, 5:47:04 PM3/20/18
to dev-secur...@lists.mozilla.org
On Fri, Mar 16, 2018 at 04:28:10AM +0000, Ben Wilson via dev-security-policy wrote:
> 7. List of steps your CA is taking to resolve the situation and ensure
> such issuance will not be repeated in the future, accompanied with a
> timeline of when your CA expects to accomplish these things.
>
> A. CTJ scanned already-issued certificates to see if they contained the
> incorrect string in the FQDN and to investigate if any additional
> problematic certificates existed.
>
> B. CTJ patched its system on Mar 14.
This appears to be taking a much narrower definition of the term "such
> 7. List of steps your CA is taking to resolve the situation and ensure
> such issuance will not be repeated in the future, accompanied with a
> timeline of when your CA expects to accomplish these things.
>
> A. CTJ scanned already-issued certificates to see if they contained the
> incorrect string in the FQDN and to investigate if any additional
> problematic certificates existed.
>
> B. CTJ patched its system on Mar 14.
issuance" than is appropriate, IMO. Without more detail as to what the
patch referred to contains, I'm concerned that the applied fix is likely to
be little more than checking names against /^https:/, which whilst it
"fixes" the problem reported, does nothing to prevent
remarkably-similar-but-not-identical misissuance in the future.
Band-aid fixes are not conducive to trustworthiness. Are there plans for
the deployment of more holistic preventative measures, such as integrating
pre-issuance checking via one or more of the established certificate linting
programs, into CTJ's issuance pipeline? If not, why not? If yes, what is
the timeline for such integration, and why was it not mentioned in the list
of steps above?
If the "patch" applied by CTJ was, in fact, to integrate pre-issuance
linting, I would note that more detail around the nature of "patches"
applied to CA systems in response to mis-issuance would prevent
misunderstandings.
- Matt
Ben Wilson
Mar 23, 2018, 11:43:29 AM3/23/18
to Jakob Bohm, Matt Palmer, mozilla-dev-s...@lists.mozilla.org
Matt and Jakob,
Cybertrust Japan asked me to relay the following response to the list.
Jakob, thank you very much for pointing this out. We should have reported this link, https://crt.sh/?id=357203958&opt=cablint
Matt, thank you very much also for asking about our remediation actions we did and will.
The patch we applied to our front end checking system is to fix the bug so that certificate request containing "https://" or "http://" is now rejected.
However, I hope if you could also read bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1445857) about this incident. There, we addressed that CTJ would explore the viability of other pre-issuance mechanisms, things similar to cablint.
So, just like you mentioned, we are integrating pre-issuance checking via the established certificate linting program into our issuance pipeline. It is scheduled to deploy by the end of next week.
Best regards,
Masaru (Mo) Sakamoto
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, March 15, 2018 11:18 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Mis-issuance of certificate with https in CN/SAN
On 16/03/2018 05:28, Ben Wilson wrote:
> IkJYjacpw=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05Anwprg
> FDKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJM
> D8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9
> rVKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0e
> NJ6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfey
> ree9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_
> QfnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D&u=https%3A%2
> F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1445857)
> zo_dn4Ww=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05AnwprgF
> DKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJMD
> 8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9r
> VKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0eN
> J6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfeyr
> ee9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_Q
> fnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D&u=https%3A%2F
> %2Fcrt.sh%2F%3Fid%3D353098570%26opt%3Dcablint
> zo_dn4Ww=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05AnwprgF
> DKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJMD
> 8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9r
> VKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0eN
> J6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfeyr
> ee9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_Q
> fnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D&u=https%3A%2F
> %2Fcrt.sh%2F%3Fid%3D353098570%26opt%3Dcablint
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://clicktime.symantec.com/a/1/mes8IirdwaQvcpvBsm3YAxOrMASaBcE2AjFThU0CHks=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05AnwprgFDKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJMD8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9rVKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0eNJ6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfeyree9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_QfnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D&u=https%3A%2F%2Fwww.wisemo.com
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://clicktime.symantec.com/a/1/rFXj0_HN2tKCyMLkMXsxS95-24GP5wQx5MREsUKOOxI=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05AnwprgFDKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJMD8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9rVKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0eNJ6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfeyree9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_QfnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
Cybertrust Japan asked me to relay the following response to the list.
Jakob, thank you very much for pointing this out. We should have reported this link, https://crt.sh/?id=357203958&opt=cablint
Matt, thank you very much also for asking about our remediation actions we did and will.
The patch we applied to our front end checking system is to fix the bug so that certificate request containing "https://" or "http://" is now rejected.
However, I hope if you could also read bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1445857) about this incident. There, we addressed that CTJ would explore the viability of other pre-issuance mechanisms, things similar to cablint.
So, just like you mentioned, we are integrating pre-issuance checking via the established certificate linting program into our issuance pipeline. It is scheduled to deploy by the end of next week.
Best regards,
Masaru (Mo) Sakamoto
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, March 15, 2018 11:18 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Mis-issuance of certificate with https in CN/SAN
On 16/03/2018 05:28, Ben Wilson wrote:
> This mis-issuance incident was reported by Cybertrust Japan (CTJ), an
> intermediate CA of DigiCert.
> (https://clicktime.symantec.com/a/1/qNaFf1d2FZ7nAtcI4QYFpyVzedhFds4tJj
> intermediate CA of DigiCert.
> IkJYjacpw=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05Anwprg
> FDKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJM
> D8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9
> rVKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0e
> NJ6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfey
> ree9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_
> QfnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D&u=https%3A%2
> F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1445857)
>
> Here's the incident report:
>
> 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
>
> CTJ found a misissued certificate through its regular quality-control checking using cablint on cert.sh.
> https://clicktime.symantec.com/a/1/eUA2Ox-2OmTu2LMJ1-PeQnNKn85x02FRP7y
> Here's the incident report:
>
> 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
>
> CTJ found a misissued certificate through its regular quality-control checking using cablint on cert.sh.
> zo_dn4Ww=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05AnwprgF
> DKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJMD
> 8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9r
> VKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0eN
> J6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfeyr
> ee9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_Q
> fnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D&u=https%3A%2F
> %2Fcrt.sh%2F%3Fid%3D353098570%26opt%3Dcablint
>
> 2. A timeline of the actions your CA took in response.
>
> A. Mar 12, 2018 13:02:22 (JST) - The certificate was issued
> B. Mar 13, 2018 10:38 (JST) - Found the certificate during our daily check on cert.sh
> C. Mar 13, 2018 11:00 (JST) - Contacted the customer
> D. Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
> E. Mar 14, 2018 - patched and tested issuance system
>
> 3. Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.
>
> CTJ patched its system to reject the problematic request on Mar 14.
>
> 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
>
> Number of the affected certificate is one (1). CTJ scanned all certificates issued in the past and only found the one reported above.
>
> 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
>
> Please see
> https://clicktime.symantec.com/a/1/eUA2Ox-2OmTu2LMJ1-PeQnNKn85x02FRP7y
> 2. A timeline of the actions your CA took in response.
>
> A. Mar 12, 2018 13:02:22 (JST) - The certificate was issued
> B. Mar 13, 2018 10:38 (JST) - Found the certificate during our daily check on cert.sh
> C. Mar 13, 2018 11:00 (JST) - Contacted the customer
> D. Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
> E. Mar 14, 2018 - patched and tested issuance system
>
> 3. Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.
>
> CTJ patched its system to reject the problematic request on Mar 14.
>
> 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
>
> Number of the affected certificate is one (1). CTJ scanned all certificates issued in the past and only found the one reported above.
>
> 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
>
> Please see
> zo_dn4Ww=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05AnwprgF
> DKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJMD
> 8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9r
> VKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0eN
> J6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfeyr
> ee9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_Q
> fnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D&u=https%3A%2F
> %2Fcrt.sh%2F%3Fid%3D353098570%26opt%3Dcablint
>
Note: This is the CT precertificate.
Note 2: According to crt.sh, the OCSP response for this precertificate is not correct. (error message: "OCSP response contains bad number of certificates").
Note: This is the CT precertificate.
Note 2: According to crt.sh, the OCSP response for this precertificate is not correct. (error message: "OCSP response contains bad number of certificates").
> 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
>
> The bug was not previously found by CTJ QA. The affected certificate was issued through an enterprise RA system. CTJ's front-end system rejects incorrect FQDN if request is for additional SAN(s) in certificate. However, this checking function was missed for the CN.
>
> 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
>
> A. CTJ scanned already-issued certificates to see if they contained the incorrect string in the FQDN and to investigate if any additional problematic certificates existed.
> B. CTJ patched its system on Mar 14.
>
> Ben Wilson, JD, CISA, CISSP
> DigiCert VP Compliance
>
>
Enjoy
>
> The bug was not previously found by CTJ QA. The affected certificate was issued through an enterprise RA system. CTJ's front-end system rejects incorrect FQDN if request is for additional SAN(s) in certificate. However, this checking function was missed for the CN.
>
> 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
>
> A. CTJ scanned already-issued certificates to see if they contained the incorrect string in the FQDN and to investigate if any additional problematic certificates existed.
> B. CTJ patched its system on Mar 14.
>
> Ben Wilson, JD, CISA, CISSP
> DigiCert VP Compliance
>
>
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://clicktime.symantec.com/a/1/mes8IirdwaQvcpvBsm3YAxOrMASaBcE2AjFThU0CHks=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05AnwprgFDKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJMD8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9rVKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0eNJ6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfeyree9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_QfnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D&u=https%3A%2F%2Fwww.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-secur...@lists.mozilla.org
https://clicktime.symantec.com/a/1/rFXj0_HN2tKCyMLkMXsxS95-24GP5wQx5MREsUKOOxI=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05AnwprgFDKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJMD8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9rVKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0eNJ6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfeyree9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_QfnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
Rob Stradling
May 9, 2018, 10:35:33 AM5/9/18
to mozilla-dev-s...@lists.mozilla.org
On 16/03/18 10:27, Rob Stradling via dev-security-policy wrote:
> On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote:
> <snip>
>>> Please see https://crt.sh/?id=353098570&opt=cablint
>>>
>>
> On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote:
> <snip>
>>> Please see https://crt.sh/?id=353098570&opt=cablint
>>>
>>
>> Note: This is the CT precertificate.
>>
>> Note 2: According to crt.sh, the OCSP response for this precertificate
>> is not correct. (error message: "OCSP response contains bad number of
>> certificates").
>
>>
>> Note 2: According to crt.sh, the OCSP response for this precertificate
>> is not correct. (error message: "OCSP response contains bad number of
>> certificates").
>
> The crt.sh feature relies on Go's crypto/ocsp library, which currently
> "is just a bit limited and doesn't have support for more complex
> responses" [1].
The Go x/crypto/ocsp library was recently updated. I've just deployed
> "is just a bit limited and doesn't have support for more complex
> responses" [1].
the update to crt.sh, and as a result https://crt.sh/ocsp-responders no
longer shows any instances of the "bad number of certificates" error.
0 new messages