[Dovecot] client certs with godaddy ssl cert

[Bill Cole]

Harondel J. Sibble wrote:
> 
> On 29 Sep 2008 at 10:43, Bill Cole wrote:
> 
>> Right. You need to keep track of what client certs you trust, so you really
>> should be *at least* the immediate issuer (signer) of the client certs. The
>> only reasons you would want your signing cert for those client certs to have
>> a commercial issuer would be:
> 
> That's my intent to have full control over the client certs hence the reason 
> for going with self signed certs for the client side.
>  
>> 1. You want the client certs to be generally usable with those devices and
>> servers other than your own.
> 
> I do not, this is only for use with my infrastructure and will be limited to 
> a small handfull of people.
>  
>> 2. The devices do not support the addition of new "root" certificates (i.e.
>> your signing cert.)
> 
> Mix of devices, but primarily windows mobile, palm, symbian and blackberry 
> handhelds.  There will also be a few laptops.

I've heard so many conflicting stories about the X509/SSL/TLS capabilities
of different mobile platforms that I don't know what to believe. I would
expect that the Windows Mobile devices could use any cert you can construct,
and I know that *some* Palm mailers can deal with self-signed server certs
and so could *probably* deal with client certs, but even that's an iffy
proposition because so many Palm devices are carrier-customized in bad ways
(particularly by Verizon.) I've seen enough stupid failure when asking for
client certs that I wouldn't try it with any platform where the vendor does
not clearly explain how to do it.

>> It is also likely to be irrelevant. The signature chain of a server's cert
>> does not influence what signing chain a client cert needs to have.
> 
> Ohh.... I was wondering about that...
> 
> Okay then so as long as Dovecot is set to check client certs and the client 
> cert presented matches the check points, CN, domain name, user email etc, 
> it'll just work?

Dovecot does have to trust the signing cert for the clients (i.e. it can't
just be looking at some default bundle of commercial CA's) but that's not
really connected to its server cert.

>> That is only true if you are using a dependable mechanism to assure that 
>> users will actually be required to enter a password live rather than have 
>> their mail client save it
> 
> I've already beat that one into the couple of business partners that will be 
> making use of this.  Personally I don't ever save passwords, in browsers or 
> otherwise as a matter of course so not an issue for me.

This can't just be about education. The vast majority of users will not
tolerate having to enter a worthwhile password every time they want to make
a mail connection unless it is forced on them, particularly on a device with
a tiny keyboard. You partners may need to be told clearly that if they
cannot or will not enforce frequent password entry on end-users in some
fashion, client certs are literally worthless and any effort (or money)
spent to make them work initially or support them in the future is wasted.

An alternative approach that might be easier to implement on some platforms
(certainly on Palm and iPhone) would be to force the device to lock on
extended idle, network disconnect, or reset, requiring a password to
unlock it. That enforces a "something you know" on the whole device, rather
than just on mail.