Closed Bug 529286 Opened 15 years ago Closed 13 years ago

Add ipsCA Global and ipsCA Main root certificates

Categories

(CA Program :: CA Certificate Root Program, task)

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: j.pascual, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: Information incomplete)

Attachments

(2 files)

Initial Information Gathering Document
28.66 KB, application/pdf
Details
Editable Version of Info Gathering Doc
120.50 KB, application/octet-stream
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: 

ipsCA, a Spanish company in public key technologies applied to digital trust announced the upcoming availability of two new hierarchies of trust will be released during the fourth quarter of this year. Hierarchies have been created during the previous quarter and has been working on improving service quality and security features of the certificates will be issued by the new hierarchy. During this time they have been conducting activities aimed at achieving the maximum dissemination of new roots of trust, which spread to major software vendors require stamps based quality audits, so we would like to apply for including these two new roots within Mozilla Software.

1.	General information about the CA’s associated organization (i.e., the company, nonprofit organization, or government agency operating the CA), including 
1.	Name: ipsCA Main Root
2.	Website URL: http://www.ipsca.com
3.	Organizational type: private
4.	Primary market / customer base: worldwide CA, with special focus on Spain, where there are the headquarters. More than 12.000 Universities and educational entities (in the USA mainly) had obtained without any cost our SSL certificates. 

2.	For each root CA whose certificate is to be included in Mozilla (or whose metadata is to be modified): 

1.	The name of the root CAs. ipsCA Main Root ipsCA Global Root
2.	The root CA certificate. 
http://certs.ipsca.com/store/ipsCAMain.der
http://certs.ipsca.com/store/ipsCAGlobal.der
3.	The X.509 certificate version. Version 3
4.	SHA-1 fingerprint. Respectively:
ipsCA Main Root - cf e4 31 3d ba 05 b8 a7 c3 00 63 99 5a 9e b7 c2 47 ad 8f d5 
ipsCA Global Root - 3c 71 d7 0e 35 a5 da a8 b2 e3 81 2d c3 67 74 17 f5 99 0d f3
5.	Type of signing key. RSA
6.	Signing key parameters. 2048 bits.
EKUs Assigned (check if EKUs apply):
X	Server Authentication EKU=1.3.6.1.5.5.7.3.1
X	Client Authentication EKU=1.3.6.1.5.5.7.3.2
X	Secure E-mail EKU=1.3.6.1.5.5.7.3.4
X	Code Signing EKU=1.3.6.1.5.5.7.3.3
X	Time stamping EKU=1.3.6.1.5.5.7.3.8
X	Encrypting File System EKU=1.3.6.1.4.1.311.10.3.4
	IPSec (Tunnel) EKU=1.3.6.1.5.5.7.3.6
	IPSec (User) EKU=1.3.6.1.5.5.7.3.7
7.	Valid from (YYYY-MM-DD). 07 September 2009
8.	Valid to (YYYY-MM-DD). 25 December 2029 
9.	A description of the PKI hierarchy rooted at or otherwise associated with this root CA certificate, including: 
No subordinated CA exists for the moment. Our plan is to generate new SubCAs for different purposes and all of them will be under our CPS. In the near future we will build up a subCA for SSL certificates issuance by ipsCA to continue our SSL business area where our the currently root certificate IPS SERVIDORES, included in the Mozilla trusted Store, is expiring on 29 December 2009.
10.	Whether certificates are issued for any of the following purposes within the hierarchy rooted at this root CA certificate: 
Only this one ->	Certificates usable for enabling web or other servers to support SSL/TLS connections. 
11.	If SSL certificates are issued within the hierarchy rooted at this root CA certificate: 
Whether or not the domain name referenced in the certificate is verified to be owned/controlled by the certificate subscriber. 
ipsCA will perform verification of certificate information as follows:
-  Limited check of the applicant's domain name against a public domain name registry; 
- Confirmation of applicant's Company name, name, address and phone number against information contained in an independent third party business database. 
- Faxed documentation will be required when applicants company name cannot be validated using available information.  
15.	Example certificate(s) issued within the hierarchy rooted at this root, including the full certificate chain(s) where applicable. (There should be at least one example certificate for each of the major types of certificates issued, e.g., email vs. SSL vs. code signing, or EV vs. OV vs. DV. For SSL certificates this should also include URLs of one or more web servers using the certificate(s).) 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            10:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=ES, ST=Madrid, L=Madrid, O=IPS Certification Authority s.l. ipsCA, OU=ipsCA, CN=ipsCA Main CA Root/emailAddress=main01@ipsca.com
        Validity
            Not Before: Sep 22 11:59:24 2009 GMT
            Not After : Sep 22 11:59:24 2010 GMT
        Subject: C=ES, ST=Madrid, L=Madrid, O=ipsCA, OU=Certificates, CN=sirius.ipsca.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:8e:65:a5:65:f4:77:ae:c5:66:0c:e9:fa:e7:f6:
                    69:bd:d5:88:4d:5a:4d:7e:5f:a3:0d:bf:5b:c5:2b:
                    b1:fb:b4:64:ae:c7:90:d1:1f:42:42:93:67:34:ec:
                    a1:1b:7c:96:94:39:d9:8f:2b:70:bf:36:d6:88:c2:
                    f7:91:1d:bb:91:de:2d:33:e1:3a:15:60:89:e8:62:
                    b5:76:37:d5:13:9a:b9:5c:df:09:37:dc:cb:c7:10:
                    4a:00:7d:64:35:a8:4f:15:61:fc:aa:a3:7c:21:73:
                    25:f5:db:7d:9a:96:1c:12:03:51:16:e7:a7:fd:54:
                    41:89:94:c4:ae:3c:1b:2f:8b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Cert Type:
                SSL Server
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Key Identifier:
                D9:FF:8D:8E:0E:27:B2:5A:71:B8:C6:85:03:5B:32:30:89:1E:FC:6E
            X509v3 Authority Key Identifier:
                keyid:61:ED:39:8D:6B:3C:E1:36:C6:CF:DB:41:FC:1B:43:51:57:CB:4D:6B
                DirName:/C=ES/ST=Madrid/L=Madrid/O=IPS Certification Authority s.l. ipsCA/OU=ipsCA/CN=ipsCA Main CA Root/emailAddress=main01@ipsca.com
                serial:00

            X509v3 Issuer Alternative Name:
                email:main01@ipsca.com, URI:http://crlmain01.ipsca.com/crl/crtmain01.crt
            X509v3 CRL Distribution Points:
                URI:http://crlmain01.ipsca.com/crl/crlmain01.crl

            Authority Information Access:
                OCSP - URI:http://ocspmain01.ipsca.com/

    Signature Algorithm: sha1WithRSAEncryption
        06:77:32:2a:f8:dd:1d:4a:85:10:46:ee:8c:a9:cb:cc:f7:27:
        82:d9:70:5e:33:90:ca:1b:ab:31:41:79:86:fc:49:9a:10:64:
        61:38:00:ae:72:ee:9f:bd:b4:5d:85:90:d9:8c:64:ca:bf:b9:
        62:2e:33:93:ed:45:43:52:29:34:2e:da:c5:a6:00:1a:a6:21:
        85:07:6a:95:a9:d0:1a:74:8b:fa:af:6f:7e:aa:83:37:58:0b:
        7e:3b:a7:15:96:16:67:68:37:36:89:ac:12:0b:f5:d4:ea:30:
        b8:ad:82:98:0c:98:ae:90:23:38:d5:6f:14:5e:79:a0:92:d6:
        7b:ef:fd:74:24:59:95:f6:06:63:72:2a:ed:97:3c:94:ec:13:
        a4:ac:29:e5:ef:bc:5d:14:68:d0:d6:2f:e2:d9:77:ce:1b:24:
        d3:d4:d0:06:3d:a8:1b:7c:dc:ce:1f:b0:34:6d:8a:a5:06:4d:
        86:8c:f9:7c:95:20:7c:7d:7c:4e:88:27:41:45:2c:ef:4a:42:
        24:72:67:f0:29:a8:f5:78:b7:4f:f9:18:27:ec:0c:18:72:25:
        82:5f:51:93:76:9e:46:8b:a0:df:fc:13:bd:6e:08:9f:24:55:
        14:82:53:b7:98:31:79:f2:cb:f1:1e:77:4e:c6:cb:85:80:3e:
        d1:c1:c6:ab
-----BEGIN CERTIFICATE-----
MIIFJDCCBAygAwIBAgIUEAAAAAAAAAAAAAAAAAAAAAAAAAEwDQYJKoZIhvcNAQEF
BQAwga4xCzAJBgNVBAYTAkVTMQ8wDQYDVQQIEwZNYWRyaWQxDzANBgNVBAcTBk1h
ZHJpZDEvMC0GA1UEChMmSVBTIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IHMubC4g
aXBzQ0ExDjAMBgNVBAsTBWlwc0NBMRswGQYDVQQDExJpcHNDQSBNYWluIENBIFJv
b3QxHzAdBgkqhkiG9w0BCQEWEG1haW4wMUBpcHNjYS5jb20wHhcNMDkwOTIyMTE1
OTI0WhcNMTAwOTIyMTE1OTI0WjBxMQswCQYDVQQGEwJFUzEPMA0GA1UECBMGTWFk
cmlkMQ8wDQYDVQQHEwZNYWRyaWQxDjAMBgNVBAoTBWlwc0NBMRUwEwYDVQQLEwxD
ZXJ0aWZpY2F0ZXMxGTAXBgNVBAMTEHNpcml1cy5pcHNjYS5jb20wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAI5lpWX0d67FZgzp+uf2ab3ViE1aTX5fow2/W8Ur
sfu0ZK7HkNEfQkKTZzTsoRt8lpQ52Y8rcL821ojC95Edu5HeLTPhOhVgiehitXY3
1ROauVzfCTfcy8cQSgB9ZDWoTxVh/KqjfCFzJfXbfZqWHBIDURbnp/1UQYmUxK48
Gy+LAgMBAAGjggH4MIIB9DAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIGQDAT
BgNVHSUEDDAKBggrBgEFBQcDATAdBgNVHQ4EFgQU2f+Njg4nslpxuMaFA1syMIke
/G4wgdsGA1UdIwSB0zCB0IAUYe05jWs84TbGz9tB/BtDUVfLTWuhgbSkgbEwga4x
CzAJBgNVBAYTAkVTMQ8wDQYDVQQIEwZNYWRyaWQxDzANBgNVBAcTBk1hZHJpZDEv
MC0GA1UEChMmSVBTIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IHMubC4gaXBzQ0Ex
DjAMBgNVBAsTBWlwc0NBMRswGQYDVQQDExJpcHNDQSBNYWluIENBIFJvb3QxHzAd
BgkqhkiG9w0BCQEWEG1haW4wMUBpcHNjYS5jb22CAQAwSQYDVR0SBEIwQIEQbWFp
bjAxQGlwc2NhLmNvbYYsaHR0cDovL2NybG1haW4wMS5pcHNjYS5jb20vY3JsL2Ny
dG1haW4wMS5jcnQwPQYDVR0fBDYwNDAyoDCgLoYsaHR0cDovL2NybG1haW4wMS5p
cHNjYS5jb20vY3JsL2NybG1haW4wMS5jcmwwOAYIKwYBBQUHAQEELDAqMCgGCCsG
AQUFBzABhhxodHRwOi8vb2NzcG1haW4wMS5pcHNjYS5jb20vMA0GCSqGSIb3DQEB
BQUAA4IBAQAGdzIq+N0dSoUQRu6MqcvM9yeC2XBeM5DKG6sxQXmG/EmaEGRhOACu
cu6fvbRdhZDZjGTKv7liLjOT7UVDUik0LtrFpgAapiGFB2qVqdAadIv6r29+qoM3
WAt+O6cVlhZnaDc2iawSC/XU6jC4rYKYDJiukCM41W8UXnmgktZ77/10JFmV9gZj
cirtlzyU7BOkrCnl77xdFGjQ1i/i2XfOGyTT1NAGPagbfNzOH7A0bYqlBk2GjPl8
lSB8fXxOiCdBRSzvSkIkcmfwKaj1eLdP+Rgn7AwYciWCX1GTdp5Gi6Df/BO9bgif
JFUUglO3mDF58svxHndOxsuFgD7Rwcar
-----END CERTIFICATE-----

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            10:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:03
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=ES, ST=Madrid, L=Madrid, O=IPS Certification Authority s.l. ip
sCA, OU=ipsCA, CN=ipsCA Global CA Root/emailAddress=global01@ipsca.com
        Validity
            Not Before: Sep 22 11:57:52 2009 GMT
            Not After : Sep 22 11:57:52 2010 GMT
        Subject: C=ES, ST=Madrid, L=Madrid, O=ipsCA, OU=Certificados, CN=orion.i
psca.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:c5:ab:69:2a:c2:f5:2e:39:91:45:76:91:bd:54:
                    6f:aa:27:fb:df:6d:92:07:fc:72:0c:4d:0f:36:70:
                    91:1a:7d:c0:82:30:a1:84:7e:a5:37:61:21:ce:01:
                    2b:85:bb:67:4d:5d:79:d8:76:97:b2:82:d6:5f:f5:
                    57:29:0f:d3:3c:87:84:b8:47:b3:27:da:74:09:cc:
                    8e:95:24:19:8c:b1:8e:af:06:38:c2:7f:47:c4:6c:
                    7e:5f:6c:1b:99:56:89:10:51:07:30:06:b0:eb:54:
                    92:ea:53:c1:cd:f0:32:fc:16:4b:ec:fc:0c:d5:d8:
                    20:74:fb:c1:07:93:bf:0c:31
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
            CA:FALSE
            Netscape Cert Type:
            SSL Server
            X509v3 Extended Key Usage:
            TLS Web Server Authentication
            X509v3 Subject Key Identifier:
            AF:9B:47:C0:2D:07:9E:9A:4C:DF:77:64:1E:2A:65:50:83:AE:CC:CE
            X509v3 Authority Key Identifier:
            keyid:15:A6:96:80:B1:15:4B:31:C3:C2:9C:F6:E7:13:0B:4B:F3:18:CD:86
            DirName:/C=ES/ST=Madrid/L=Madrid/O=IPS Certification Authority s.l.
ipsCA/OU=ipsCA/CN=ipsCA Global CA Root/emailAddress=global01@ipsca.com
            serial:00

            X509v3 Issuer Alternative Name:
            email:global01@ipsca.com, URI:http://crlglobal01.ipsca.com/crl/crtgl
obal01.crt
            X509v3 CRL Distribution Points:
            URI:http://crlglobal01.ipsca.com/crl/crlglobal01.crl

            Authority Information Access:
            OCSP - URI:http://ocspglobal01.ipsca.com/

    Signature Algorithm: sha1WithRSAEncryption
        74:97:bf:95:bc:6c:e3:54:98:16:28:92:04:14:44:bc:55:b7:
        99:6e:a6:70:33:95:75:f4:09:d7:fd:e1:ba:29:28:df:be:eb:
        12:d2:22:29:12:8c:ed:9a:cf:9f:c4:93:c0:7d:d1:ec:77:11:
        94:3e:48:06:75:94:5f:c3:d3:80:8a:eb:17:16:0f:69:bf:1e:
        e1:7b:58:fc:11:01:83:45:9e:b3:76:1a:18:c4:ad:bb:9d:63:
        4e:db:29:e7:9d:b6:13:95:3c:f2:8d:14:ac:53:0e:64:0d:d7:
        e2:3a:4c:47:0a:56:c9:5a:d1:1d:53:1c:5f:6b:02:fd:ab:d7:
        8a:7e:3a:37:1c:d7:c7:1c:03:7d:b2:f6:9e:c5:69:8c:7f:b3:
        ab:01:0e:7a:e0:dc:38:30:7e:8e:c7:16:3f:f9:ee:b9:aa:d5:
        f0:8b:ba:85:99:02:63:8d:76:4b:da:ad:4f:2b:f2:3b:98:ab:
        bb:0a:bc:0c:4b:7d:8d:d3:ff:ce:86:ff:fc:4a:e0:a2:1d:af:
        74:97:65:cf:11:f7:19:ff:97:1f:95:3d:6b:2d:ef:f1:12:64:
        9d:f2:d7:ce:75:86:e0:e0:83:68:26:d3:3e:60:64:cf:2d:ed:
        ec:eb:39:1b:c2:fd:22:2c:dc:20:e4:37:2c:71:72:b0:ec:93:
        12:99:71:85

16.	Whether or not the validity of end entity and CA certificates issued within the hierarchy rooted at this root may be verified using Certificate Revocation Lists (CRLs) and, if so, the URL(s) at which the CRL(s) may be obtained
 http://crlmain01.ipsca.com/crl/crlmain01.crl
 http://crlglobal01.ipsca.com/crl/crlmain01.crl

17.	Whether or not the validity of end entity and CA certificates issued within the hierarchy rooted at this root may be verified using the Online Certificate Status Protocol (OCSP) and, if so, the URL(s) for the associated OCSP responder(s). 
http://ocspmain01.ipsca.com
http://ocspglobal01.ipsca.com

18.	The maximum time elapsing from the revocation of an end entity or CA certificate until CRLs and/or OCSP responders are updated to reflect that revocation. 
24 Hours

19.	The published document(s) describing how certificates are issued within the hierarchy rooted at this root, as well as other practices associated with the root CA and other CAs in the hierarchy, including in particular the Certification Practice Statement(s) (CPS) and related documents. (These documents should be available at publicly accessible URLs, and should be in English or available in English translation.) 
http://www.ipsca.com/es/Certificates/CPSIPSCAv31.pdf

20.	The published document(s) relating to independent audit(s) of the root CA and any CAs within the hierarchy rooted at the root. (For example, for WebTrust for CAs audits this would be the "audit report and management assertions" document available from the webtrust.org site or elsewhere.) 
Renewed Webtrust seal: https://cert.webtrust.org/ViewSeal?id=933


Reproducible: Always



Expected Results:  
We would like to have all the steps for inclusion passed in the shortest time possible because we are discontinuing our former root CA which is currently included in Mozilla Products IPS SERVIDORES next 29th of December and on this date we will have issued all our customer's certificates with the new hierarchy.We do know that this time is very shot for this inclusion, but this delay i because we have been working hard in solving some security issues before applying. We are confident our position is solid in order to apply for including with a good product.
Starting the information gathering and verification phase as per:
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
The attached document summarizes the information that has been gathered and
verified as per
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.
Whiteboard: Information incomplete
Looks like this bug is still blocking on further information from ipsCA.  Given that there are no maintenance releases scheduled between now and December 29th, which will likely be a problem for ipsCA's customers... 

In any case, we need the details requested by Kathleen here... Juan, can you follow up with the required information?
The University of Wisconsin-Eau Claire 9along with ~12,000 other universities)also uses ipsCA certificates.  I cannot speak for the other universities but we are seeing exactly the same issue as Kathleen Wilson has stated.  

Chip Eckardt
University of Florida is also experiencing this issue. This will cause major problems if Mozilla doesn't add the new CA from IPSCA.
Several sites at Ohio State University are also affected by this.
Is there any way someone at Mozilla can update us on the status of this issue? Is it likely this will be resolved and released in a Firefox update soon? Thank you very much!
The request to have a new root enabled was made at the 2009-11-17 by ipsCA at this bug, Kathleen follow up the day after. There were some additional issues which were discussed at the mozilla.dev.security.policy newsgroup. Don't expect this to be solved very soon.
RE:  Eddy Nigg (StartCom) @ 2009-12-22 10:16:08 PST

Do you happen to have a pointer to the issues in the mozilla.dev.security.policy group?

-Jeff
Actually, the conversations you linked to are discussing this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=523652

Which has been marked as fixed since late November.

As far as I can tell, the only action items for the inclusion of the new root are in this bug.
(In reply to comment #12)
> As far as I can tell, the only action items for the inclusion of the new root
> are in this bug.

Correct. I'm just saying that from experience and knowledge about the inclusion process, this will take a while. The previous issues might influence the discussions a bit as well. See also https://wiki.mozilla.org/CA:How_to_apply#Timeline
Thank you for the feedback and link to that time line. I guess what most of us end users are wondering is, can Mozilla provide an estimate on the date the updated CA will be added to Firefox? Us non-profits are looking at spending thousands of dollars in a hurry to replace certs. If we had an idea when it might be included, it would save a lot of headache. It kind of sucks when we push our users so hard to switch to Firefox from IE and now we're going to have to tell them, use IE for a while. Besides, replacing certs that quickly isn't possible. There is no doubt that most users will see the "untrusted site" error come Jan 1.
I verified that the "untrusted site" error does not show in Internet Explorer 8. That will work for all our PC users, but we still have around 500 Mac users (the error also shows in Apple's Safari browser as well) and running IE is not an option for them.
(In reply to comment #15)
> I verified that the "untrusted site" error does not show in Internet Explorer
> 8. That will work for all our PC users, but we still have around 500 Mac users
> (the error also shows in Apple's Safari browser as well) and running IE is not
> an option for them.

This might be an incomplete installation - does the server send the complete CA certificates chain as required?
So, because ipsCA regenerated their root back in September to fix some of the problems in the previous bug, the ~1 year process starts over again?
Mike, this isn't a good place for discussions, the mozilla.dev.security.policy should be used for that. However, ipsCA's root expires at the 31st of December 2009 and certificates have been issued beyond the life-time of this root. This isn't a problem of Mozilla, more so that the request to include a new root has been made barely a month ago. Please don't blame the wrong party for the shortcomings. The inclusion processes of Mozilla are known to CAs and publicly displayed for everyone to read. This may take up to a year.
(In reply to comment #16)
> (In reply to comment #15)
> > I verified that the "untrusted site" error does not show in Internet Explorer
> > 8. That will work for all our PC users, but we still have around 500 Mac users
> > (the error also shows in Apple's Safari browser as well) and running IE is not
> > an option for them.
> This might be an incomplete installation - does the server send the complete CA
> certificates chain as required?

Yes.
To all those who are impatient for this certificate to be approved and implemented for Gecko-based products:  

The presence of a root certificate in the NSS database used by Gecko-based products indicates that users can place some degree of trust in the use of that certificate for secure Web browsing.  For that trust to be valid, the certificate authority owning the root certificate must undergo some scrutiny, which takes time.  

The timeline for such scrutiny is described at <https://wiki.mozilla.org/CA:Schedule>, which also shows the current queue for the public discussion that is part of the process.  As noted in comment #2, some required information is missing.  That information must be provided by the certificate authority before this request can enter the queue.  

Thus, the problem lies in the hands of ipsCA and not Mozilla.  As pointed out in comment #18, the very late recognition by ipsCA that they had to replace a root certificate that was about to expire compounded the problem.  

Further expressions of the need for haste will not speed the process.  Any shortcuts or other measures to hasten the process can only weaken the trust users have in the overall certificate database.
I almost forgot.  Those who are anxious for these root certificates, who already trust them, and who have no patience with the Mozilla process for scrutinizing certificate authorities can download and install the root certificates themselves.  The links are at <http://www.mozilla.org/projects/security/certs/pending/#ipsCA>.  

When downloaded, open the Certificate Manager at the "Authorities" tab and select the Import button.  On SeaMonkey, the Certificate Manager is reached from the menu bar via [Edit > Preferences > Privacy & Security > Certificates].  Since I don't use Firefox, I don't know the path.
At OSU, we will be undertaking other alternatives to the ipSCA certs for the time being. We believe this process is necessary and worth the time consumed.
Hi, sorry for the "annoying" questions, but is still there any missing information from IPSCA?
Is it possible to know an estimate date when the cert will be considered trusted?

I'm not putting pressure, it's just to know if we are more likely talking about weeks, months or year, as stated before.
Thanks!
See my comment 13 and comment 16. Realistically this process has always taken something between 9 - 12 month. If there are problems it might take even longer than that and according to attachment 413219 [details] , a new audit statement will have to be provided by ipsCA first. Hope this helps!
As far as I can tell, this bug is still waiting (after 3 months) for ipsCA's response to Kathleen's Initial Information Gathering Document. As Eddy notes, they have had other issues to deal with meanwhile. But any delay here is not the responsibility of Mozilla.

If anyone has been sold an ipsCA certificate on the expectation that it would work in all popular browsers, they need to take that up with ipsCA.

Gerv
I just emailed IPS to ask when this would be taken care of.  Their response was:

Dear customer

Our technicians are gathering all the information required by Mozilla. Everything will be sent soon.

Best Regards
ipsCA support
I am an instructor at a US educational institution that uses ipsCA certificates.  The failure to resolve this issue is driving students away from Firefox.  Out here in userland, most people don't care if ipsCA is at fault or if Mozilla is at fault.  They simply want a product that works.

Getting this fixed in a release of Firefox that is available for download before fall semester starts is something that really needs to happen.
Regarding comment #29, you are free to download and install the root certificates yourself as cited in comment #21.  Note that central maintenance of work stations in LANs and WANs -- such as might be practiced at your institution -- might allow for a central installation of the ipsCA root certificates in the workstations there without requiring each user to do it individually.  If you don't trust ipsCA sufficiently for you to install its certificates now, then why would you think the Mozilla organization has more trust in ipsCA?
Regarding comment #30.  I think there is a fundamental misunderstanding of the message in comment #29.

If product market share does not matter then disregard rest.

My story is far from unique as I have found out while researching the issue:  The tech support department at the university where I am an instructor has been a heavy recommender of Firefox to students who have had problems accessing university online resources (including online classes.)  This changed in January of this year as the difficulties associated with Firefox due to the lack of ipsCA support made it more work than alternatives.  University tech support folks generally go for the low hanging fruit.  They could care less about the issues behind the scenes.

In researching this issue I have found ipsCA offers certificates to educational institutions for free.  Further research seems to indicate they have a sizable market share with educational institutions.  As I found evidence that educational institutions were using ipsCA, I wrote down the size of the student bodies.  I stopped when the number went over one million.  ipsCA appears to be a major player in an area where Firefox likely gains significant market share...or looses market share given bad decisions.

Further research and testing shows that Chrome does support the new ipsCA certificates and it appears to have matured enough for me to switch which browser I recommend to my students.  I'll be working on my syllabi for fall over the next couple of weeks.  Which browser will I recommend?  It is really up to whether this issue is fixed.

Over the years I've been a big fan and supporter of Firefox.  I'm at a decision point.  Help me to help you.

Is the point now clear?
I also agree with Nicky.  We are at a crucial decision point where we are deploying computer images to classrooms and labs and we need to know whether or not our web-based applications will be supported when the Fall semester begins.  We also have trumpeted Firefox and open source software, but we are at a point where we cannot continue to recommend Firefox to our faculty, staff, and students when they will not support the technologies on which we rely.  Must we really spend untold amounts of money on Verisign certificates just so that the browser will not throw a confusing error, or shall we make a seamless transition to Chrome that fully supports our deployed environments?
Really your choice should not be about which browser to use for your applications, but rather which certificates to use.  ipsCA has shown that the trust you should place in them isn't much better than self signed certs.  I mean they continued to issue certs after their CA was expired.  If that's all the more trust you need for your applications then I wouldn't bother to worry about the annoyance you're giving your users.  Might as well set up your own CA, distribute the cert to your lab machines, and deal with it that way.  

If you need something more, then you should go out and get some real certs.  digicert [1] has wildcard certs for ~$500.  That's quite reasonable, they're well trusted, work in just about every client app I've tried (minus eudora :P), and can be managed fairly easily since typically one will work for a number of services.

I for one am much happier in the mozilla folks taking their time to diligently check the purported security that a particular CA offers before my browser magically trusts them.

[1] http://www.digicert.com/wildcard-ssl-certificates.htm
As far as I can tell, there is no reason ipsCA should not be considered trustworthy.  All I see is that they made a mistake in delaying when they notified browser vendors of a new root CA.  I'm nearly certain that all new certs issued after their old CA expired were issued using their new CA cert.  However, I also think you've missed the point here.  If an edu uses their own CA, they need to dedicate staff and resources to do that, and still deal with the fact that the cert exists in no browser right now.  A number of people have pointed out central deployment of root CAs in browsers, but are you going to manage every student's personal computer as well?  There are even some universities dropping computer labs, so the vast majority of computers are student-owned and not university-managed.  If an edu uses ipsCA, the CA is already installed in at least IE and Chrome, but not Mozilla.  The latter remains more convenient for helpdesks and users.

And lest we forget, ipsCA never did this: http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/.  But did Comodo get removed from Mozilla?  Despite the fact that the incident specifically involved Mozilla?  Did the vetting process prevent that from happening?

No offense, but sometimes I think people need to act less like computers and more like humans that are capable of more than just following precisely written directions and processes.  There are times when an established process no longer fulfills its purpose and does more harm than good, and as far as I can tell this is one of them.  But of course everyone is entitled to their own opinion and choice of browser.
Re 34:

"I'm nearly certain that all new certs issued after their old CA expired were issued using their new CA cert."

I was issued certificates approximately two weeks before IPS SERVERDORES expired.  To say the least, these "free" certificates cost me quite a bit.

The pressure here needs to be put on ipsCA, not Mozilla.  There are costs of doing business as a CA.  It is only due to their negligence that they are not in the Mozilla browser.
(In reply to comment #34)
> And lest we forget, ipsCA never did this:
> http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/.  But did Comodo
> get removed from Mozilla?  Despite the fact that the incident specifically
> involved Mozilla?

Just for your knowledge, neither was ipsCA removed because of this: http://it.slashdot.org/story/09/10/06/2118211/Null-Prefix-SSL-Certificate-For-PayPal-Released (with consequences probably worse than the above)
Re: comment #35: I'm not saying ipsCA isn't at fault, but ultimately between ipsCA and Mozilla, users (and IT staff dealing with the consequences) are the ones that are suffering.  I suppose you could also say that it is due to Microsoft's lack of due diligence that ipsCA _is_ in there.  Unfortunately, at least in our case, time is something that can be spent on the ipsCA problem, but hard cash to buy certs from elsewhere isn't available.  I'm curious though, are we still actually waiting for ipsCA to send their information to Mozilla or is Mozilla in the review process now?  No one from Mozilla or ipsCA seems to have posted an update here in awhile.

Re: comment #36: Thanks for the info, I admit I didn't know about that.  I do feel like the scope is different though; while potentially more serious, it also involves a flaw in browsers (which Mozilla fixed but MS hadn't), while the first can't really be fixed in code.
(In reply to comment #37)
> I'm curious though,
> are we still actually waiting for ipsCA to send their information to Mozilla or
> is Mozilla in the review process now?  No one from Mozilla or ipsCA seems to
> have posted an update here in awhile.

I believe the last comment with relevance was comment 3. According to https://wiki.mozilla.org/CA:How_to_apply#Timeline there is still some work to do.
The way I understand the issue, Firefox needs to trust the CA before they can pass that trust on.  Err on the side of making sure the trust is well placed.

The bigger 'problem' is the nature of cert use.  There are really 2 reasons to use a cert.  One is to truly trust the source page, the other is to encrypt traffic on the wire.  In a perfect world, the customer would know the difference--but we don't live in a perfect world.  If I tell a casual user they can do their banking as long as the padlock in the browser is OK and the url says https--I'd better know *not just hope* that the browser did its homework in putting the cert in the trust path.  Am I ready to suggest banking over chrome?  Probably not.  Firefox?  Yes.  IE--that's an entirely different set of questions :-)

If I'm running a bank with a few dozen certs, $500/cert is nothing.  If I'm running a small computer science dept with a dozen production servers and 2 dozen test servers that all need certs I have a different business case.  I may need to tell my users to go past an extra page of verification or (ugh!) use a browser that I don't trust to go to the bank with.  Nothing against chrome--it just lives in a different world (assuming the statement made about chrome was correct--I didn't check it out myself).
In order to proceed with this request as per 
https://wiki.mozilla.org/CA:How_to_apply 
a representative of ipsCA must respond to the attached Initial Information Gathering Document as per Comment 2 and Comment 3.

This request is still in the "Information Gathering and Verification" phase. 
See https://wiki.mozilla.org/CA:How_to_apply#Timeline
Firefox, it has been good knowing you, but comment 40 makes it clear that I must move on.  I've been testing Chrome since the initial reply to my initial comment on this thread.  Chrome has matured to the point that it meets my needs.  I'll also be changing the browser I recommend to my students.

All major browsers, including IE8, Chrome, and Safari, have current ipsCA support, with the exception of Firefox.  If Firefox was in a monopoly position in the market, it might be a situation where this attitude could work.  This isn't the case.  Most market share data I have looked at shows Firefox market share peaking late last year.  I'll forecast that the second half of 2010 is not good to the market share of Firefox.  However, I'm moving on to Chrome I no longer care.  Hasta la vista.
Some interesting observations:

Microsoft is currently the only software vendor supporting these roots. Chrome, Safari and IE work on Windows platforms because they make use of the native certificates store. No other platform or browser works besides that at the moment.

Safari and Chrome use native libraries on the respective platforms for the moment. E.g. Mozilla NSS on Linux and Apple Keychain on MAC OSX. Firefox and Opera use their own certificate store.

As to market share, competition is great! But CA roots are a matter of declared policies and not a drive for market share. So long...
Just to add some clarification to comment 42: Safari and Chrome only accept ipsCA certificates when running in Windows because they use the native certificate store in Windows that IE8 uses. Don't expect them to work on Safari or Chrome for Mac OS X or Linux because it won't! By way if you are teaching in higher ed and your school is somewhat typical like ours, your students will be overwhelmingly coming with Macs to the classroom this fall semester.

You truly get what you pay for (free in .edu's case): it is IMHO extremely unethical that ipsCA issued certificates that expire AFTER their root CA's expiration! Mind you they've had 11 YEARS to avoid this problem and instead waited until 9/7/2009 to just begin to solve it!  We are now half a year into Mozilla's vetting process and they still have not responded to the INITIAL information gathering! Is it really worth keeping them as your SSL certificate issuer when you can get a wild card certificate for just over $200 and it will cover an *unlimited* number of websites and not student will have an issue?

For a more permanent solution, ask your school's IT department to seriously consider setting up a trusted root signed CA internally or use a 3rd party SSL managed service so you can issue your own certificates that are accepted everywhere. If you have large numbers of certificates it is a lot more cost effective and easier to manage in the long run.
Overwhelming numbers of mac users? On what planet? What are you, a film school?

Furthermore, why can't firefox have an option to use the OS's built-in certificate store?
On planet earth actually, what planet do you hail from?  I don't understand it either: we are a laptop university and we give our students a choice between several models of PC laptops and Mac laptops.  Since we've started offering Macs as an option 3 years ago, students have opted for on more and more.  This year well over 70% of the incoming class has chosen a Mac, and that's after the extra fee for choosing a more expensive Mac!

Using the built-in certificate store of the OS makes the browser less portable to different operating systems.  Also the info. security officer in my also would like to point out that it also makes the browser more vulnerable to security issues that are specific to an operating system.  I suppose that's why, from a design standpoint, Mozilla and Opera picked to do it this way.  Probably one of the many reasons why you can easily port Firefox to just about any operating system whereas that process is not so easy with Chrome (both being open source).  You can even get Firefox for AmigaOS now :-)!
Is that only considering students that buy from your program?  I know that the large majority of students here (at JHU) do not buy from the university laptop purchase program and opt to purchase on their own, but it's possible that Mac buyers are more likely to use the program than PC buyers.
Folks, this stopped being bug-relevant a while ago.
any chance this could be sorted ?? we use ff & ipsCA certificates - but most of our users have now opted for ie8 !! -
padraig,

This has already been discussed here and the problem lies with ipsCA.  They still have not provided the required information to continue with the next step.  So, the correct group to ask is ipsCA and not Mozilla.
Closing this bug because it has been over a year since the CA has provided input (see Comment #2 and Comment #40). If the CA wishes to proceed, they may create a new bug and provide all of the information listed here: 
https://wiki.mozilla.org/CA:Information_checklist
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
I contacted ipsCA support today and thought I would post their response. It looks like there is not much hope of getting this resolved any time soon.


Submitted by RGU Tue 07 Feb 2012 - 17:31:36
Dear customer,

Currently, our root CA is recognized in Internet Explorer and all browsers which use Windows certificate store in Windows plattforms, i.e, Google Chrome or Apple Safari. Regarding Firefox, we are in process for being included within Firefox browser.

As a temp solution, you can add a code within your web page in order to enable your customer to install themselves our trust chain manually. We are including a code sample.

This is the link to install manually the CA root:
http://certs.ipsca.com/store/ipsCAGlobal.crt

Thanks for trusting ipsCA
ipsCA support



Where in the timeline is ipsCA in getting the ipsCA root certs included in Firefox? What steps still need to be completed?

Is it within a month, 6 months, 1 year? It seems this issue has existed since December 2009. I don't mean to be skeptical, but I am, as to if this issue will ever get resolved.

Thanks
Jared 



Submitted by SAL Tue 07 Feb 2012 - 19:04:30
Dear Customer

We continue working in the process of inclusion. We do not have an exact time, but it will take several more months.

Best Regards and Thanks for Trusting ipsCA
ipsCA Support
http://certs.ipsca.com
> Where in the timeline is ipsCA in getting the ipsCA root certs included in
> Firefox? What steps still need to be completed?
> 
> Is it within a month, 6 months, 1 year? It seems this issue has existed
> since December 2009. I don't mean to be skeptical, but I am, as to if this
> issue will ever get resolved.


A representative of the CA would need to either re-open this bug and provide the requested information, or create a new bug before this request would even get into the queue for public discussion (which in itself takes a long time).

https://wiki.mozilla.org/CA
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: