User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20071127 Firefox/188.8.131.52 Build Identifier: Name of the CA certificate in question: The Trustwave "SecureTrust CA" root certificate is located here: https://www.securetrust.com/legal/STCA.txt) Published CP/CPS where we describe how we're operating in accordance with the EV guidelines: http://www.securetrust.com/legal/issuer.html includes: SecureTrust Extended Validation CPS Extended Validation SSL Relying Party Agreement Extended Validation Subcriber Agreement SecureTrust CA CRL Published CPSs for other uses: https://www.securetrust.com/legal/ Current (1ssued November 2007) AICPA/CICA WebTrust for Certification Authorities Audit Report including EV audit can be found here: https://cert.webtrust.org/ViewSeal?id=359 EV OID(s) for the CA certificate in question: 2.16.840.1.114404.1.1.2.4.1 (http://www.securetrust.com/legal/issuer.html) This CA is currently/soon shall be used to issue certificates marked for: serverAuth (184.108.40.206.220.127.116.11.1) -- TLS Web server authentication (OV/EV only) codeSigning (18.104.22.168.22.214.171.124.3) -- Code signing We currently issue EV and OV certificates off of this root. Based upon outcome of current cabforum activity, we may also issue code signing certificates off of this root. SHA1 thumbprint: 87 82 c6 c3 04 35 3b cf d2 96 92 d2 59 3e 7d 44 d9 34 ff 11 Certificate: Data: Version: 3 (0x2) Serial Number: 0c:f0:8e:5c:08:16:a5:ad:42:7f:f0:eb:27:18:59:d0 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=SecureTrust Corporation, CN=SecureTrust CA Validity Not Before: Nov 7 19:31:18 2006 GMT Not After : Dec 31 19:40:55 2029 GMT Subject: C=US, O=SecureTrust Corporation, CN=SecureTrust CA Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:ab:a4:81:e5:95:cd:f5:f6:14:8e:c2:4f:ca:d4: e2:78:95:58:9c:41:e1:0d:99:40:24:17:39:91:33: 66:e9:be:e1:83:af:62:5c:89:d1:fc:24:5b:61:b3: e0:11:11:41:1c:1d:6e:f0:b8:bb:f8:de:a7:81:ba: a6:48:c6:9f:1d:bd:be:8e:a9:41:3e:b8:94:ed:29: 1a:d4:8e:d2:03:1d:03:ef:6d:0d:67:1c:57:d7:06: ad:ca:c8:f5:fe:0e:af:66:25:48:04:96:0b:5d:a3: ba:16:c3:08:4f:d1:46:f8:14:5c:f2:c8:5e:01:99: 6d:fd:88:cc:86:a8:c1:6f:31:42:6c:52:3e:68:cb: f3:19:34:df:bb:87:18:56:80:26:c4:d0:dc:c0:6f: df:de:a0:c2:91:16:a0:64:11:4b:44:bc:1e:f6:e7: fa:63:de:66:ac:76:a4:71:a3:ec:36:94:68:7a:77: a4:b1:e7:0e:2f:81:7a:e2:b5:72:86:ef:a2:6b:8b: f0:0f:db:d3:59:3f:ba:72:bc:44:24:9c:e3:73:b3: f7:af:57:2f:42:26:9d:a9:74:ba:00:52:f2:4b:cd: 53:7c:47:0b:36:85:0e:66:a9:08:97:16:34:57:c1: 66:f7:80:e3:ed:70:54:c7:93:e0:2e:28:15:59:87: ba:bb Exponent: 65537 (0x10001) X509v3 extensions: 126.96.36.199.4.1.311.20.2: ...C.A X509v3 Key Usage: Digital Signature, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 42:32:B6:16:FA:04:FD:FE:5D:4B:7A:C3:FD:F7:4C:40:1D:5A:43:AF X509v3 CRL Distribution Points: URI:http://crl.securetrust.com/STCA.crl 188.8.131.52.4.1.311.21.1: ... Signature Algorithm: sha1WithRSAEncryption 30:ed:4f:4a:e1:58:3a:52:72:5b:b5:a6:a3:65:18:a6:bb:51: 3b:77:e9:9d:ea:d3:9f:5c:e0:45:65:7b:0d:ca:5b:e2:70:50: b2:94:05:14:ae:49:c7:8d:41:07:12:73:94:7e:0c:23:21:fd: bc:10:7f:60:10:5a:72:f5:98:0e:ac:ec:b9:7f:dd:7a:6f:5d: d3:1c:f4:ff:88:05:69:42:a9:05:71:c8:b7:ac:26:e8:2e:b4: 8c:6a:ff:71:dc:b8:b1:df:99:bc:7c:21:54:2b:e4:58:a2:bb: 57:29:ae:9e:a9:a3:19:26:0f:99:2e:08:b0:ef:fd:69:cf:99: 1a:09:8d:e3:a7:9f:2b:c9:36:34:7b:24:b3:78:4c:95:17:a4: 06:26:1e:b6:64:52:36:5f:60:67:d9:9c:c5:05:74:0b:e7:67: 23:d2:08:fc:88:e9:ae:8b:7f:e1:30:f4:37:7e:fd:c6:32:da: 2d:9e:44:30:30:6c:ee:07:de:d2:34:fc:d2:ff:40:f6:4b:f4: 66:46:06:54:a6:f2:32:0a:63:26:30:6b:9b:d1:dc:8b:47:ba: e1:b9:d5:62:d0:a2:a0:f4:67:05:78:29:63:1a:6f:04:d6:f8: c6:4c:a3:9a:b1:37:b4:8d:e5:28:4b:1d:9e:2c:c2:b8:68:bc: ed:02:ee:31 -----BEGIN CERTIFICATE----- MIIDuDCCAqCgAwIBAgIQDPCOXAgWpa1Cf/DrJxhZ0DANBgkqhkiG9w0BAQUFADBI MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXU2VjdXJlVHJ1c3QgQ29ycG9yYXRpb24x FzAVBgNVBAMTDlNlY3VyZVRydXN0IENBMB4XDTA2MTEwNzE5MzExOFoXDTI5MTIz MTE5NDA1NVowSDELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF1NlY3VyZVRydXN0IENv cnBvcmF0aW9uMRcwFQYDVQQDEw5TZWN1cmVUcnVzdCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAKukgeWVzfX2FI7CT8rU4niVWJxB4Q2ZQCQXOZEz Zum+4YOvYlyJ0fwkW2Gz4BERQRwdbvC4u/jep4G6pkjGnx29vo6pQT64lO0pGtSO 0gMdA+9tDWccV9cGrcrI9f4Or2YlSASWC12juhbDCE/RRvgUXPLIXgGZbf2IzIao wW8xQmxSPmjL8xk037uHGFaAJsTQ3MBv396gwpEWoGQRS0S8Hvbn+mPeZqx2pHGj 7DaUaHp3pLHnDi+BeuK1cobvomuL8A/b01k/unK8RCSc43Oz969XL0Imnal0ugBS 8kvNU3xHCzaFDmapCJcWNFfBZveA4+1wVMeT4C4oFVmHursCAwEAAaOBnTCBmjAT BgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQUQjK2FvoE/f5dS3rD/fdMQB1aQ68wNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC5zZWN1cmV0cnVzdC5jb20vU1RDQS5jcmwwEAYJKwYBBAGC NxUBBAMCAQAwDQYJKoZIhvcNAQEFBQADggEBADDtT0rhWDpSclu1pqNlGKa7UTt3 6Z3q059c4EVlew3KW+JwULKUBRSuSceNQQcSc5R+DCMh/bwQf2AQWnL1mA6s7Ll/ 3XpvXdMc9P+IBWlCqQVxyLesJugutIxq/3HcuLHfmbx8IVQr5Fiiu1cprp6poxkm D5kuCLDv/WnPmRoJjeOnnyvJNjR7JLN4TJUXpAYmHrZkUjZfYGfZnMUFdAvnZyPS CPyI6a6Lf+Ew9Dd+/cYy2i2eRDAwbO4H3tI0/NL/QPZL9GZGBlSm8jIKYyYwa5vR 3ItHuuG51WLQoqD0ZwV4KWMabwTW+MZMo5qxN7SN5ShLHZ4swrhovO0C7jE= -----END CERTIFICATE----- Note information on the "historical dangling" OIDS above in the extension - 184.108.40.206.4.1.311.21.1 & 220.127.116.11.4.1.311.20.2 - which currently are of no importance or relevance, to us, can be found here: http://support.microsoft.com/kb/287547. Also, these extensions are NOT CRITICAL. Reproducible: Always Steps to Reproduce: 1. 2. 3.
"XRamp Security Services, Inc.", successor to SecureTrust corporation, a wholly owned subsidiary of Trustwave Holdings, Inc. ("Trustwave")
This is basically a resubmittal of bug 367670 for just the SecureTrust CA root, is it not? Is the information in this bug (audit, CPS, etc.) more up to date than in the other bug? If so I may close the other bug and focus on this one.
I've resolved bug 367670 as INVALID because it is superseded by this bug. I've renamed the SecureTrust entry in the pending request list to reference Trustwave instead, and have updated the entry to include the latest information as I understand it: http://www.mozilla.org/projects/security/certs/pending/#Trustwave Andrew, please review the information for Trustwave and the SecureTrust CA and let me know if it's correct or needs correction.
I have confirmed with our auditor that the final release version (Effective 09/30/07) of the EV Audit specification was used.
Independent of approval process, for technical testing purposes: Could you please supply an https:// URL to an example SSL server (customer or demo) that uses a server cert issued (directly or through intermediates) by this root? Should you request multiple roots to be enabled for EV, please provide one example URL for each root. Thank you.
I have now completed my review of Trustwave's application for adding the SecureTrust CA root CA certificate and enabling it for EV use, per the official Mozilla CA certificate policy at: http://www.mozilla.org/projects/security/certs/policy/ I apologize for any delays on my part in doing the review. Here follows my final assessment. If anyone sees any factual errors, please point them out. Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by Trustwave, or of instances where Trustwave has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report. Section 6 [Relevancy and Policy]. Trustwave appears to provide a service relevant to Mozilla users; it is a commercial CA operating in United States and serving customers worldwide, incorporating the SecureTrust and XRamp CAs. Its policies are documented in its CPSs: https://www.securetrust.com/legal/evCPS.pdf https://www.securetrust.com/legal/securetrust%20cps%20for%20ov.pdf https://www.securetrust.com/legal/SecureTrust_SMIME_CPS_1_6_0.pdf https://www.securetrust.com/legal/SecureTrust_Code_Signing_CPS.pdf (These are for EV SSL certificates, OV SSL certificates, S/MIME email certificates, and code signing certificates respectively.) * Email: The SecureTrust CA does not issue email certificates. * SSL: For OV SSL certificates Trustwave validates organizational identity and control of the domain referenced in the certificate. (See section III.B.3 in the OV CPS.) For EV SSL certificates Trustwave validates identity and domain ownership using procedures consistent with the EV guidelines. (See section III.B.3 in the EV CPS.) * Code: For code signing certificates Trustwave verifies the applicant's identity. (See section III.B.2 of the Trustwave code signing CPS.) Section 8-10 [Audit]. Trustwave has successfully completed an independent audit using the WebTrust for CAs criteria and the WebTrust EV criteria. The audit was done by Boysen & Miller PLLC. Attestation of the successful completion of the audit is in the form of a standard WebTrust/WebTrust EV report available at https://cert.webtrust.org/SealFile?seal=359&file=pdf Note that the WebTrust EV audit was done against the final 1.0 version of the EV guidelines. Audits are done annually. Section 13 [Certificate Hierarchy]. This particular request is for the SecureTrust CA root. Trustwave also has two other root CAs; requests for those roots are being handled separately as bug 409837 and bug 409840. At this time there are no subordinate CAs for the SecureTrust CA; instead end entity certificates are issued directly from the root, with different classes of certificates under different certificate policies. The SecureTrust CA is not associated with a single CPS, rather end entity certs are associated with policies that link to the CPS that the certificate was issued under: an EV CPS, an OV CPS, etc. (Note that mixing certificates of different classes under a single CA is contrary to section 13 of the Mozilla CA certificate policy; however that section is a recommendation only, not a requirement.) Other: Trustwave issues CRLs at least every 10-14 days. (Note that this is an upper bound, per sections II.I and V.C of the EV CPS and other CPS documents. Trustwave may in fact issue CRLs more frequently, but this is not stated in the CPSs.) Trustwave does not currently have an OCSP responder. Based on the above information, I am minded to approve the inclusion of the SecureTrust CA root in NSS (and thence in Firefox and other Mozilla-based products), with trust bits for SSL and code signing set, and the root's enabling for EV with policy OID 2.16.840.1.114404.1.1.2.4.1. Before I issue my final approval, I'm opening up a period of public discussion of this request in the mozilla.dev.tech.crypto newsgroup .  The mozilla.dev.tech.crypto newsgroup is accessible via NNTP-capable newsreaders at: news://news.mozilla.org/mozilla.dev.tech.crypto via email by subscribing to the associated mailing list: https://lists.mozilla.org/listinfo/dev-tech-crypto and via the web at: http://groups.google.com/group/mozilla.dev.tech.crypto/topics
(In reply to comment #6) > Section 13 [Certificate Hierarchy]. This particular request is for the > SecureTrust CA root. Trustwave also has two other root CAs; requests for those > roots are being handled separately as bug 409837 and bug 409840. Sorry, that should be bug 409838 and bug 409840.
(In reply to comment #5) > Independent of approval process, for technical testing purposes: Could you > please supply an https:// URL to an example SSL server (customer or demo) that > uses a server cert issued (directly or through intermediates) by this root? > Should you request multiple roots to be enabled for EV, please provide one > example URL for each root. Thank you. > https://www.harrycooper.com/ -----BEGIN CERTIFICATE----- MIIEHzCCAwegAwIBAgIEQAAA4jANBgkqhkiG9w0BAQUFADBIMQswCQYDVQQGEwJV UzEgMB4GA1UEChMXU2VjdXJlVHJ1c3QgQ29ycG9yYXRpb24xFzAVBgNVBAMTDlNl Y3VyZVRydXN0IENBMB4XDTA3MTIxODIzNDQwNloXDTA5MTIxNzIzNDQwNlowgdox ETAPBgNVBAUTCDAwMDMwODgxMRMwEQYLKwYBBAGCNzwCAQMTAlVTMRkwFwYLKwYB BAGCNzwCAQITCE1pc3NvdXJpMRswGQYDVQQPExJWMS4wLCBDbGF1c2UgNS4oZCkx CzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaXNzb3VyaTEUMBIGA1UEBxMLU3ByaW5n ZmllbGQxJDAiBgNVBAoTG1RoZSBIYXJyeSBDb29wZXIgU3VwcGx5IENvLjEcMBoG A1UEAxMTd3d3LmhhcnJ5Y29vcGVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Vd9Dgjkd6jKzZNbIl04nisJCS8LQLjg8iL+2Apw+Tw5u3aCZiGtyzcv 48WuNhqsk+QU3ZKiRrJ+bWN0uGTMQg36Jz5NOgqbOVOcFwkxGoXVM2ZQonyBDftb 5PBDDTxtuGSuodV5c28HiV20Go+3U8KyIZnPxCXGum9S5pPr+78CAwEAAaOCAQAw gf0wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBRCMrYW+gT9/l1LesP990xAHVpD rzAdBgNVHQ4EFgQU1h623ibQlbj6D/MueMRxmAvTW5YwCwYDVR0PBAQDAgXgMBMG A1UdJQQMMAoGCCsGAQUFBwMBMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwu c2VjdXJldHJ1c3QuY29tL1NUQ0EuY3JsMFUGA1UdIAROMEwwSgYMYIZIAYb9ZAEB AgQBMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc2VjdXJldHJ1c3QuY29tL2xl Z2FsL2lzc3Vlci5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQCbPL7HOxFdOk7upVp/ HrSSdJnkclbb4m/GI57Q8O4EbjkvzF3DHMAu0TX9upUaltiCzi/Ompo1NMY9c45v NB7LeV8kwAZcjaPG+g0GTXljWfelicQYvnxcTVyorDM4JoPTiOsrulFlhuxDmUIz qKslntNFBWnMYQTBL+tPo+qodkeMj4l7qY3DNflYOw1NlNXmmTJM0q/HzS/bGN/E G/plqp8khcsrZ4ooMectVDxq1mgdd3Xyqawa1p/yCO+gty2UvcbMejxA8pdi9LHG NdQ9TKuvIgu2nC6GP0+XyJPCPQ2xR+cgj++i1l+/E/yPfZm8215Kx+WWTQ/r9MsO ql5D -----END CERTIFICATE-----
The comment period has ended and there are no outstanding issues or questions, so I'm formally approving this Trustwave request to add the "SecureTrust CA" root and enable it for EV use. I'll proceed to file bugs against NSS and PSM for the actual changes.
Filed bug 418907 to add the root cert and 418910 to EV enable it. Marking this bug as dependent just on bug 418910, since bug 418910 already depends on bug 418907.
Depends on: 418910
Summary: Please add the Trustwave "SecureTrust CA" root certificate and mark for EV → add Trustwave "SecureTrust CA" EV root
According to http://www.mozilla.org/projects/security/certs/pending/#Trustwave the status of this request is that it has been approved for inclusion.
Whiteboard: EV → EV - inclusion in progress
Whiteboard: EV - inclusion in progress → EV - inclusion approved
Root is in Firefox 3.0.2. RESOLVING FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.