Everyone is familiar with going to a SSL page in a web browser. That being
said, you should know that there are three major checks.
1. Check to see if the host name and the Common Name (CN) of the
certificate are one in the same. If not, a warning results.
2. Check to see if the certificate is expired. If it is, a warning
results.
3. Check to see if the certificate is issued by an authority that is
trusted.
These Certification Authorities can be chained. This is called a Chain of
Trust. For example, let's say I have an ID Card issued by the State of
Hawai'i but I am in California. Why should I trust it? Well, I can say
that I trust it because Hawai'i is mart of the United States, I trust the
United States, therefore I trust the State of Hawai'i because the United
States trusts the State of Hawai'i. These Certification Authorities are
companies or organizations like Verisign, Thawte, etc. Depending on the OS,
the actual mechanism for storing these CAs may vary but in general they are
kept in some kind of Certificate Store.
At any rate, when you use a web browser, you may see a message that is
displayed when one of these tests fail and you will then have the option to
accept the message or not. Not all protocols have the ability to provide
you with an error message because in many cases, there is no UI to send the
message too. Therefore, the end result is the process fails and you simply
get some kind of error. It seems that at least with the mail clients, we
are getting a warning message, similar to what we get with a web browser.
However, you can see that even if you SSL enable every site, you will still
have to deal with the issue of a trusted authority. The only way around
that is if you have your clients Import your CA (of your server) into their
Certificate Store for Trusted Certification Authorities. I know how to do
that for Windows but frankly speaking, I am not so knowledgeable on how to
do that for other OSes. I know I can figure it out if need be.
On 10/1/06 3:08 AM, "Connexions Web Solutions"
<administration (at mark) cnx-solutions.com> wrote:
> Hi Blues,
>
> Thats how its supposed to work I think.
>
> If for example your clients domain is www.domain.com, and the
> certificate is issued in that name, they will get no warning.
>
> If however their mail server is say pop3.domain.com, and they
> attempt to connect to pop3.domain.com top get their mail securely,
> then a warning will be issued saying this certificate is not issued for
> pop3.domain.com, but is www.domain.com.
>
> Onother problem is each certificate I am pretty sure has to have a
> unique IP.
>
> Setting up secure certficates so you do not get warnings is not as
> easy as it sounds. Especially with all the different types of OS.
>
> Rgds.
>
>
> Date sent: Sun, 1 Oct 2006 13:14:42 +0200
> From: Maurice de Laat <muisnetw (at mark) xs4all.nl>
> Send reply to: coba-e (at mark) bluequartz.org
> Subject: [coba-e:07321] Re: Dovecot SSL warning (not error)
> To: coba-e (at mark) bluequartz.org
>
> [ Double-click this line for list subscription options ]
>
> On Thu, Sep 28, 2006 at 03:39:00PM +0100, Connexions Web
> Solutions
> wrote:
>
>> You will get this unless you use a properly chained certificate from
>> a recognised authority.
>
> Indeed. However, my users have another problem with the
> certificate.
> When they are connecting with POPS to their own virtual
> domainname,
> they receive a security warning that the certificate's domainname is
> different from the domainname they are connecting to. The
> certificate's domainname is the name from the box.
>
> When the client uses the box's name as their POPS server, there
> is no warning. Anyone know of a way to get rid of the warning while
> still using the client's domainname as the POPS server?
>
> Thank you