Closed Bug 181822 Opened 23 years ago Closed 23 years ago

Login to Schwab returns error code -8190 when trying to establish an encrypted connection

Categories

(Core Graveyard :: Security: UI, defect)

Other Branch
x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: mrp.bugzilla1, Assigned: ssaux)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b; MultiZilla v1.1.25) Gecko/20021016 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b; MultiZilla v1.1.25) Gecko/20021016 We are unable to access the Schwab web site with Mozilla. When clicking on the 'login' button, a dialog box pops up with the following error message: "Error establishing an encrypted connection to investing.schwab.com. Error code: -8190." IE and Netscape 4.79 have no problems with it. The problem is repeatable on all versions of Mozilla I have tested (> 0.96) and on both Windoze and Linux platforms. Needless to say, it breaks my heart to crank up Netscape 4.79 to access Schwab. Reproducible: Always Steps to Reproduce: 1. Surf to www.schwab.com 2. Click on the "Login" icon or keyword 3. Up comes the error message (popup dialog), and further progress into schwab will not be possible. Actual Results: A dialog box pops up with the following message: "Error establishing encrypted connection to investing.schwab.com. Error code: -8190." Expected Results: Established an https connection to investing.schwab.com. The Investing.schwab.com web page should ask for a user name and password. The problem has been tested with: Mozilla 1.2b on WindozeXP Mozilla 1.0 on Mandrake Linux 8.2+Ximian Mozilla 1.1 on Mandrake Linux 9.0 The problem has existed for quite a while (> Mozilla 0.96). The problem has been repeated on machines both at home and at work, so it is not isolated to a "bad configuration" or "hosed registry". Unless, I've configured all four machines similarly, and incorrectly. Home machines have no proxy. Work machines try to access schwab through a proxy firewall. Problem exists in Netscape 7.0 also. However, IE and Netscape 4.79 are able to access schwab from these same machines with no problem. For the Linux platforms, Konqueror and Galeon work as well. Have tried using HTTP 1.0 with pipelining and keep alive turned off--no success. Have disabled most of the crypto except SSL2 (which is what I believe schwab wants)--no success. Problem could be user error--as I find bug reports indicating that others are accessing schwab with only limited problems. But, for the life of me, I can't figure out what I could be doing incorrectly. To me, it appears to be a Mozilla bug at this time.
-> PSM (please read the component description sice securtiy doesn't hanle SSL/TLS bugs) Have you tried it with a new (additional test) profile ?
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: Trunk → unspecified
Creating a new "test" profile clears the problem right up! Sorry I didn't think to try that. Also, sorry about mis-classifying the component of the bug report--tried my best, and guessed wrong. Mozilla (and I) are VERY happy at this point. However, should the report stay open since it doesn't work in the default profile? Thanks for the help!
Have you migrated old NS4.7x profiles ? Please rename/move to another location this files from your old profile: cert7.db , key3.db
Reporter, can you check your old profiles to see if OCSP was turned on? That may have been the problem. Edit>Prefs>Privacy>Validation. If so, set it to "Do not use OCSP", which is the default.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Answers to comment #3: Yes, it is highly likely that the Netscape 4.79 settings were migrated. As instructed, for the default profile I renamed cert7.db and key3.db to cert7.db-old, and key3.db-old respectively. That does not clear up the problem. Answers to comment #4: OCSP is off per the default install. I will admit to fiddling with it to see if it was the culprit; however, when it didn't correct anything, I restored it to the original setting (off). Thanks for the suggestions. I'm willing to try any others, as it seems a 'bad thing' for one profile to work and another one not. Particularly when the other one is the default profile.
Found it! The Schwab web page breaks if I enable FIPS in the Privacy&Security>Certificates>Manage Security Devices. Looks like I caused the problem by setting this option. However, I reopened the report for evaluation. SSL shouldn't break because FIPS is turned on, should it?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
No, SSL should not break when FIPS is enabled. That is a separate bug to disable SSL2 when FIPS is enabled, which for some reason, Schwab uses exclusively, no SSL3 or TLSv1. Marking worksforme instead of duplicate of bug 106604. Reporter, you might have better error messages with a more recent nightly build at www.mozilla.org. Install into a clean directory in case there is a problem with a particular night's builds. All of your profiles will still be available.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
Verified WFM.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.