SSL Cert not working with Firefox/Netscape/Opera

S

shin0bi

Verified User
Joined
Feb 26, 2004
Messages
24
Hi All,


I have a user who has a Thwate™ certificate installed, which is working fine with I.E. but when viewing the site with Firefox, Netscape, or Opera. Here's the error I get with Firefox.

Unable to verify the identity of [site.com] as a trusted site.

Possible reasons for this error:

-Your browser does not recognize the Certificate Authority that issued the site's certificate
-The site's certificate is incomplete due to a server misconfiguration
-You are connected to a site pretending to be [site.com], possible to obtain your confidential information.

I've checked the server's SSL configuration and everything looks correct.


Thanks for your help in advance. :)



Best,
 
It would be relatively easy to test if you'd given us the domain name.

Since you didn't I tried:

https://www.thawte.com/

in both Mozilla and Firefox (on Linux). In both cases, the cert was recognized.

So your first step should be to try the thawte domain, as I did, in the same browsers that don't work for the domain in question.

Jeff
 
IE sees the Certificate Hierarch (Certificate Path) as a complete path, but the other browsers (which are much more "standards aware) than IE) do not:

For example, from Mozilla, for your cert:
Code: 
General
 Issued by: Thawte SSL Domain CA
            Thawte Consulting (Pty) Ltd.
Details:
 Software Hierarchy
  sofaware.infopop.cc
From Mozilla, Thawte's cert:
Code: 
General
 Issued by: Thawte SGC CA
            Thawte Consulting (Pty) Ltd.
Details:
 Certificate Hierarchy
  Builtin Object Token: Verisign Class 3 Public Primary Certification Authority
   Thawte SGC CA
    www.thawte.com
One of our certs, issued for secure.ezsecureusa.com:
Code: 
General:
 Issued by: UTN-USERFirst-Network Applications
            The USERTRUST Network
Details:
 Certificate Hierarchy
  UTN-USERFirst-Network Applications
   secure.ezsecureusa.com
I've never seen a cert work where the hierarchy (path) didn't have the same details at the top as the "Issued by" value.

It appears that Mozilla/Firefox/Netscape 7.x cannot find the "root"; perhaps it's not built into the Mozilla and Firefox browsers.

If not, then it's a major oversight on Thawte's part to not use a root in all the major browsers.

However one other thought comes to mind: browsers should check revocation lists maintained by the cert authority. Is it possible that thawte has, for some reason, revoked the cert?

I believe your next step is going to be Thawte tech support. DO NOT attempt a reinstall unless you save the private key first; without it you cannot use the cert at all.

You pay a lot of a Thawte cert; time to see how good their support is.

(And consider buying your next cert from an authority that's less expensive and does it right :) .)

Jeff
 
I hope everyone gets this (I'll forward to support as well), but as per this web page:

http://www.webservertalk.com/message849972.html

The problem is because httpd is restarted, rather than cold started (stop & start). This was really and truly the magic bullet.

The prior trouble shooting attempt was to duplicate the CA certificate into the CA section of the DA control panel. However, that met with no success on two workstations (one UNIX, and one win32 which had never been to the site before).

Again, /etc/init.d/httpd stop & /etc/init.d/httpd start caused Firefox to recognize the intermediate CA cert.
 
Hello,

But.. a restart is just a stop/start:

http://files.directadmin.com/services/customapache/httpd
Code: 
 restart)
	[b]stop[/b]
	waitforexit "httpd" 20
	[b]start[/b]
	;;
I checked the code to see if perhaps DA was only issuing a "reload", but "restart" is passed for all changes with SSL certificates. The only difference between that and doing it with stop/start is there would be a few seconds of dealy (and downtime) when you type it. I can't say for sure what happened either way. It's also possible that a "restart" on his system is different than ours.

You'd have to go back in the /var/log/httpd/error_log to see if apache was actually restarted when you issued the command.

John
 
Hmmmm, well that's just bizare.

I'll post here if I find out anything further. At present, however, I'm at a loss to describe this behavior.
 
You must log in or register to reply here.
Back
Top