Closed Bug 974262 Opened 10 years ago Closed 10 years ago

Compatibility problems due to removing 1024-bit Entrust roots

Categories

(NSS :: CA Certificates Code, task)

3.16
task
Not set
normal

Tracking

(firefox28 unaffected, firefox29 affected, firefox30 affected)

RESOLVED INVALID
Tracking Status
firefox28 --- unaffected
firefox29 --- affected
firefox30 --- affected

People

(Reporter: prittman, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

Attached image OWA.png
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140218004001

Steps to reproduce:

Access website https://cas.vvc.edu/owa/. 





Actual results:

Webpage won't show, but only an error page (see screenshot: http://paulrittman.com/OWA.png). I have attached this screenshot to this bug report.


Expected results:

I should have been taken to a login page that allowed me to enter username and password for an email account. 

It works in IE 11. 

What didn't work:
(1) Deleting cookies and cache; 
(2) restarting with addons disabled;
(3) changing my DNS
(4) disabling the default option in FF for using the Online Certificate Status Protocol
Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2925006239ec
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140209161501
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5b5e7559cda5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140209163202
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2925006239ec&tochange=5b5e7559cda5

Regressed by: Bug 967153
Blocks: 967153
Status: UNCONFIRMED → NEW
Component: Untriaged → Security
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Assignee: nobody → nobody
Component: Security → CA Certificates
OS: Windows 7 → All
Product: Core → NSS
Hardware: x86_64 → All
Summary: Outlook Web Access site won't work in FF 29 or 30 → Compatibility problems due to removing 1024-bit Entrust roots
Version: 29 Branch → 3.16
To resolve this problem, the cas.vvc.edu administrator needs to...

1. Remove the Entrust1024->USERTrustLegacySecureServerCA intermediate that the server currently sends.

2. Add this Entrust2048->USERTrustLegacySecureServerCA intermediate instead:
http://crt.usertrust.com/USERTrustLegacySecureServerCA_2.crt
(This intermediate has the same Subject Name and Public Key as the other intermediate).

3. Consider adding this Entrust1024->Entrust2048 cross-certificate, if there is a need to preserve compatibility with legacy clients that don't trust the Entrust2048 Root but do trust the Entrust1024 Root:
http://crt.usertrust.com/EntrustCertificationAuthority2048_2.crt
2 things:

1. it still works in FF 27 release.

2. I called the network guy at our college, and he said that the certificate hasn't expired yet (July 15 is the expiration). He also verified that it works in the release. 

This probably won't get fixed on their end until later on, if there still is a problem by the time 29 hits release.
Thank you for filing this bug.

As per Bug #936304, the Entrust.net 1024-bit root is being removed in Firefox 29.

Bruce, Please have someone from Entrust contact this customer to move them to a cert that does not chain up to the 1024-bit root, or is cross-signed with a 2048-bit root.
Thanks, Kathleen. I'll email your statement to our web admin.
Will have our Support team follow up.

Thanks, Bruce.
This is good info. - we do have 2048RSA certs, but may have not rolled up to the new ones on this server yet for Outlook Web App - thanks - will go take a look tomorrow. 

Justin
(In reply to Kathleen Wilson from comment #4)
> Thank you for filing this bug.
> 
> As per Bug #936304, the Entrust.net 1024-bit root is being removed in
> Firefox 29.
> 
> Bruce, Please have someone from Entrust contact this customer to move them
> to a cert that does not chain up to the 1024-bit root, or is cross-signed
> with a 2048-bit root.

Kathleen, as I wrote in comment 2, there is no need for this customer's end-entity cert to be replaced.  They just need to change which intermediate(s) their server sends.
Rob, can I assume that your personnel are dealing with this issue with the customer?

Thanks, Bruce.
(In reply to Kevin Brosnan [:kbrosnan] from comment #10)
> https://members.nearlyfreespeech.net is affected as well.

Kevin, Would you please try browsing to that site again? Looks like they installed a new SSL cert, so I want to double-check the behavior of someone who has browsed to the site before then.
nearlyfreespeech.net WFM now. When Kevin first posted the link, I got an error message, so yes, I agree Kathleen, they must have done something recently, b/c now I'm taken to a login page.
(In reply to prittman from comment #12)
> nearlyfreespeech.net WFM now. When Kevin first posted the link, I got an
> error message, so yes, I agree Kathleen, they must have done something
> recently, b/c now I'm taken to a login page.

Excellent. Thanks for checking!
> they must have done something recently

The current cert is valid:

  from: 2014-02-21 00:00:00 UTC
    to: 2016-02-21 23:59:59 UTC

so they /did/ just get a new cert.

Yesterday.
I think we're done here. If not, reopen please.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Looks like the server is still sending the legacy 1024-bit intermediate:
https://www.ssllabs.com/ssltest/analyze.html?d=cas.vvc.edu
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: