MozillaWiki

CA/WoSign Issues: Difference between revisions

Page Discussion

CA/WoSign Issues (view source)

Revision as of 22:06, 30 December 2021

9,451 bytes added ,  30 December 2021
m
Kathleen Wilson moved page CA:WoSign Issues to CA/WoSign Issues: Moved from CA: to CA/
m (typo)
m (Kathleen Wilson moved page CA:WoSign Issues to CA/WoSign Issues: Moved from CA: to CA/)
 
(17 intermediate revisions by one other user not shown)
Line 29: Line 29:
</i></blockquote>
</i></blockquote>


===Further Comments===
This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report].
 
===Further Comments and Conclusion===
 
WoSign say that they were aware that they were doing this, and that the cause was a delay in implementing the changes from CAB Forum ballot 118. Ballot 118 was passed on 16th October 2014, but WoSign were unable to update their systems until March 5th 2015, nearly five months later. This seems like a surprisingly long delay for a relatively simple change, given how quickly WoSign have been able to update their systems in other cases.


The fact that WoSign declared this on their audit strongly suggests that WoSign were unaware that they were issuing certificates against a SHOULD NOT (i.e. this was not done after carefully weighing and understanding the full implications) and decided to correct the situation when informed. If they had been doing this in full knowledge of the consequences, and the extension into 2017 was intentional, they would not have agreed to revoke all the certificates before 31st December 2016. So while this is not a BR violation, it speaks to their control over their issuance process.
However, as noted above, this is not a BR violation.


==Issue F: Certs Identical Except For NotBefore (Mar 2015)==
==Issue F: Certs Identical Except For NotBefore (Mar 2015)==
Line 42: Line 46:
===WoSign Response===
===WoSign Response===


This issue has been raised with WoSign, and we await their response.
This issue is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. They explain that there are 16 examples, and it happens when their Certificate Management System loses contact with a signing server during a transaction, and so tries the other one, but both signing servers issue a certificate. One was sent to the subscriber, and the other was stored in their records, and then logged to CT when they logged all their certs.
 
WoSign has since updated their system to use better locking.
 
===Further Comments and Conclusion===
 
Issuing two different certs with the same serial number is a violation of the RFC, but the impact of this bug is minimal.


==Issue H: Duplicate Serial Numbers (Apr 2015)==
==Issue H: Duplicate Serial Numbers (Apr 2015)==
Line 58: Line 68:
</i></blockquote>
</i></blockquote>


===Further Comments===
This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. They explain that there were two bugs which led to the same result - one involving a system which did not understand serial numbers with leading zeroes, and the other a race condition.
 
===Further Comments and Conclusion===


This last auditor statement ("follow up action was also conducted to prevent the recurrence of the incident") is relevant given later issues involving duplicate serial numbers.
This last auditor statement ("follow up action was also conducted to prevent the recurrence of the incident") is relevant given later issues involving duplicate serial numbers.
It's not clear how "a system bug with the serial number generation, generating a serial number starting with “0” in the first left position" combined with "the signing system had a bug that didn’t know how to deal with this kind of serial number" could lead to duplicate serial numbers. Further clarification has been requested on this point.
This incident is unfortunate and an RFC violation, but it was detected fairly promptly (albeit not by WoSign themselves) and fixed.


==Issue J: Various BR Violations (Apr 2015)==
==Issue J: Various BR Violations (Apr 2015)==
Line 80: Line 96:
WoSign resolved this promptly at the time by a mix of changes to practice and changes to [https://www.wosign.com/policy/wosign-policy-1-2-11.pdf their CPS] (new versions 1.2.10 and 1.2.11).
WoSign resolved this promptly at the time by a mix of changes to practice and changes to [https://www.wosign.com/policy/wosign-policy-1-2-11.pdf their CPS] (new versions 1.2.10 and 1.2.11).


This issue was included in Google's report to Mozilla in August 2016 but not listed in the original public discussion. It has come up in the ensuing discussion in m.d.s.policy but no additional formal response has been made. It is possible that WoSign's upcoming report will cover this.
This issue was included in Google's report to Mozilla in August 2016 but not listed in the original public discussion. This issue is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report].


===Further Comments===
===Further Comments and Conclusion===


WoSign acted quickly to resolve the issues, but this issue perhaps demonstrates that their CPS was not a definition of their practice, but more a document to be updated post-hoc to match changes made to their operations.
WoSign acted quickly to resolve the issues, but this issue perhaps demonstrates that their CPS was not a definition of their practice, but more a document to be updated post-hoc to match changes made to their operations.
Line 93: Line 109:


As Mozilla was not aware of this issue at the time, we were unable to make a judgement on whether these issues rose to an appropriate level of severity to require this response.
As Mozilla was not aware of this issue at the time, we were unable to make a judgement on whether these issues rose to an appropriate level of severity to require this response.
There is also the question of whether Mozilla wishes to continue to accept audits from an auditor who misses CPS violations covering such a large proportion of the certificate corpus.


==Issue L: Any Port (Jan - Apr 2015)==
==Issue L: Any Port (Jan - Apr 2015)==
Line 118: Line 136:
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official issue report].
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official issue report].


===Further Comments===
This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report].
 
===Further Comments and Conclusion===


It is the responsibility of the CA to disclose issues to its auditors, not for the auditor to discover them. WoSign was aware of this, because some of the issues in this document were disclosed to auditors and included in their report.
It is the responsibility of the CA to disclose issues to its auditors, not for the auditor to discover them. WoSign was aware of this, because some of the issues in this document were disclosed to auditors and included in their report.


The completeness of WoSign's list of 72 certificates was called into question by a discussion participant who testified that [https://crt.sh/?id=30335331 his certificate] was validated using port 8080 but does not appear in WoSign's list. In response, Richard [https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/LVnZBHOGDgAJ said] that in fact their system did not directly record the port used for validation, and so he could not guarantee that the list was complete.
The completeness of WoSign's list of 72 certificates was called into question by a discussion participant who testified that [https://crt.sh/?id=30335331 his certificate] was validated using port 8080 but does not appear in WoSign's list. In response, Richard [https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/LVnZBHOGDgAJ said] that in fact their system did not directly record the port used for validation, and so he could not guarantee that the list was complete. However, the final incident report still gives the impression that WoSign was able to generate a complete list.
 
WoSign has since stopped doing website validation; if they had continued, better logging of the process would have been necessary. The logs they were keeping while using this process were clearly inadequate.


==Issue N: Additional Domain Errors (June 2015)==
==Issue N: Additional Domain Errors (June 2015)==
Line 143: Line 165:


* This misissuance issue did not turn up on WoSign's subsequent [https://cert.webtrust.org/SealFile?seal=2019&file=pdf BR audit].
* 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===
===WoSign Response===
Line 151: Line 175:


2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official issue report]. The report explains the two bugs, N1 and N2.  WoSign classifies the misissuances as 21 N1 and 12 N2.
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official issue report]. The report explains the two bugs, N1 and N2.  WoSign classifies the misissuances as 21 N1 and 12 N2.
This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report].


====Bug N1====
====Bug N1====
Line 166: Line 192:
Looking at their list of misissued domains in the report, this really does mean "any domain". For example, a cert where the owner validated "netwi.ru" was able to add "mx.idisk.su", an entirely different domain, without validating it. This effectively bypasses domain validation for any attacker who owns a domain of their own.
Looking at their list of misissued domains in the report, this really does mean "any domain". For example, a cert where the owner validated "netwi.ru" was able to add "mx.idisk.su", an entirely different domain, without validating it. This effectively bypasses domain validation for any attacker who owns a domain of their own.


===Further Comments===
===Further Comments and Conclusion===


* An arbitrary unvalidated ownership domain misissuance bug is an extremely serious flaw. It is not clear whether it was possible to do this in the standard workflow or if it required hacking form parameters. Given the number of misissued certs, the former seems more likely.
* An arbitrary unvalidated ownership domain misissuance bug is an extremely serious flaw, particularly if it's available in a normal workflow.


* The report seems to suggest an "issue first, ask questions later" approach whereby a cert is issued to the subscriber even if it is flagged as questionable, and the remediation mechanism is revocation rather than lack of issuance. Furthermore, their validation team works 9-5, so an applicant could have many hours to abuse a misissued certificate before it was discovered.
* The report seems to suggest an "issue first, ask questions later" approach whereby a cert is issued to the subscriber even if it is flagged as questionable, and the remediation mechanism is revocation rather than lack of issuance. Furthermore, their validation team works 9-5, so an applicant could have many hours to abuse a misissued certificate before it was discovered.
Line 177: Line 203:


* The certificate involved here were all clearly misissued; even if the person could have proved control of the parent domain, they did not do so during the process. Therefore, failure to revoke these certificates immediately (as WoSign argued it didn't need to during the public discussion) constitutes a further BR violation, as per Section 4.9.1.1 of the [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.8.pdf BRs], in particular, item 4 and item 9.
* The certificate involved here were all clearly misissued; even if the person could have proved control of the parent domain, they did not do so during the process. Therefore, failure to revoke these certificates immediately (as WoSign argued it didn't need to during the public discussion) constitutes a further BR violation, as per Section 4.9.1.1 of the [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.8.pdf BRs], in particular, item 4 and item 9.
WoSign has since stopped doing website control validation entirely. However, that does not decrease the seriousness of the bug/feature. It also raises the question of how such a feature could make it through review, testing and QA.
==Issue O: Intermediates with Duplicate Serial Numbers (May - July 2015)==
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 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.
Thanks to Kurt Roeckx and Rob Stradling for their help with this issue.
===WoSign Response===
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===
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)==
==Issue P: Use of SM2 Algorithm (Nov 2015)==
Line 193: Line 237:
Richard Wang: "This is another case that we will include it in our report. We issued two test cert using SM2 algorithm that used the same serial number as the RSA cert (same subject) to test if we can setup a gateway that install this two type cert, it can shake hand automatically using different cert based on the browser algorithm support." (Unable to find this message in the groups.google.com archive.)
Richard Wang: "This is another case that we will include it in our report. We issued two test cert using SM2 algorithm that used the same serial number as the RSA cert (same subject) to test if we can setup a gateway that install this two type cert, it can shake hand automatically using different cert based on the browser algorithm support." (Unable to find this message in the groups.google.com archive.)


===Further Comments===
This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. Their later [https://www.wosign.com/report/WoSign_final_statement_09232016.pdf final statement] document says: "being a Chinese licensed CA, we must abide by local laws and regulations, we must actively cooperate with domestic browsers to test the SSL certificate using SM2 algorithm issued by a
global trusted root in the real Internet, not intranet."
 
===Further Comments and Conclusion===
 
There are plenty of ways of testing this scenario without using public roots - and, in fact, WoSign has said they have updated their systems to avoid issuing test certificates from public roots in future. Mozilla is sceptical of the claim that Chinese law or regulation required WoSign to issue these certificates. However, if that were true, the Baseline Requirements contain a mechanism (section 9.16.3) by which a CA can break the BRs if required to do so by local law, with appropriate disclosure to the CAB Forum. That was not done in this case.


There are plenty of ways of testing this scenario without using public roots. Symantec was penalised for issuing non-BR-compliant test certificates in their publicly-trusted certificate hierarchies.
We note that Symantec was penalised in late 2015 for issuing non-BR-compliant test certificates in their publicly-trusted certificate hierarchies. Their problems were first revealed in September, and one big discussion of these problems happened in m.d.s.policy starting on 13th October 2015. All of these dates are prior to WoSign's test certificate misissuances.


==Issue R: Purchase of StartCom (Nov 2015)==
==Issue R: Purchase of StartCom (Nov 2015)==
Line 205: Line 254:
===WoSign Response===
===WoSign Response===


We have not yet had an official response from WoSign or StartCom about this issue.
Richard Wang [https://groups.google.com/d/msg/mozilla.dev.security.policy/0pqpLJ_lCJQ/7lyHB15LDwAJ writes]: "An announcement and disclosure will be made shortly pending completion of the business transaction. We can provide the proof documents to Mozilla to show this transaction is not finished if Mozilla think it is necessary."
 
On 2016-09-19, WoSign issued a [https://www.wosign.com/english/News/WoSign_completed_equity_investment_to_StartCom_CA.htm press release] saying that they have "made an equity investment" in StartCom CA.
 
===Further Comments and Conclusion===
 
Mozilla has confirmed with a Hebrew-speaking lawyer that, as far as the Israeli company authorities are concerned, the transaction which completed the chain to give WoSign 100% ownership of StartCom completed on November 1st 2015. We maintain that this is the date at which the ownership change should have been disclosed to Mozilla.
 
In addition, WoSign's press release about their "equity investment" seems to be economical with the truth; WoSign owns 100% of StartCom. The statement that "WoSign and StartCom [are] two companies operate[d] and managed independently" is hard to square with the fact that the same person is sole director of StartCom and CEO of WoSign. Also, there is technical evidence that StartCom are now using a large part of WoSign's issuance infrastructure.


==Issue S: Backdated SHA-1 Certs (January 2016)==
==Issue S: Backdated SHA-1 Certs (January 2016)==
Line 239: Line 296:
These are the only certs for which cryptographic proof of backdating is available. However, other strong circumstantial evidence suggests that backdating is more prevalent.
These are the only certs for which cryptographic proof of backdating is available. However, other strong circumstantial evidence suggests that backdating is more prevalent.


Firstly, around 12th May 2016, WoSign started using a new certificate template for some of their SHA-1 issuances. This has a fixed notAfter date of 2016-12-29T16:00:00Z (i.e. midnight on 29th/30th December, CST). This may have been a (sensible) move to prevent accidentally issuing SHA-1 certs which ran into 2017. We have found 939 SHA-1 certificates with this fixed notAfter date, including the above three.
Firstly, around 12th May 2015, WoSign started using a new certificate template for some of their SHA-1 issuances. This has a fixed notAfter date of 2016-12-29T16:00:00Z (i.e. midnight on 29th/30th December, CST). This may have been a (sensible) move to prevent accidentally issuing SHA-1 certs which ran into 2017. We have found 939 SHA-1 certificates with this fixed notAfter date, including the above three.


Certificates issued using this template almost exclusively have notBefore dates on working days in China, suggesting they are issued by explicit WoSign employee action. All of them have notBefores between Monday and Friday, except for 13 on a Saturday and 66 on a Sunday. Of those 66, 4 have notBefores on 2015-09-06, a Sunday which was, unusually, [https://www.thebeijinger.com/blog/2015/05/13/china-announces-special-three-day-september-holiday-mark-70th-anniversary-end-world a working day in China]. The other 62 all have notBefores on 2015-12-20, which was a Sunday, and not a working day in China. This suggests that, for these 62, the notBefore does not reflect the actual issuance date.  
Certificates issued using this template almost exclusively have notBefore dates on working days in China, suggesting they are issued by explicit WoSign employee action. All of them have notBefores between Monday and Friday, except for 13 on a Saturday and 66 on a Sunday. Of those 66, 4 have notBefores on 2015-09-06, a Sunday which was, unusually, [https://www.thebeijinger.com/blog/2015/05/13/china-announces-special-three-day-september-holiday-mark-70th-anniversary-end-world a working day in China]. The other 62 all have notBefores on 2015-12-20, which was a Sunday, and not a working day in China. This suggests that, for these 62, the notBefore does not reflect the actual issuance date.  
Line 283: Line 340:
===WoSign Response===
===WoSign Response===


This issue has been raised with WoSign, and we await their response.
This issue is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. Of the 64 certificates they consider, WoSign attribute 6 to a dual-issuance bug, 9 they say are not problematic because they were issued on December 31st 2015, 2 are the mis-issued certs relating to Issue V, and the other 47 are "normal SHA-1 orders".
 
===Further Comments===
 
Mozilla is seeking further information on the details in WoSign's report and will make further comment at a later date.


==Issue T: alicdn.com Misissuance (June 2016)==
==Issue T: alicdn.com Misissuance (June 2016)==


A certificate has been issued in June 2016 to alicdn.com which, it is claimed, was not requested by the owner of that domain. However, it has not yet been possible to confirm that this cert has been misissued because the owner of the private key has not been located. The domains in question currently use certificates from Symantec.
A certificate has been issued in June 2016 to alicdn.com which was not requested by the owner of that domain. The domains in question currently use certificates from Symantec.


* [https://gist.github.com/xiaohuilam/8589f2dfaac435bae4bf8dfe0984f69e Cert on Github Gist]
* [https://gist.github.com/xiaohuilam/8589f2dfaac435bae4bf8dfe0984f69e Cert on Github Gist]
Line 294: Line 355:
===WoSign Response===
===WoSign Response===


This issue has been raised with WoSign, who are investigating the issue with Alibaba (owner of the domain in question). This issuance used website control validation, which WoSign has since stopped doing. We await their fuller response.
This issue is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. WoSign assert that they completed the domain control checks correctly.
 
===Further Comments and Conclusion===
 
The owners of alicdn.com have confirmed directly to Mozilla that this incident was caused by an attacker being able to control content on their domain.
 
We would have some concerns with how WoSign's systems validated website control. However, they no longer support this method. This "misissuance" was possible only because alicdn.com was, for some period of time, controlled by an attacker. Therefore, no blame can be attributed to WoSign for the misissuance itself.


==Issue V: StartEncrypt (July 2016)==
==Issue V: StartEncrypt (July 2016)==
Line 314: Line 381:
===WoSign Response===
===WoSign Response===


2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official issue report].
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official issue report]. This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report].


===Further Comments===
===Further Comments and Conclusion===


* This issue does not paint a picture of careful software development practices and quality assurance - having unused code around capable of issuing BR-violating certificates does not seem like responsible practice.
* This issue does not paint a picture of careful software development practices and quality assurance - having unused code around capable of issuing BR-violating certificates does not seem like responsible practice.


* The question of why StartCom was able to trigger certificate-issuance code which WoSign has stopped developing and maintaining is also still open.
* The question of why StartCom was able to trigger certificate-issuance code which WoSign has stopped developing and maintaining is also still open.
==Issue X: Unpatched Software (September 2016)==
The first WoSign [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf incident report], produced in response to other issues listed on this page, has a screenshot of a dig query from their validation server. The dig program is part of the bind-utils package, and the output of dig appears to show a bind-utils version of 9.7.3-8.P3.el6. The "el6" shows that this is a version built for Red Hat Enterprise Linux 6. This version of bind-utils was released in [https://rhn.redhat.com/errata/RHBA-2011-1697.html December 2011] and so is very out of date.
The next release of this package for EL6 following the one WoSign are using is bind-utils 9.7.3-8.P3.el6_2.1, which was released [https://rhn.redhat.com/errata/RHBA-2011-1836.html a little later in December 2011]. The most recent version is 9.8.2-0.47.rc1.el6, which was released on the [https://rhn.redhat.com/errata/RHBA-2016-0784.html 10th of May 2016]. There are 19 patched CVEs between the version WoSign is suspected of running and the current version. None of these CVEs are especially severe. However, if this software is in fact that far out of date (nearly five years), it raises questions about the overall patch level of their verification server and even their other infrastructure.
WoSign's [https://cert.webtrust.org/SealFile?seal=2019&file=pdf most recent audit] used the "[http://www.webtrust.org/homepage-documents/item79806.pdf SSL Baseline With Network Security - Version 2.0]" criteria. These criteria integrate two CA/Browser Forum Documents - the SSL BRs and the Network & Certificate Systems Security Requirements.
A bullet on page 19 of the Network Security Requirements requires that "Recommended security patches are applied to Certificate Systems within six months of the security patch’s availability, unless the CA documents that the security patch would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch." That appears not to be true of their version of bind, and so may well not be true of other more critical packages on their systems.
We would expect the presence of badly outdated software and the lack of an appropriate patching regime to have been caught by WoSign's auditors.
Thanks to Paul Pearce for his help with this issue.
===WoSign Response===
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===
N/A.


==Cross Signing==
==Cross Signing==


It is important background information to know which WoSign roots are cross-signed by other trusted or previously-trusted roots. The following cross-signatures are currently known:
It is important background information to know which WoSign roots are cross-signed by other trusted or previously-trusted roots. The following unexpired and unrevoked cross-signatures are currently known:
{| class="wikitable"
{| class="wikitable"
!Target
!Target
Line 348: Line 437:
|Asseco Data Systems S.A.
|Asseco Data Systems S.A.
|[https://crt.sh/?id=15147905 2020-11-02T01:01:59Z]
|[https://crt.sh/?id=15147905 2020-11-02T01:01:59Z]
|
| Revoked as of 2016-11-29, according to Asseco
|- style="vertical-align:top;"
|- style="vertical-align:top;"
|/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign G2
|/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign G2
Line 354: Line 443:
|Asseco Data Systems S.A.
|Asseco Data Systems S.A.
|[https://crt.sh/?id=10591186 2020-11-02T01:59:59Z]
|[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."
|}
|}
Kathleen Wilson
Confirmed users, Administrators
5,526

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1147279...1239778"