Valid vs Invalid SSL certificates - Was: Re: ISPDB configs without STARTTLS and/or SSL
tanstaafl at libertytrek.org
Sun Jan 20 16:10:27 UTC 2013
On 2013-01-19 10:49 AM, Andrew Sutherland <asutherland at asutherland.org>
> A similar, if less strong, case can be made for requiring valid SSL
> certificates. There are free alternatives like gmail that are known to
> be, at the very least, competent. And there are free SSL certificates
> available from StartCom and maybe others.
I may be misreading this, so would you mind elaborating on what you
meant above by 'valid SSL certificate'?
It sounds like you mean 'signed by a trusted 3rd party'.
First and foremost, I hope you will agree that there is a big difference
between SSL certificate usage in a web browser and in an email client.
Web browsers are used for (among other things) financial transactions.
Email clients are not. Every single legitimate argument I have ever seen
discusses this issue only from the standpoint of the web browser and
Second, Are you saying that self-signed certs are *invalid* certs? While
it is true that they are not signed by some trusted 3rd party, that
certainly does not mean they are invalid.
We have always used self-signed certificates. They are extremely
flexible and easy to use (and free, but that is not even a large reason
we use them). It has always infuriated me that Outlook doesn't provide
an option for permanently trusting a self-signed cert without having to
jump through major hoops, and having Thunderbird able to do so with a
single mouse-click has always been a boon for us.
I totally understand the reason for requiring 'valid' (per my definition
above) certs in a web browser since they can be/are used for financial
transactions, and no one in their right mind, large or small, should use
self-signed certs to secure financial transactions, nor should anyone
buy anything from anyone who did so.
I also understand the rationale for a much stronger warning about an
*invalid* cert (hostname mistmatch, expired, etc) whether it is signed
by a trusted 3rd party or self-signed, but self-signed certs are a very
important and useful function for small companies or individuals who
don't want to jump through the hoops and/or divulge personal information
(which they *all* require) in order to get a 'trusted' certificate.
I could understand the argument in favor of disallowing, or at least a
much more strongly worded warning for large free-mail service providers
(like google, hotmail, yahoo, etc), but again, for private systems,
self-signed certs are extremely important.
I see there is a bug about changing the incorrect wording in Mozillas
warning about self-signed certs being invalid
(https://bugzilla.mozilla.org/show_bug.cgi?id=433422), but it appears
that the drivers have no desire to change it (I didn't research this
further, but cannot see any legitimate reason for wanting to
intentionally mislead people by saying it is invalid when it isn't),
which would, imnsho, be the best way to handle this...
I could understand, and even support a change that would make it much
more difficult to trust an *invalid* certificate, and would even support
a change in the default option to 'permanently store the exception' for
valid, self-signed certificates (ie, make it unchecked). You could even
post links to web pages explaining the differences, and maybe a new
field could be added to the ISPDB for providers who use self-signed
certs (DreamHost is one, I know because I use them). Maybe even add a
new about:config option so that Companies could add their own links to
this warning dialog to pages they designed, explaining things...
Anyway, thanks, and I look forward to your response.
More information about the tb-planning