Closed Bug 581901 Opened 14 years ago Closed 13 years ago

Add HARICA root certificate

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 FIXED

People

(Reporter: jimmy, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: Included in FF 11)

Attachments

(7 files, 7 obsolete files)

HARICA PKI Hierarchy
45.97 KB, image/png
Details
Initial Information Gathering Document
113.72 KB, application/pdf
Details
Reply to initial Information Gathering
185.49 KB, application/pdf
Details
Updated Information Gathering Document
109.11 KB, application/pdf
Details
Reply to Updated Information Gathering Document
148.93 KB, application/pdf
Details
Representative list of elegible domain names for HARICA
26.50 KB, application/octet-stream
Details
Completed Information Gathering Document
105.60 KB, application/pdf
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 (.NET CLR 3.5.30729) Build Identifier: * Product: mozilla.org * Component: CA Certificates * Version: Other * Severity: enhancement * Platform: All * OS: All * Summary: Add Hellenic Academic and Research Institutions Certification Authority (HARICA) root certificate * Description: CA Details ---------- CA Company/Organization Name: Hellenic Academic and Research Institutions Certification Authority / Greek Universities Network Website: http://www.harica.gr/ The Hellenic Academic and Research Institutions Certification Authority (HARICA) is a non profit activity operated by the Greek Universities Network (www.gunet.gr). Our main web site is www.harica.gr and has been operating since 2006. All of our certificates have a clear mark indicating that "This certificate is subject to Greek laws and our CPS. This Certificate must only be used for academic, research or educational purposes". This is also included in the comments and policy fields of each certificate. The main goal of HARICA is the deployment of an infrastructure for secure communication between the collaborating members of the Greek Academic and Research Institutions. The HARICA PKI : * Implements a Public Key Hierarchy having as root authority the HARICA Root Certification Authority, which collaborates with the other parties' Certification Authorities in Greece and abroad aiming to widening the network of trust. * Issues -on behalf of its members- digital certificates for servers, in order to secure the data exchanged with the network users. * Issues -on behalf of its members- digital certificates for users, which can be used to prove their identity when accessing network services, to secure e-mail communication and to sign documents/code/etc. Currently the subordinate CAs are the following: * HaricaAdministrationCAR2 * HaricaEKTCAR2 * HaricaTeiCreteCAR2 * HaricaTeiEpirusCAR2 * HaricaTeiKalamataCAR2 * HaricaTeiLamiaCAR2 * HaricaTeiLarissaCAR2 * HaricaTeiMessolonghiCAR2 * HaricaTeiSerresCAR2 * HaricaUcgCAR2 * HaricaUocCAR2 * HaricaUopCAR2 * HaricaUthCAR2 * AuthCentralCAR2 * AuthNocCAR3 * AuthUsersCAR3 * AuthServersCAR3 Currently, we haven't audited our Certification Authority. However, we have an offer from a Greek Auditors Company which includes 1 CISSP and 2 CISA certified auditors. Some of their previous work includes auditing other Government sectors and major IT companies. We are planning to do an audit as soon as possible. Certificate Details ------------------- Certificate Name: Hellenic Academic and Research Institutions RootCA 2006 The root certificate authority is used to sign only subordinate certification authority certificates. No end user or server certificates will be issued by this CA. Currently there are 13 subordinate CAs operated internally by HARICA Administration: * HaricaAdministrationCAR2 * HaricaEKTCAR2 * HaricaTeiCreteCAR2 * HaricaTeiEpirusCAR2 * HaricaTeiKalamataCAR2 * HaricaTeiLamiaCAR2 * HaricaTeiLarissaCAR2 * HaricaTeiMessolonghiCAR2 * HaricaTeiSerresCAR2 * HaricaUcgCAR2 * HaricaUocCAR2 * HaricaUopCAR2 * HaricaUthCAR2 All these CAs belong to different Academic or Research Institutions and are used to issue both user and server certificates. The following CAs are operated by Aristotle University of Thessaloniki Network Operations Center: * AuthCentralCAR2 * AuthNocCAR3 * AuthUsersCAR3 * AuthServersCAR3 The AuthCentralCAR2 CA is used only to issue subordinate CAs. The AuthNocCAR3 CA is used to issue user and server certificates for the needs of the Network Operations Center of the University. AuthUsersCAR3 and AuthServersCAR3 are used to issue user and server certificates respectively for the rest of the University. Attached you can find a PNG image of the HARICA PKI hierarchy. Certificate HTTP download URL (on CA website): http://www.harica.gr/certs/HaricaRootCA2006.pem (PEM format) http://www.harica.gr/certs/HaricaRootCA2006.der (DER format) Version: Version 3 SHA1 Fingerprint: EF:BE:64:58:33:41:8D:95:82:21:4F:35:00:C2:3B:A6:62:C6:25:77 Public key length (for RSA, modulus length) in bits: 2048 bit Valid From (YYYY-MM-DD): 2006-07-25 Valid To (YYYY-MM-DD): 2026-07-20 CRL HTTP URL: http://crlv1.harica.gr/HaricaRootCA2006/crlv1.der.crl CRL issuing frequency for end-entity certificates: 1 month OCSP URL: http://ocsp.harica.gr Class (domain-validated, identity/organisationally-validated or EV): identity/organisationally-validated EV policy OID(s) (if applicable): not applicable Certificate Policy URL: http://www.harica.gr/documents/CPS.php (Greek), http://www.harica.gr/documents/CPS-en.php (English) CPS URL: http://www.harica.gr/documents/CPS.php (Greek), http://www.harica.gr/documents/CPS-en.php (English) List one or more Trust Bits to enable, choices are Websites (SSL/TLS), Email (S/MIME), and/or Code (code/document signing): Websites, Email and Code URL of website whose SSL certificate chains to this root (if applying for SSL): https://www.harica.gr/ CA Contact Information: Dimitris Zacharopoulos (jimmy at ccf.auth.gr), Panagiotis Tzounakis (pj at ccf.auth.gr), Fotis Loukos (fotisl at ccf.auth.gr) CA Email Alias: ca-admin@harica.gr CA Phone Number: +30-2310998483, +30-2310998438 Title/Department: AUTH Network Operations Center, Harica Administration Reproducible: Always
Attached image HARICA PKI Hierarchy —
Accepting this bug. I will start the Information Gathering and Verification phase as per https://wiki.mozilla.org/CA:How_to_apply.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: Information incomplete
The attached document summarizes the information that has been gathered and verified. The items highlighted in yellow indicate where further information or clarification is needed. Please review the full document for accuracy and completeness.
Our next generation Root CA can be downloaded in the following versions: http://www.harica.gr/certs/HaricaRootCA2010.pem http://www.harica.gr/certs/HaricaRootCA2010.der http://www.harica.gr/certs/HaricaRootCA2010.txt It will eventually have the same hierarchy as the current MD5 root, and similar CRL and OCSP support. Our next version of CP/CPS will incorporate the changes mentioned in this document.
After reviewing the list of Potentially Problematic Practices (http://wiki.mozilla.org/CA:Problematic_Practices), here is the completed list: - Long-lived DV certificates End certificates (for hosts and users) have a 2-year maximum validity period. Furthermore, since there is a limit on the allowed domains (only academic and research institutions in Greece can participate in HARICA), it is rather impossible for the domain ownership to change. - Wildcard DV SSL certificates HARICA doesn't allow the creation of wildcard certificates. - Email Address Prefixes for DV Certs In order to request an SSL certificate the user must own an S/MIME one in order to be authenticated. The e-mail address prefix is not used. - Delegation of Domain / Email validation to third parties The main RA and CA is run by the HARICA Administration Team. In case an institution -within the HARICA constituency- wants to run its own RA, it must provide an official audit according to the mozilla CA requirements. - Issuing end entity certificates directly from roots HARICA ROOT CA is used only to issue SubCA certificates. - Allowing external entities to operate subordinate CAs As in the case of an external RA, an institution -within the HARICA constituency- that wants to run its own CA must provide an official audit according to the mozilla CA requirements. - Distributing generated private keys in PKCS#12 files The CP/CPS discoureges key-pair generation on behalf of users and strongly advises only end user to be able to generate private keys. Section 6.1.2 of our CP/CPS mentions that there might be cases for batch key generation under a very strict procedure. - Certificates referencing hostnames or private IP addresses Host certificates are only allowed to have FQDNs. Hostnames or IP addresses are not allowed. This is described in section 3.1.1.2. Our next CP/CPS revision will specifically mention that hostsnames or private IP Addresses are not allowed. - Issuing SSL Certificates for Internal Domains Use of internal domains is not allowed. Only internet domains belonging to HARICA academic institutions are allowed. - OCSP Responses signed by a certificate under a different root The OCSP responses are signed by the certificate of the Harica Administration SubCA, which is in turn signed by the Harica Root CA. - CRL with critical CIDP Extension CRLs don't have a critical CIDP extension. - Generic names for CAs The names of the CAs are very specific. For example: 'Hellenic Academic and Research Institutions AdminCA R2', 'University of Central Greece CA R2' etc. - Lack of Communication With End Users Harica Administration uses e-mail and telephone support for end-users. Telephone support works 8 hours/day, working days. Furthermore, specific institutions, such as the Aristotle University of Thessaloniki, provide helpdesk visiting facilities for end users and on-site support at faculty members offices/computers.
Thank you for the information. Please post a comment in this bug when the CP/CPS has been updated.
This request has been added to the queue for public discussion: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion Now that you have a request in the Queue for Public Discussion, you are directly impacted by the time it takes to work through the queue. The goal is to have each discussion take about one to two weeks. However, that time varies dramatically depending on the number of reviewers contributing to the discussion, and the types of concerns that are raised. If no one reviews and contributes to a discussion, then a request may be in the discussion for several weeks. When there are not enough people contributing to the discussions ahead of yours, then your request will sit in the queue longer. How can you help reduce the time that your request sits in the queue? You can help by reviewing and providing your feedback in the public discussions of root inclusion requests, or by asking a knowledgeable colleague to do so. Participating in other discussions is a great way to learn the expectations and be prepared for the discussion of your request. Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
Whiteboard: Information incomplete → Information confirmed complete
We have completed our Audit according to the ETSI TS 101 456 standard. It is available at http://www.harica.gr/documents/Harica.Audit-report.2011.03.18.Rev1.2.ENG.pdf or at an independent location (http://www.trust-it.gr/userfiles/Harica.2011.03.18.Rev1.2.ENG.pdf). Our CP/CPS has also been modified and is currently in version 2.2 (http://www.harica.gr/documents/CPS-EN.pdf).
Thanks for the update. Has CRL and OCSP support been implemented for the new root?
Thank you for the fast processing. The currently used URLs (ocsp.harica.gr, crlv1.harica.gr) are serving the currently used MD5 root. We plan to enable www2.harica.gr under the new root and its new subCA for testing. It will point to a new CRL link (the URL crlv1.harica.gr will remain the same). The OCSP is a bit more tricky if we want the same URL to serve under two different ROOT CAs. Switching the OCSP to the new root only, is trivial. Is it necessary to implement ocsp support for the new root before the public discussion? We also noticed that the audit statements at http://www.mozilla.org/projects/security/certs/pending/#HARICA (although marked as completed) are unlinked and still TBD. Best regards.
We have enabled OCSP support for https://www2.harica.gr under the new SHA1 ROOT CA. Best regards, Dimitris Zacharopoulos.
Attachment #484410 - Attachment is obsolete: true
There are some changes to the audit report that reflect minor changes of our CP/CPS (mostly changed couple of "should" to "must" in the translated document). The latest audit report is available at the following URLs: - http://www.harica.gr/documents/HARICA.Audit.Report.EN.pdf - http://www.trust-it.gr/userfiles/Harica.2011.03.18.Rev1.2.ENG.pdf Our CP/CPS has also been modified and is currently in version 2.3 (http://www.harica.gr/documents/CPS-EN.pdf). This comment obsoletes comment #10.
Attachment #530664 - Attachment is obsolete: true
We would like to inform you that the sub CAs operated for Aristotle University of Thessaloniki (http://www.pki.auth.gr), have completed a separate audit from an independent auditor according to the ETSI TS 101 456 standard. The report is available at http://www.pki.auth.gr/documents/AUTH.Audit.Report.EN.pdf and at an independent location (http://www.trust-it.gr/userfiles/AUTH.2011.03.18.Rev1.7.English.pdf). AUTH's CP/CPS has also been modified and is currently in version 3.1 (http://www.pki.auth.gr/documents/CPS.pdf.en).
Attachment #541694 - Attachment is obsolete: true
This request is next in line for public discussion: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion I will post a comment in this bug when I start the discussion -- hopefully the week of September 6.
We recently discovered that our proposed ROOT CA had a problem with the AuthorityKeyIdentifier extension and the certificate policy OID which is now fixed. Our next generation Root CA can be downloaded in the following versions: http://www.harica.gr/certs/HaricaRootCA2011.pem http://www.harica.gr/certs/HaricaRootCA2011.der http://www.harica.gr/certs/HaricaRootCA2011.txt Fingerprints: SHA1 is B2:49:E1:BE:68:B9:00:44:22:A5:4D:EA:A3:82:A9:19:BC:0A:5B:47 and MD5 is F6:DB:22:B0:75:19:53:F6:C7:C8:34:F1:B6:39:3B:1D. It will eventually have the same hierarchy as the current MD5 root, and similar CRL and OCSP support. The test certificate under https://www2.harica.gr is also replaced by the new hierarchy and is OCSP ready. Finally, we must inform you that the transition from the "Hellenic Academic and Research Institutions RootCA 2010" root cert to the new cert, has no impact on existing certificates (since no certificates were issued to end users/servers), produces no updates on our CP/CPS and has no effect on our recent Audit.
Attachment #555456 - Attachment is obsolete: true
We have included answers to the latest communication to the CAs with root certificates in NSS. Please read below. == Dear Certification Authority, [...] Please confirm completion of the following actions or state when these actions will be completed, and provide the requested information no later than September 16, 2011: 1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs. ** HARICA has recently (Apr 2011) passed a security audit at the same time as the ETSI TS 101 456 audit. 2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included ** HARICA does not allow cross-signed certificates 3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance. ** We confirm multi-factor authentication for server certificates, and multi-factor authentication to access the RA and CA engines. 4) Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks this year). Please further confirm your process for manually verifying such requests, when blocked. ** HARICA has implemented technical restrictions (at the RA and CA level) allowing only specific domains affiliated with our constituency to be included in certificates. Each server certificate is manually verified. 5) For each external third party (CAs and RAs) that issues certificates or can directly cause the issuance of certificates within the hierarchy of the root certificate(s) that you have included in Mozilla products, either: a) Implement technical controls to restrict issuance to a specific set of domain names which you have confirmed that the third party has registered or has been authorized to act for (e.g. RFC5280 x509 dNSName name constraints, marked critical) ** HARICA has implemented technical controls to restrict issuance to a specific set of domain names which have been confirmed. These controls check the dNSName, E-mail and the CN of the certificate requests. OR b) Send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the subordinate CA's internal operations. Each action requested above applies both to your root and to these third parties. Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your participation in this pursuit. Regards, Kathleen Wilson Module Owner of Mozilla's CA Certificates Module
Attachment #557668 - Attachment is obsolete: true
(In reply to Kathleen Wilson from comment #23) > Created attachment 561318 [details] > Completed Information Gathering Document Dimitris, Please confirm that the information in this document is current and correct. If there are any errors, or anything is out of date, please post correction.
Also, when I try to browse to https://www2.harica.gr I get Error code: sec_error_ocsp_try_server_later
We needed to reload the OCSP daemon after an upgrade which took place last week. Our production site https://www.harica.gr was ok. https://www2.harica.gr is now ok as well. We also added extra monitoring code to warn us in case the service fails for https://www2.harica.gr Thank you for the notification. I also confirm that the information in the Gathering Document is current and correct. Just one small correction for the CP/CPS URL for AUTH-PKI. The direct link is http://www.pki.auth.gr/documents/CPS-EN.pdf. The current link automatically detects the browser language and presents the greek/english version accordingly. Best regards, Dimitris Zacharopoulos.
Attachment #561318 - Attachment is obsolete: true
I am now opening the first public discussion period for this request from HARICA to add the “Hellenic Academic and Research Institutions RootCA 2011” root certificate, and enable all three trust bits. For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list. http://www.mozilla.org/community/developer-forums.html https://lists.mozilla.org/listinfo/dev-security-policy news://news.mozilla.org/mozilla.dev.security.policy The discussion thread is called “HARICA Root Inclusion Request” Please actively review, respond, and contribute to the discussion. A representative of HARICA must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In public discussion
This is a representative list of eligible domain names of Greek Academic and Research institutions under HARICA. This list is not comprehensive because each of these institutions may have other affiliated sub-divisions under the same legal entity with different domain names.
HARICA has now implemented the name constraints extension as discussed in the m.d.s mailing list. The next generation Root CA can be downloaded in the following versions: http://www.harica.gr/certs/HaricaRootCA2011.pem http://www.harica.gr/certs/HaricaRootCA2011.der http://www.harica.gr/certs/HaricaRootCA2011.txt Fingerprints: SHA1 is 41:CB:5B:99:D6:EC:E6:8C:29:70:95:EB:5D:9C:89:EC:6C:80:93:32 and MD5 is 14:99:76:B4:34:BC:58:D7:34:02:8F:B6:AD:2F:E6:5F. It will eventually have the same hierarchy as the current MD5 root, and similar CRL and OCSP support. The test certificate under https://www2.harica.gr is also replaced by the new hierarchy with the name constraints and is OCSP ready. The updated CP/CPS is available at https://www.harica.gr/documents/CPS-EN.pdf and the name constraints section is 7.1.5.
This post obsoletes Comment #30. HARICA has now implemented the name constraints extension without the critical bit as discussed in the m.d.s mailing list. The next generation Root CA can be downloaded in the following versions: http://www.harica.gr/certs/HaricaRootCA2011.pem http://www.harica.gr/certs/HaricaRootCA2011.der http://www.harica.gr/certs/HaricaRootCA2011.txt Fingerprints: SHA1 is fe:45:65:9b:79:03:5b:98:a1:61:b5:51:2e:ac:da:58:09:48:22:4d and MD5 is 73:9f:4c:4b:73:5b:79:e9:fa:ba:1c:ef:6e:cb:d5:c9. It will eventually have the same hierarchy as the current MD5 root, and similar CRL and OCSP support. The test certificate under https://www2.harica.gr is also replaced by the new hierarchy with the name constraints and is OCSP ready. The updated CP/CPS (version 2.5) is available at http://www.harica.gr/documents/CPS-EN.pdf and the name constraints section is 7.1.5.
Attachment #569483 - Attachment is obsolete: true
The public comment period for this request is now over. This request has been evaluated as per Mozilla’s CA Certificate Policy at http://www.mozilla.org/projects/security/certs/policy/ Here follows a summary of the assessment. If anyone sees any factual errors, please point them out. To summarize, this assessment is for the request to add the “Hellenic Academic and Research Institutions RootCA 2011” root certificate and turn on all three trust bits. Section 4 [Technical]. I am not aware of instances where HARICA 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]. HARICA appears to provide a service relevant to Mozilla users: It is a non-profit organization with the goal of deploying an infrastructure for secure communication between the collaborating members of the Greek Academic and Research Institutions. Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main document of interest is the CPS. The documents are provided in English. Document Repository: http://www.harica.gr/procedures.php CPS: http://www.harica.gr/documents/CPS-EN.pdf Section 7 [Validation]. HARICA appears to meet the minimum requirements for subscriber verification, as follows: * SSL: According to CPA section 7.1.5, name constraints are required for all subCAs, so that each subCA will be constrained to the Institution’s domain name that the subCA signs for. According to CPS section 3.2.3.2, issuance of an SSL/TLS certificate is only allowed for domains belonging to each institution. Additionally, verification e-mail is sent to an institution's network operations center designated administrator who verifies the validity of the FQDN of the certificate request and checks that the person who applied for the certificate is the rightful owner of the FQDN according to the institution's database of users and servers. * Email: According to CPS section 3.2.3.1, HARICA uses two methods for e-mail ownership and control verification. In the first method, a verification e-mail is sent to the user with a link to a unique web page. After following this link, an e-mail is sent to the institution's network operation center mail administrator that requires an approval based on the full name entered by the user and the user's email. This approval requires the identification of the user with his/her physical presence and an acceptable official document. The second method uses an LDAP server. The user enters the personal e-mail address at the initial certificate request form and the corresponding password. This information is verified against the institution's LDAP server. If the verification is successful, the RA queries the real name of the user and creates the certificate request. In order for a user to be listed in the Institutional Directory server, the institution must have verified the user with his/her physical presence and an acceptable official photo-id document. * Code: According to CPS sections 3.2.2 and 3.2.3 the identity and authority of the certificate subscriber are checked by performing physical identity verification, ensuring the subscriber is registered in the official directory services of the Institution, and confirming the request with the administration of the Institution. Section 15 [Certificate Hierarchy]. This new root will eventually have the same intermediate CAs as HARICA’s MD5 root; the CA hierarchy diagram is here: https://bugzilla.mozilla.org/attachment.cgi?id=460450 * The hierarchy that will be transitioned to this root currently consists of several internally-operated subordinate CAs and one externally-operated subordinate CA. Each subordinate CA is used for a different academic or research institution. ** HARICA has implemented technical restrictions (at the RA and CA level) allowing only specific domains affiliated with their constituency to be included in certificates. ** HARICA provided the CPS and audit statement for the externally-operated subCA. * Both CRL and OCSP are provided under this root ** CPS section 4.9.7: The CRL must be updated and published at least every five (5) days. Section 8-10 [Audit]. Annual audits are performed according to the ETSI TS 101 456 criteria. The most recent audit was performed by Deventum (http://deventum.com), and posted on the Trust-IT website: http://www.trust-it.gr/userfiles/Harica.2011.03.18.Rev1.2.ENG.pdf ** Note that this new root was created after the last audit, and will need to be included in the next audit. ** A network security audit was performed at the same time as the ETSI audit. Based on this assessment I intend to approve this request to add the “Hellenic Academic and Research Institutions RootCA 2011” root certificate and turn on all three trust bits.
Whiteboard: In public discussion → Pending Approval
To the representatives of HARICA: Thank you for your cooperation and your patience. To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request. As per the summary in Comment #33, and on behalf of Mozilla I approve this request from HARICA to include the following root certificate in Mozilla products: * Hellenic Academic and Research Institutions RootCA 2011 (websites, email, code) I will file the NSS bug for the actual changes.
Whiteboard: Pending Approval → Approved - awaiting NSS
Depends on: 711594
I have filed bug #711594 for the actual changes in NSS.
The "Hellenic Academic and Research Institutions RootCA 2011" root certificate is a Builtin Object Token in FF 11.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS → Included in FF 11
The recent audit statement is also available from the Trust-IT website: http://www.trust-it.gr/UserFiles/HARICA-2012.04.20.Audit.pdf
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: