Vapor wrote:
> I never changed the "ssl_ca_file" option (left it commented out), I assume this then
> uses "/usr/share/ssl/certs/ca-bundle.crt". This contains info on my Thawte certs giving
> them a working chain of authority. I assumed this would not need changing at all unless
> you are using an unlisted CA or a self-signed cert (which would still not benefit from
> changing).
>
> I only changed the paths for:
>
> ssl_cert_file = /etc/pki/dovecot/certs/dovecot.pem
> ssl_key_file = /etc/pki/dovecot/private/dovecot.pem
>
> To point to my cert and key files.
>
> For self signed I had to import the cert into the root auth tree on any client windows
> boxes though to avoid the chain error, not a hard task though with Internet Exploder.
>
> I'd try undoing your change to the "ssl_ca_file" first and restarting, but on grepping /
> usr/share/ssl/certs/* for "modo" brings no joy, maybe you need to add some other
> support for Comodo? I know most common browsers have them in now, as proven by your web
> site setup working. No clue as to how you'd go about adding it to email though.
>
> Unfortunately it's the actual encryption I'm more interested in that the reselling of
> the service, so once it was working on my few Thawtes and self-signed's I stop working
> on it.
>
> It would be nice however that when a cert was added and setup as working in the gui,
> the email server at least responded over SSL for it I agree, seems like such a waste.
> Fair enough we are aware of the single IP per cert limitation but surely that can't be
> too hard to restrict either.
>
> All in all it suffices for a moderate tweakers of in house systems like me, but totally
> unsuitably for reselling SSL encrypted email services as it stands now...
>
Okay - using your info, I actually got IMAPs, and POPs working on a
server. I actually needed to point to the Comodo CA file, otherwise it
would not work. However, SMTPS still fails miserably, still complaining
about the sendmail.pem file.
I will try fiddling with it and post my discoveries.
/Jes