Bug 192977 - Can't visit a specific https:// site
Can't visit a specific https:// site
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
:
: 211975 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-24 12:12 EDT by Hector Palacios
Modified: 2007-11-30 17:11 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-17 11:51:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hector Palacios 2006-05-24 12:12:06 EDT
Description of problem:
I can't visit http://www.credicard.com.ve/bancaribe
or
https://www.credicard.com.ve/credicard/jspEnLinea/enlineaBanco.jsp?xBco=301.
The former jumps to the last one.

But I can visit it when using mozilla-1.7.12-0.90.2.legacy
with a kernel 2.4.26-1.ll.rh90.

Version-Release number of selected component (if applicable):
firefox-1.5.0.3-1.1.fc5

How reproducible:
Always reproducible.

Steps to Reproduce:
1. Type in  http://www.credicard.com.ve/bancaribe
or https://www.credicard.com.ve/credicard/jspEnLinea/enlineaBanco.jsp?xBco=301

Actual results:
It said something like:
"wrong authentificacion message recieve"
(free traduction from spanish)

Expected results:
Should show the web page.

Additional info:
In fact, the web page is jumping to
https://www.credicard.com.ve/credicard/jspEnLinea/enlineaBanco.jsp?xBco=301
which is an encrypted page
Comment 1 Tomasz Kepczynski 2006-07-12 03:26:15 EDT
I seem to have very similar problem. I cannot access the following sites:
https://login.vwbankdirect.pl
https://www.r-bank.pl
Firefox reports error -5990 and says it cannot start encrypted connection.
Mozilla works for both sites.
Now the really important part seems to be firewall and proxy. I have the
following automatic proxy config:
function FindProxyForURL(url, host)
{
  return("PROXY proxy.xxx.xxx.com:911");
}
but browser seems to go directly and obviously fails (I can see
SYN_SENT line in netstat -t going outside the firewall to
12.166.243.30:http for both of the above sites).
Could this be a problem with certificate handling (maybe it is
trying to fetch crl from CA directly)?
The site #1 also does not work for me.
I can access both of the sites from another machine where both
sites are available directly.

I have the following packages:
mozilla-1.7.13-1.1.fc5 i386
firefox-1.5.0.4-1.2.fc5 i386
Comment 2 Tomasz Kepczynski 2006-07-12 03:40:44 EDT
The site 12.166.243.30 is ocsp.verisign.com. This site is mentioned
in certificate for login.vwbankdirect.pl in:
[1]Authority Info Access
     Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
     Alternative Name:
          URL=http://ocsp.verisign.com
[2]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://SVRIntl-aia.verisign.com/SVRIntl-aia.cer
Comment 3 Tomasz Kepczynski 2006-07-12 03:49:02 EDT
As a workaround turn off OCSP:
Edit->Preferences->Advanced->Security->Verification and select
Do not use OCSP for certificate validation

Anyway - firefox should use any configured proxy for this.
Comment 4 Diego Torres Milano 2006-08-14 11:44:23 EDT
Something in the firefox-1.5.0.6-2.fc5 RPM or its dependencies is broken, it's
searching for PSM (Personal Security Manager) but PSM is not there.
The problem seems to be evident with any https request. It is not related to
specific sites.
Firefox was working before the 'yum update'.
You can't even fill in a bug report in bugzilla.redhat.com because you need
HTTPS to do it ! ;-)

QUICK WORKAROUND:
Download firefox 1.5.0.6 tar.gz from Mozilla.com, unpack it and it will work.
The when the RPM will be fixed, update and delete the unpacked firefox.
Comment 5 mohanraj 2006-08-15 00:33:04 EDT
The Difference in the new version is that the following modules for the Security
devices are not loaded.
1.N S S Internal PKCS#11 Module
Thiscomprises of two modules Generic Crypto Services and Software security services.

2. Builtin Roots Module
This comprise of Builtin Object token.
These are the products of Mozilla and connected with the Personal Security
Manager. this may be the reason for not connecting to Https sites.These are
loaded in the Mozilla browser.

I Tried loading these modulesby going to Prefrences -- Advanced -- Security --
Security Devices.

I could not add these modules because i do not know what files to load are where
to look for them.

Can anybody give instruction how to load them.
	Reply With Quote
Comment 6 Terry Gruber 2006-08-18 17:14:01 EDT
All HTTPS sites are broken and inaccessible.  Doesn't matter where I go.  I
tried the Mozilla Firefox tar.gz file replacement.  It works on a current
installation, but not on a newly installed  (read, fresh Fedora installation)
Fedora Core 5.
Comment 7 Terry Gruber 2006-08-18 17:43:58 EDT
(In reply to comment #6)
> All HTTPS sites are broken and inaccessible.  Doesn't matter where I go.  I
> tried the Mozilla Firefox tar.gz file replacement.  It works on a current
> installation, but not on a newly installed  (read, fresh Fedora installation)
> Fedora Core 5.  Also, i have noticed that there are no loaded security files
on the 1.5.0.6 distribution in FC-5 which is probably a cause of the problem. 
The above workaround involving turning off OCSP didn't work---the setting was
already existing at installation.  

Anyone know how to install the security devices?

Comment 8 Terry Gruber 2006-08-18 17:44:54 EDT
(In reply to comment #6)
> All HTTPS sites are broken and inaccessible.  Doesn't matter where I go.  I
> tried the Mozilla Firefox tar.gz file replacement.  It works on a current
> installation, but not on a newly installed  (read, fresh Fedora installation)
> Fedora Core 5.  Also, i have noticed that there are no loaded security files
on the 1.5.0.6 distribution in FC-5 which is probably a cause of the problem. 
The above workaround involving turning off OCSP didn't work---the setting was
already existing at installation.  

Anyone know how to install the security devices?
Comment 9 Russ Henry 2006-09-16 13:43:15 EDT
upgraded from firefox 1.5.0.6-x to 1.5.0.7-1.FC5 and now now secure https sites
will load. Disabled iptables and tried with --safe-mode param. The specific
error is:
Unexpected response from server
Firefox doesn't know how to communicate with the server.
* Check to make sure your system has the Personal Security Manager
installed.
* This might be due to a non-standard configuration on the server.

I am currently running running kernel 2.6.17-1.2174_FC5 #1 
Comment 10 Peter Kukums 2006-09-16 20:40:35 EDT
I also just upgraded to Firefox 1.5.0.7-1.FC5 but I still cannot view any secure
sites.
Comment 11 Warren Togami 2006-09-17 11:48:20 EDT
Did you upgrade to the latest FC5 update of firefox without upgrading nss?
Comment 12 Christopher Aillon 2006-09-17 11:51:10 EDT
This is only a problem for people who update individual packages.  The issue was
that nss, which firefox depends on, changed ABI accidentally in a non compatible
way.  Firefox was built against the newer ABI and older versions of nss will not
work, but will corrupt the component registry.  There is no way to fix this for
you via RPM unfortunately.  The only fix is to make sure that you have the
latest nss and firefox versions, and then while all firefox instances are
closed, delete the compreg.dat from your profile directory.
Comment 13 Peter Kukums 2006-09-17 12:12:40 EDT
Thank you. Deleting compreg.dat has fixed the problem.
Comment 14 Tomasz Kepczynski 2006-09-18 02:34:12 EDT
It is a real pity you haven't paid attention to original bug report and my
commants #1 - #3. The original issue still exists and is not fixed by deleting
compreg.dat file. I also always upgrade via yum, so I shouldn't have had
incompatible firefox and nss.
Anyway - with browser behind firewall, configured proxy, certificate with OCSP
URL and OCSP on in firefox I still can't connect to such secure site. Turning
off OCSP works around a problem.
As I mentioned in #2 - firefox goes directly to fetch OCSP instead using
configured proxy.
Please reopen.
Comment 15 Terry Gruber 2006-09-18 07:44:21 EDT
I went back to the 1.5.0.4 version and upgraded to .7, skipping .6.  Could that
version be the problem?  Because .7 is working fine on both my machines.
Comment 16 Russ Henry 2006-09-18 09:43:25 EDT
Updating nss, reinstalling firefox 1.5.0.7-1 and deleting compreg.dat worked 
for me as well. Thanks!
Comment 17 Christopher Aillon 2006-10-30 16:00:12 EST
*** Bug 211975 has been marked as a duplicate of this bug. ***
Comment 18 Axel Hutt 2006-11-08 10:13:37 EST
(In reply to comment #13)
> Thank you. Deleting compreg.dat has fixed the problem.

deleting compreg.dat works for me!
I had updated firefox by yum and https sites did not 
work. Now they do

Thanks a lot for the hint
Comment 19 Cameron Davidson 2006-11-10 21:28:55 EST
Just adding a bit more information in case others are searching for this.
I also got bitten by the bug because I only upgraded firefox (to 1.5.0.7).
Since the API to NSS has changed in an incompatible fashion without updating the
version, I presume that upgrading nss will break older apps built against
previous nss.
In my case that seems to be only thunderbird, which I had updated at the same
time anyway. The upgraded thunderbird has the same problem as firefox, and
deleting compreg.dat from its profile fixes that also. I could not find a
thunderbird bugzila report.

Other symptoms:
The password database is no longer available for either program:
  1. It will not ask for the master password
  2. listing saved passwords only shows old entries from mozilla (short
encrypted entries) but it cannot recover those passwords anyway. entries stored
beginning MD are not even listed with user names.

Another note for those interested - I share my profiles between Fedora and XP on
a network drive. Deleting compreg.dat did not upset the XP versions, and they
still seemed to work even when compreg.dat was corrupted.

Note You need to log in before you can comment on or make changes to this bug.