Valid vs Invalid SSL certificates - Was: Re: ISPDB configs without STARTTLS and/or SSL

Tanstaafl tanstaafl at
Sun Jan 20 16:10:27 UTC 2013

On 2013-01-19 10:49 AM, Andrew Sutherland <asutherland at> 
> 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.

Hi Andrew,

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 
financial transactions.

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 
(, 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 mailing list