Dealing with warning that certifcate can't be trusted?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I have a basic question about dealing with certificates.  Just
yesterday (May 11th) I started getting an popup from Firefox saying
that the issuer of the certificate of the hotmail site was unknown.
This is weird because I've been accessing hotmail for months via
Firefox, so I was worried that somehow I had been redirected to
another site.

So my question is, when you get an error like this, how do you resolve
what to do?  How do you determine if you really should trust the
certificate or if someone is trying to mislead you?

Re: Dealing with warning that certifcate can't be trusted?

murdocj wrote:
Quoted text here. Click to load it

so three things could have changed

1) different certificate from the webserver
2) different firefox
3) firefox honors some certificate expire date

basically digital certificate are a form of standin trust. there design
target was the offline email of the early 80s; recipient dials up their
local electronic postoffice, exchanges email, hangs up ... and now much
process email. They have new email from total stranger that they've
never communicated with ... and have no resources for determining
anything about the brand new correspondance.

the basic digital signature infrastructure has relying party/recipient
with trusted public key repository for validating digital signatures.
the trusted repository contains some information about the associated
entry (like who they are, their current balance, etc) and the
associated public key.

in the case of the offline email scenario from the early 80s with new
communication from total stranger ... they needed some standin ...
analogous to letters of credit from the sailing ship days. this is the
digital certificate .... instead of just having direct information
about the communicating parties in their trusted repository, they can
also have information about trusted certifying authorities in their
repositories. trusted certification authorities certify some
information about an entity and package it along with the entities
public key in a digital certificate.

no when relying party gets some correspondance ... they have the basic
message, the digital signature on the basic message and an attached
digital certificatee (signed by a certification authority). They
retrieve the public key of the certification authority from their
trusted repository and verify the digital signature on the digital
certificate, they then retrieve the sender's public key from the
digital certificate and verify the digital signature on the base
correspondance (and use whatever information about the sending entity
contained in the digital certificate).

Cerfified information tends to have expiration dates (frequently they
are good for a year). Also some products ship trusted public key
repositories embedded in their product ... the public keys in the
embedded respositories also can have expiration dates.

possible (valid) reasons for the error:

1) hotmail's digital certificate could have expired and they had to get
a new digital certificate. for some reason the new digital certificate
could be signed by a certification authority that firefox doesn't know
about (ask to view the digital certificate and see if it is newly
issued and the identity of the certification authority).

2) a new firefox could have shipped ... and the contents of its
embedded trusted public key repository could have changed (go look at
the public keys in firefox's embedded trusted repository)

3) the public key (included in firefox's embedded trusted public key
repository for the certification authority used for hotmail's digital
certificate could expired. there are some number of embedded trusted
repositoriies that are shipping with expired certification authority
public keys ... an ongoing issue is should browsers and other products
ignore such expiration dates ... or conform to specified processing
defined for expired information.

the traditional mechanism for dealing with questionable information is
to examine it closely ... and then see if it can be corroborated via
other means.

Re: Dealing with warning that certifcate can't be trusted?

On 14 May 2005 05:13:39 -0700, wrote:

Quoted text here. Click to load it

I had taken a look at the certificate and it looked like it was #1.
The certificate was listed as having been issued about 2 weeks earlier
by something like (I don't recall the exact issuing
agent).  And when I looked at the issuing authorities in my copy of
firefox, that issuer wasn't listed.  So I suppose what could have
happened was that Microsoft issued a new certificate and then had just
started using it with the hotmail site.

Quoted text here. Click to load it

Yep, I think this is the case.

Quoted text here. Click to load it

I tried to do this.  I did things like checking the IP address of
hotmail against the IP on other computers, etc.  One thing I was
nervous about was that my ISP's DNS servers have been really awful, so
I've been using a utility called treewalk to do local DNS.  So I start
getting paranoid about treewalk perhaps deliberately pointing me to
the wrong site.

One other thing I did was run IE on the same computer to hotmail.
That did not bring up a certificate warning about the issuer, so I
assume that meant that IE had that issuer among the valid issuers.

Site Timeline