CA/WoSign Issues: Difference between revisions

← Older edit

CA/WoSign Issues (view source)

Revision as of 22:06, 30 December 2021

482 bytes removed , 30 December 2021

m

Kathleen Wilson moved page CA:WoSign Issues to CA/WoSign Issues: Moved from CA: to CA/

Kathleen Wilson

Confirmed users, Administrators

5,526

edits

@@ Line 165: / Line 165: @@
 * This misissuance issue did not turn up on WoSign's subsequent [https://cert.webtrust.org/SealFile?seal=2019&file=pdf BR audit].
+Thanks to Stephen Schrauger for reporting this issue.
 ===WoSign Response===
@@ Line 208: / Line 210: @@
 WoSign has issued two pairs of intermediates with the same issuer duplicate serial numbers - [https://crt.sh/?serial=44807b207cf2052e8d3411770266d295&iCAID=1450 one pair] with a notBefore in May 2015, and [https://crt.sh/?serial=3adec402270bf4ee9e892cc65e0ada21&iCAID=1450 one pair] with a notBefore in July 2015. All four certificates were issued by WoSign's "CA 沃通根证书" root. This is a violation of RFC 5280.
-One of each pair has CRL and OCSP URLs with domains such as cr.wscrl.cn, oc.wsocsp.cn and ai.wscrl.cn. These domains no longer exist. The other one of each pair has CRL and OCSP URLs at subdomains of wosign.cn; these subdomains do exist, and point to the Akamai CDN. In the case of one of the pairs, the first cert was logged in the 'pilot' CT log about a month before the second one. One possibility is that WoSign was planning to adopt one strategy for CRL and OCSP hosting, and then changed strategy, which necessitated re-issuing the intermediates with new URLs. If that is the case, it raises the question of why the notBefore date for both certificates is the same.
+One of each pair has CRL and OCSP URLs with domains such as cr.wscrl.cn, oc.wsocsp.cn and ai.wscrl.cn. These domains no longer exist. The other one of each pair has CRL and OCSP URLs at subdomains of wosign.cn; these subdomains do exist, and point to either Akamai's CDN or what appears to be Qihoo 360's CDN. In the case of one of the pairs, the first cert was logged in the 'pilot' CT log about a month before the second one. One possibility is that WoSign was planning to adopt one strategy for CRL and OCSP hosting, and then changed strategy, which necessitated re-issuing the intermediates with new URLs. If that is the case, it raises the question of why the notBefore date for both certificates is the same.
-Given that intermediates are issued manually rather than in an automated fashion, and should normally be surrounded by strong controls, reusing a serial number for two intermediates is disappointing.
 Thanks to Kurt Roeckx and Rob Stradling for their help with this issue.
@@ Line 216: / Line 216: @@
 ===WoSign Response===
-This issue has not yet been formally brought to WoSign's attention.
+By private mail, Richard Wang of WoSign said that the plan was to use a CDN with a different domain, but in discussions with the CDN provider there was no need to change domain, so they changed the plan to use the existing domain and reissued the intermediate certificate. At that point, they "forgot to change the serial number". The old one issued only test certificates for two months. WoSign plan to revoke "this two intermediate CA and all issued certificates soon" (by which I assume he means the two certificates with the older domain names).
 ===Further Comments and Conclusion===
-N/A.
+Given that intermediates are issued manually rather than in an automated fashion, and should normally be surrounded by strong controls as they involve issuance directly from the root, reusing a serial number for two intermediates shows a disappointing lack of care and appropriate processes.
 ==Issue P: Use of SM2 Algorithm (Nov 2015)==
@@ Line 405: / Line 405: @@
 ===WoSign Response===
-This issue has not yet been formally brought to WoSign's attention.
+WoSign's most recent [https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf incident report] acknowledged the issue and they committed to updating the OS on the server(s) in question.
 ===Further Comments and Conclusion===
@@ Line 437: / Line 437: @@
 |Asseco Data Systems S.A.
 |[https://crt.sh/?id=15147905 2020-11-02T01:01:59Z]
-|
+| Revoked as of 2016-11-29, according to Asseco
 |- style="vertical-align:top;"
 |/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign G2
@@ Line 443: / Line 443: @@
 |Asseco Data Systems S.A.
 |[https://crt.sh/?id=10591186 2020-11-02T01:59:59Z]
-|
+| Revoked as of 2016-11-29, according to Asseco
-|- style="vertical-align:top;"
-|/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign
-|<nowiki>/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC</nowiki>
-|Comodo
-|[https://crt.sh/?id=3223853 2019-06-24T19:06:30Z]
-|Rob Stradling of Comodo writes: "This cross-certificate is currently unexpired and unrevoked.  However, the 'UTN - DATACorp SGC' root was [https://bugzilla.mozilla.org/show_bug.cgi?id=1208461 removed from NSS] last year. 'UTN - DATACorp SGC' was also cross-certified by the 'AddTrust External CA Root' root, but we revoked the cross-certificates in December 2015."
-|- style="vertical-align:top;"
-|/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign
-|<nowiki>/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Object</nowiki>
-|Comodo
-|[https://crt.sh/?q=Certification+Authority+of+WoSign&iCAID=1395 2019-07-09T18:40:36Z]
-|Rob Stradling of Comodo writes: "These two cross-certificates are currently unexpired and unrevoked. However, the 'UTN-USERFirst-Object' root is only enabled for the Code Signing trust bit in NSS. There are 2 cross-certs (currently unconstrained and unrevoked) issued by 'AddTrust External CA Root' to 'UTN-USERFirst-Object'. However, the cross-certs issued to WoSign are EKU-constrained to Code Signing/Time Stamping."
 |}