AB wrote:
> I'm running IE 8 under WindowsXP. Lately I've been getting a lot of
> warnings about security certificates on sites I KNOW are secure. It's
> gotten to the point where I'm ready to ditch IE for another browser if
> this unwanted interference can't be stopped. Changing the settings in
> Tools --> Internet Options --> Security doesn't make any differnce.
>
> Any suggestions for gettign rid of this nuisance are much
> appreciated!
Depends on what the message said which you didn't show here. Did you
click on the lock icon to the rightside of the address bar and look at
the properties of their certificate?
If the problem is the CA (certificate authority) listed by the cert
cannot be reached to verify the cert then you don't know if that cert
has expired or been revoked (which can be done by the cert owner or by
the CA). Sometimes I've seen old certs (that were purchased for a long
usage time; i.e., expiration is years away) but the CA has changed the
path to their CRL (cert revocation list) so the web browser, ANY web
browser, is told the wrong path to get the CRL (which is like a
bad-checks list showing certs no longer valid or revoked). Since the
web browser can't find the CRL using that path, the cert cannot be
verified (that it is NOT is the blacklist) as still valid.
When you look at the properties of the certificate, look at its "CRL
distribution points" property. That shows what path was recorded in the
cert to have your web browser find the CRL to make sure that cert hasn't
already expired or been revoked. Switching web browsers won't help
because all of them will use the encoded path in the cert to find the
CRL to validate the cert.
The CRL method is the old method of validating certificates. It is a
blacklist of expired and revoked certs. It is akin to sales clerks that
have to look through a list of bad checks to see if a presented check is
okay to accept. It also means having to retrieve the entire blacklist
and search through it. It also places more stress on the CA server to
provide validation for all connections to that domain. See
http://en.wikipedia.org/wiki/Certifi...evocation_list. OCSP (online
certificate status protocol) is the newer method (see
http://en.wikipedia.org/wiki/Online_...tatus_Protocol) but not
employed by all CA's or web browsers. This reduces bandwidth needed to
transfer entire CRLs but places more stress on the server to do the
lookup and send back status. In the wiki article on OCSP, note it says
"Internet Explorer starting with version 7 on Windows Vista (not XP)
supports OCSP checking". Well you have IE8 which is the latest you can
install on Windows XP (IE9 refuses to install) and it will support OCSP
but the crypto support in Windows XP does have the functionality to work
with IE7+ to do OCSP. OCSP was established long after Windows XP was
released. While RFC 2560 was technically ratified in 1999 and Windows
XP was released in 2001, it typically takes 4-6 years before RFCs get
implemented in an OS or in apps. Internet Explorer 7 was released in
2006 (after OCSP was ratified) but still Windows XP's release was too
close to OCSP's ratification to have the support needed in it so Windows
7 could use OCSP.
I've also seen boobs as web designers that use a cert for one domain but
then use that cert in a different domain. Both domains are owned by the
same registrant but they are DIFFERENT domains and a cert validates
against the domain to which it was registered. You never bothered to
give an example site where you run into the cert validate problem.
Also, SSL relies on timestamping in the handshaking process to ensure
there was no interception between sending tokens and getting a response.
I don't know what is the timeout but the server expects a response from
the client within a very short time. If your client (host) time is way
off then SSL handshakes will fail. You need to get your computer and OS
clocks within a minute, or two, of the atomic time so make sure you have
the correct time and are using a time sync utility (the one in Windows
sucks because the MS NTP servers are overly busy so they may not
respond, are not necessarily the shortest path regarding delay between
your host and the NTP server, only work on logon so if you stay logged
on then there is no sync, and a random interval is used between time
syncs that could be days or weeks apart). Get a decent time sync
utility to make sure your time is accurate so SSL will work.
Make sure your time is accurate. It is required for SSL to work.