Closed Bug 622589 Opened 14 years ago Closed 13 years ago

EV Violations cited by SSL Observatory

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: kathleen.a.wilson, Assigned: kathleen.a.wilson)

Details

Copied from Rob's posting in CABForum:

Peter Eckersley and Jesse Burns of the EFF's SSL Observatory project presented
some updated findings a couple of days ago.  Here are their slides:

http://events.ccc.de/congress/2010/Fahrplan/attachments/1777_is-the-SSLiverse-
a-safe-place%3F.pdf

Slide 36 onwards discusses EV.  Look in particular at Slide 42 onwards.

They found...

 - 2 Wildcard EV Certificates, issued by Cybertrust.  (Wildcard EV
Certificate have never been allowed!)

 - 1 EV Certificate with a 512-bit RSA key, issued by Cybertrust.  (512-bit
RSA keys have never been allowed in EV Certificates!)

 - 127 EV Certificates (issued by 13 of the 38 CAs they found) with 1024-bit
RSA keys that expire after today.  (The minimum RSA key size for EV
Certificates expiring after 31st Dec 2010 is 2048-bit!)

 - 1 EV Certificate containing private IP Addresses, issued by GlobalSign.
(This practice has never been allowed for EV, and apparently this particular
certificate was issued after GlobalSign claimed to have implemented controls
to prevent such certificates from being issued!)
Status: NEW → ASSIGNED
Copied from Johan's response in the mozilla.dev.security.policy forum:

The EV cert with RFC1918 and hostname's is ours, the 512bit EV cert is
not from GlobalSign, but from Cybertrust.

We discussed this issue back in August on
https://bugzilla.mozilla.org/show_bug.cgi?id=586414
however, it seems our corrective action at that time to identify any
affected EV certs was ineffective.  The cert was issued in Feb 2009
and soon after that reissued with correct SAN's but the old cert
remained installed

This is raised to the engineering team  to do a second scan and ensure
that the algorithm used is more effective.

We will report on this later this week.  In the meanwhile, the cert is
revoked.

Johan
Will a representative of the applicable Cybertrust root please respond to the issues stated above?
The Cybertrust certs under question are signed by 

Cybertrust SureServer EV CA

which is signed by: Cybertrust Global Root

and has been cross-signed by: GTE CyberTrust Global Root
The affected parties have been contacted and we are coordinating replacement and revocation.

These issues occurred due to incorrect configuration of the rule sets applied against certificates for these customers.  The rule sets have been modified to prevent wildcard issuance and set a 2048 bit minimum required key size.

We are scanning our EV SSL customer records for any further issues that may not be detectable on servers operated within private networks.  Any additional incidents will be handled with equal priority.

A post mortem will occur to add detail to documentation and reinforce training in the service team that handles EV SSL customers.
The offending wildcard certificate at Accenture has been replaced and revoked.  The remaining matters are actively in progress as our first priority.
The 512 bit certificate has been replaced on the production server at Thomas & Betts and we are close to completing the revocation.  The certificate is no longer operational at this time.

We are working on the XL Group wildcard replacement and revocation, updates will follow as available.
A new scan was done by our engineering team and no other valid EV certificate (not revoked or expired) issued by Globalsign was found that includes internal SANs.

We missed the one noted by EFF in the last round as the cert was re-issued with valid SANs and we didn't include the original certificate (which was installed by the customer) in the scan.
The 512 bit keyed certificate has been revoked.  We continue to actively work the remaining wildcard through replacement and toward revocation.
The other wildcard certificate was replaced by a non-EV certificate that was issued on May 10, 2010.  It has been out of operation since days after that replacement was issued.   The EV wildcard was revoked today.  This closes the three specific certificates discussed for Cybertrust.
It is my opinion that Cybertrust/Verizon has promptly responded to and resolved the issues with the 2 Wildcard EV Certificates and the 1 EV Certificate with a 512-bit RSA key. 

It is also my opinion that GlobalSign has promptly responded to and resolved the issue with the 1 EV Certificate containing private IP Addresses.

While these mistakes were not in identity validation, these are still very unfortunate mistakes. However, due to the prompt response and resolution from the CAs, Mozilla does not plan to take further action on these particular items. 

This bug is still open, because the following item needs to be followed-up on:

- 13 Issuers signed 127 valid, EV certs with 1024 bit RSA keys that expire after Dec 31, 2010.

I will greatly appreciate it if someone will add a comment in this bug to provide the list of these 13 issuers.
(In reply to comment #10)
<snip>
> This bug is still open, because the following item needs to be followed-up on:
> - 13 Issuers signed 127 valid, EV certs with 1024 bit RSA keys that expire
> after Dec 31, 2010.
> 
> I will greatly appreciate it if someone will add a comment in this bug to
> provide the list of these 13 issuers.

I count 178 certs from 15 Issuers:

Count  |  Issuer Name
=========================
   63  |  C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL SGC CA
   32  |  C=US, O=SecureTrust Corporation, CN=SecureTrust CA
   20  |  C=NL, O=DigiNotar, CN=DigiNotar Extended Validation CA/emailAddress=info@diginotar.nl
   17  |  C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL CA
   14  |  O=Cybertrust Inc, CN=Cybertrust SureServer EV CA
   11  |  C=US, O=thawte, Inc., OU=Terms of use at https://www.thawte.com/cps (c)06, CN=thawte Extended Validation SSL CA
    8  |  C=US, O=GeoTrust Inc, OU=See www.geotrust.com/resources/cps (c)06, CN=GeoTrust Extended Validation SSL CA
    4  |  C=US, O=Entrust, Inc., OU=www.entrust.net/rpa is incorporated by reference, OU=(c) 2009 Entrust, Inc., CN=Entrust Certification Authority - L1E
    3  |  C=JP, O=SECOM Trust Systems CO.,LTD., CN=SECOM Passport for Web EV CA
    1  |  C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root
    1  |  C=US, O=Wells Fargo, OU=Wells Fargo Certificate Authorities, CN=Wells Fargo Public Primary Certificate Authority
    1  |  OU=Extended Validation CA, O=GlobalSign, CN=GlobalSign Extended Validation CA
    1  |  O=Cybertrust, Inc, CN=Cybertrust Global Root
    1  |  C=US, O=Entrust, Inc., OU=AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE, OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY, OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Certification Authority - L1A
    1  |  C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance EV CA-1
Version 1.3 of the CA/Browser Forum Guidelines for EV Certs has Appendix A, "Minimum Cryptographic Algorithm and Key Sizes (Normnative)" which says:

“Subscriber Certificates whose validity period ends after 31 Dec 2010...  RSA: 2048”

Representatives of the following CAs, please see Comment #11 in this bug, and search your records to revoke and replace the currently valid end-entity EV certs with RSA key sizes less than 2048 bits.  Please post your expected completion date, progress, and closure directly in this bug.

* VeriSign (VeriSign, Thawte, and GeoTrust)
* Trustwave (SecureTrust)
* DigiNotar 
* Cybertrust/Verizon
* Entrust
* SECOM 
* Wells Fargo
* GlobalSign
* DigiCert

Your prompt response is requested.
Kathleen,

Thanks for the inclusion on this thread.

Here is an update on where we are at with this:

1) Cause - Human error. Up until September 15th 2010 we had an entirely manual (human) process for issuing these certificates. We have since instituted an automated system that will not allow a CSR<2048 through for signing.

2) Remediation - We are contacting all customers and performing reissues at this time. We will also perform a scan over the entire EV customer base to ensure that there is nothing else 'live' out there that the public scanners may not have caught.

3) Communication - We will keep you up to date on our progress as we go through the list.
Cybertrust/Verizon independently counts 16 1024-bit certificates under its Cybertrust SureServer EV CA.  The 16 are controlled by three customers.  

One of the certificates, representing one customer, expires on January 8 and its compliant replacement will be put into operation tonight.  We intend to revoke it tomorrow.

The remaining two affected customers operate 10 and 5 certificates, respectively.  We are coordinating with customers to get the replacements active this week with the revocations to follow.

In the case of these 16 certificates, the group of 5 from one customer were submitted as two year certificate requests when our 2048 bit check was not yet activated (prior to 2010), the group of 10 from one customer were accepted due to account misconfiguration as discussed in the post regarding the 512 bit key above, and the single certificate valid for one year issued on January 8, 2010 was issued just prior to our software enforcement of 2048 bit key size.  This conflicts with and supersedes my comment that our key blocking was enabled in December 2009 in previous comments above.

In addition to software changes that block requests less than 2048 bit, operational guides for our RA team are adapted to require a check of key size and a rejection for non-compliant small keys as a second line defense.  In post mortem to the 512 bit issue, we intend to hold and document a retraining reinforcement regarding the mandatory need to enable small key size blocking below 2048 bit.

I will need additional research time to respond on the 1 certificate from the GTE CyberTrust Global Root and the 1 certificate from the Cybertrust Global Root as these issuers are managed in offline mode and require multiperson access control to activate the PKI associated with them.  I don't have immediate online access to their issuance data.  There will be scheduling effort to enable the offline PKIs for the eventual revocations.
Further to the root issued certificates in the Cybertrust/Verizon scope, it is highly likely that these are intermediate issuing CA certficates.  I can confirm that once we complete our independent research.  

Appendix A of EV Guidelines version 1.3 indicates that for subordinate CAs whose validity period BEGINS on or before December 31, 2010, 1024 bit is the accepted minimum key size.

In the case of end entity subscriber certificates, the language is specifically different and underlined to emphasize that the key size requirements pertain to the date that the validity period ends.

If I document that the one certificate from the GTE CyberTrust Global Root and the one certificate from the Cybertrust Global Root are both subordinate CAs, would Mozilla consider them in compliance with the in force Guidelines?

Note that I interpret the footnote marked ** below table (3) to be interpreted only in the positive sense that an EV SSL certificate can chain to a 1024 bit root.  I do not interpret it to mean that they may not chain to 1024 bit intermediates, which are specifically provided for by table (2) of Appendix A when they are issued prior to the end of 2010.
Entrust had 4 certificates that expired on 31 Dec 2010 Eastern Time. Due to logic on our date rule that did not compensate for GMT, these certs show a 'Valid to' date of 1 Jan 2011. As these certificates have all expired, there is no further action required.

The other certificate issue was detected in May 2010 and was revoked and replaced at that time.
Dear Kathleen-san,

Secom has 2 (not 3) end-entity EV certificates with 1024 bit RSA keys.

We checked all active EV certificates and nothing else with 1024 bit.

We are now contacting both parties to renew the end-entity EV certificates with 2048 bit and hopefully, they will be replaced within a week or so.

The cause is because of the human error to set up the application system.
The applications before December 31, 2009 were allowed to use 1024 bit CSRs.
This is the reason we have the tragegy of 2 end-entity EV certificates with 1024 bit RSA keys.
But the applications after January 1, 2010 are not allowed to use 1024 bit CSRs and nothing else we find of end-entity EV certificates with 1024 bit RSA keys.
Cybertrust/Verizon confirms that the quantity (1) certificates issued directly from both the GTE CyberTrust Global Root and the Cybertrust Global Root are subordinate CAs.

The 15 outstanding EEs are actively being replaced and revoked.
Greetings,
The certificate in question for Wells Fargo is a certificate we issued to our test beacon server.  It has been revoked.  Due to change management requirements we will have to schedule the removal of the certificate from the server which should happen sometime late next week or the following week.  It is however revoked as of today.
(In reply to comment #17)
> Secom has 2 (not 3) end-entity EV certificates with 1024 bit RSA keys.
> 
> We checked all active EV certificates and nothing else with 1024 bit.

Dear Kamo-san,

Please check again -- SSL observatory shows the following three Subject Keys signed by your 96:F1:92:44:E1:49:7B:21:FE:50:6A:3A:61:B7:0C:61:B8:09:D7:34 key.
They all expire within the next 30 days, though, so it's of fairly little operational importance.

--------------
select enddate, ip, fingerprint, path from valid_certs
where issuer like "%Secom%" and rsa_modulus_bits <= 1024
and enddate > date("2010-12-31")
and `ext:X509v3 Authority Key Identifier` is null and
    locate("1.2.392.200091.100.721.1:", `ext:X509v3 Certificate Policies:Policy`)
order by cast(rsa_modulus_bits as decimal)
--------------

+---------------------+----------------+------------------------------------------------------------------------------+--------------------------------------------------------------------+
| enddate             | ip             | fingerprint                                                                  | path                                                               |
+---------------------+----------------+------------------------------------------------------------------------------+--------------------------------------------------------------------+
| 2011-01-31 14:59:59 | 211.8.190.82   | SHA1 Fingerprint=E2:B7:05:F0:F9:28:B3:3B:34:37:4B:1E:0D:DD:D4:09:C5:D9:5C:28 | /ssl-data/sslscanner4/211.x.x.x/211.x.x.82/211.8.190.82.results    |
| 2011-01-09 14:59:59 | 124.38.182.150 | SHA1 Fingerprint=4C:E9:BF:47:A4:F0:65:9C:72:FF:48:1B:96:5A:6A:EE:6A:67:E6:74 | /ssl-data/sslscanner6/124.x.x.x/124.x.x.150/124.38.182.150.results |
| 2011-01-22 14:59:59 | 202.218.13.230 | SHA1 Fingerprint=F4:19:2C:00:E7:9D:E4:63:EC:7F:47:3D:B7:4E:F1:E6:4A:55:7E:1F | /ssl-data/sslscanner8/202.x.x.x/202.x.x.230/202.218.13.230.results |
+---------------------+----------------+------------------------------------------------------------------------------+--------------------------------------------------------------------+
3 rows in set (3 min 51.29 sec)

The .results files:

http://pyron.hexapodia.org/observatory/211.x.x.x/211.x.x.82/211.8.190.82.results
http://pyron.hexapodia.org/observatory/124.x.x.x/124.x.x.150/124.38.182.150.results
http://pyron.hexapodia.org/observatory/202.x.x.x/202.x.x.230/202.218.13.230.results
(In reply to comment #18)
> Cybertrust/Verizon confirms that the quantity (1) certificates issued directly
> from both the GTE CyberTrust Global Root and the Cybertrust Global Root are
> subordinate CAs.

Steve, I'm sorry about those false positives.  I edited my query to better
distinguish between CA and EE certs.  Here are the revised details...

I count 176 certs from 14 Issuers:

Count  |  Issuer Name
=========================
   63  |  C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at
https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL
SGC CA
   32  |  C=US, O=SecureTrust Corporation, CN=SecureTrust CA
   20  |  C=NL, O=DigiNotar, CN=DigiNotar Extended Validation
CA/emailAddress=info@diginotar.nl
   17  |  C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at
https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL
CA
   14  |  O=Cybertrust Inc, CN=Cybertrust SureServer EV CA
   11  |  C=US, O=thawte, Inc., OU=Terms of use at https://www.thawte.com/cps
(c)06, CN=thawte Extended Validation SSL CA
    8  |  C=US, O=GeoTrust Inc, OU=See www.geotrust.com/resources/cps (c)06,
CN=GeoTrust Extended Validation SSL CA
    4  |  C=US, O=Entrust, Inc., OU=www.entrust.net/rpa is incorporated by
reference, OU=(c) 2009 Entrust, Inc., CN=Entrust Certification Authority - L1E
    3  |  C=JP, O=SECOM Trust Systems CO.,LTD., CN=SECOM Passport for Web EV CA
    1  |  C=US, O=Wells Fargo, OU=Wells Fargo Certificate Authorities, CN=Wells
Fargo Public Primary Certificate Authority
    1  |  OU=Extended Validation CA, O=GlobalSign, CN=GlobalSign Extended
Validation CA
    1  |  C=US, O=Entrust, Inc., OU=AND ADDITIONAL TERMS GOVERNING USE AND
RELIANCE, OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY,
OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc.,
CN=Entrust Certification Authority - L1A
    1  |  C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance
EV CA-1
This week GlobalSign has performed a full audit of its certificate database.

The 1024bit EV cert detected in the EFF list, together with two more 1024bit EV certs we detected, are revoked and replaced.  We had since 2009 controls in place against this, but a software bug allowed it through for specific operations (when renewing under certain circumstance the key-size check was not called).  
This bug is identified and fixed on our testing systems.  If testing is successful, it will go live next week.
Next to this, we are adding to our RA interfaces the key size of the CSR and we are training our vetting people to review the keysize before approval.

GlobalSign also discovered 22 non-ev certificates, of which 15 are in the EFF list, with 512bit key-size.  We expect to replace and revoke all of those by next week.
These are certificates issued through our legacy system which does not have key-size check in place.  This control is planned for the near future.  Vetting staff in the meanwhile verify key-size of the CSR.  

These incidents will be reported to our Auditors

Johan
Rob, we greatly appreciate your concerns, participation and contribution to the resolution of these issues.  There is certainly no need to apologize for the great efforts you've brought to this discussion.

On the topic of the intermediate CA certificates, while the EV Guidelines happen to contain language permitting their existence, Mozilla as well as other user agent vendors maintain stricter controls against which these CAs cause us and I am certain Mozilla and the community concern.

I have discussed the subject certificates and reached the decision that we will revoke the intermediate CAs containing 1024-bit keys within the next several business days.  There are presently zero issued EV SSL certificates created by these CAs.  Zero EV SSL connections have ever relied on these issuers.

I will provide an update to this bugzilla when we have posted the CRLs representing their end of life.
Of the remaining 15 1024-bit end entity EV SSL certificates in suspense for Verizon/Cybertrust, the 10 operated by Thomas & Betts have been revoked.

The same incorrectly set rule that permitted a 512 bit key also permitted these 1024-bit keys.  That rule has been adjusted to 2048-bit minimum.  Reinforcing training and documentation covering the issues in this bugzilla will include discussion of the impact of this specific matter.  Our auditors will view evidence of our corrective training at our next audit.

The group of 5 certificates currently have replacement requests in our queue and we have received subscriber agreements for them.  We expect to issue replacements today.  We expect the customer to implement the replacements and signal readiness to revoke within the next 2-3 business days.

We aim to close next Wednesday and will report variance.

Note that in my previous post, I misstated information received from my customer.  The 1024-bit issuing CAs presently have no active certificates.  I was not correct to state that zero certificates were issued.
We have scrubbed our entire Extended Validation installed base across our VeriSign, GeoTrust and Thawte SSL brands.  We have identified a list of certificates with key lengths under 2048 bits.  We’re in the process of contacting all of the owners of these certificates to work with them on quickly replacing with 2048-bit keys.  We are giving these customers a hard deadline by which they must replace their certificates before we revoke them ourselves, although we’re confident that we’ll have a great deal of compliance very quickly.

We have confirmed that we have no active EV certificates assigned to IP addresses nor wildcard EV certificates.  We also have confirmed that it is not possible to order or issue a new EV certificate on any of these brands that fails to meet any of the requirements listed above.
DigiNotar is in the process of identifying the customers who currently have certificates in place with key lengths under 2048 bits. We will contact these customers and replace these certificates as soon as possible.
Verizon/Cybertrust confirms that the two subordinate CAs discussed above were revoked.  The subordinate to the GTE CyberTrust Global Root was revoked on 10 January, and the subordinate to the Cybertrust Global Root was revoked on 11 January.

Our 5 remaining 1024-bit certificates have been replaced and the replacements will be implemented in the customer's networks during planned maintenance this coming weekend.  Given a report of success, the final 5 certificates under our responsibility to correct will be revoked.  Caution being taken is commensurate with the criticality of the application secured by these certificates.

I will provide a final update to close our scope early next week.
Update from Trustwave:

We have reissued 9 of these certificates and if they are not already replacing the old certs they will be very soon. We have 3 still outstanding pending customer action. One has expired and no further action is necessary.

I will provide another update as we get through the last 3.
Would the representatives of the following CAs please provide an update (in this bug) on their status in regards to Comment #12?
* VeriSign (VeriSign, Thawte, and GeoTrust)
* Trustwave (SecureTrust)
* DigiNotar 
* Cybertrust/Verizon
* SECOM 
* GlobalSign

Your prompt response is requested.
Trustwave update:

We have replaced, revoked or expired every cert that has been identified here. (a few that were not identified here as well, but detected as a result of our internal audit)

We are working with the customers to ensure that they are all replaced (there are still 2 waiting on some change windows).
GlobalSign Update:

As per comment 12, the EV certs have been replaced. The controls have been updated and are live.

The other 512bit certs are also replaced.

Johan
Secom update:

As per comment 12, two of them have been already replaced by 2048bit.

We are now waiting 1 certificate to be replaced shortly. 
It should be within a few days.
Verizon/Cybertrust Update:

The remaining 5 certificates have been replaced.  Per customer request, the certificates will be revoked at US EST COB today.  Delay in revocation after replacement results from the caution needed to permit rollback due to the criticality of the secured application.

With today's revocation, this closes our scope.
With regards to VeriSign, Thawte and GeoTrust, here's our status:

All of the 1024-bit EV certs identified in the SSL Observatory have expired or been revoked.

Of the 8 certs with non-FQDN SANs identified by Mozilla, we are continuing to work with customers to revoke and replace the certificates. 

1 has expired
1 has been revoked
1 is being replaced by a non-EV certificate; whereafter the EV cert will be revoked
1 expires in February. We will ensure the renewal has only FQDNs
4 customers still need to schedule a window to replace the certificate and we continue to work with them.

-Rick
The remaining 1 certificate have been replaced.
Secom complete the action on this issue.

thank you.
Just for the record, I hope that all those that mentioned "replaced" in this thread really mean "revoked".
All of our Secom three 1024bit certificates have expired.
With regards to the remaining VeriSign and Thawte certs, here's our status:

The 8 certs with non-FQDN SANs identified by Mozilla have expired or have been revoked.

-Rick
It looks like all of the impacted CAs have resolved the issues listed above, with the exception of DigiNotar.

Will a representative of DigiNotar please provide a status update asap?
I have received email from a representative of DigiNotar who said that there are still a few customers that need to finish moving over to new certs. This is in progress.
The status of this bug is that we are waiting on DigiNotar to provide an update and complete resolving the issues reported here.

Other than that, I am not aware of any other open action items pertaining to this bug.

Would a representative of DigiNotar please provide an update directly in this bug?
We still have 13 customers which didn't renew their certificates. We personally called them. If they are not responding to our urgent request then we will take further actions. In the worst case, we need to revoke their certificates. 

DigiNotar
(In reply to comment #42)
> We still have 13 customers which didn't renew their certificates. We
> personally called them. If they are not responding to our urgent request
> then we will take further actions. In the worst case, we need to revoke
> their certificates. 

Muhammed, Has this been completed?
No update from Diginotar in 3 months, not even after having requested an update 5 weeks ago?
Ooops. I forgot to post an update in the bug... Before my vacation I had exchanged email with Muhammed (the current representative from DigiNotar), and the status was that they had one remaining customer who still needed to move to the new cert, but the customer has delayed this work due to their holidays.
(In reply to Kathleen Wilson from comment #41)
> The status of this bug is that we are waiting on DigiNotar to provide an
> update and complete resolving the issues reported here.
> 
> Other than that, I am not aware of any other open action items pertaining to
> this bug.
> 


Closing this bug, since the remaining open item is no longer relevant.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.