Re: patch SSL certificate warning

Hi Dan,

I think I understand you thoughts on DNS and SSL and figuring out the
commonalities.

However, SSL is quite different from DNS in that it basically creates a
connection to whatever IP/domain name is given, and authenticates via
public/private key encryption (it follows the end result of DNS e.g.
follows DNS rules, but the result is a single IP address and no further
logic is needed for SSL verification).

Then, the common name (CN) in the SSL cert (whatever it is-it could be
completely different from the actual domain name) is compared to the
actual URL and then action taken from there.

The SSL cert is gained from directly accessing whatever IP address is
resolved from the URL. And as above, this could be completely different
from the actual URL, in which case
an error would arise. However, if the SSL cert CN it is *.domain.com and
the URL visiting is bob.domain.com then it is well accepted that client
side implementations believe this as correct. Similar if the SSL CN is
bob.domain.com and the URL is the same then no problem.

This is completely independent of any other things in the DNS as it only
deals with the IP that the domain name passed resolves to.

The issue is whether an CN of *.domain.com should apply to third, forth,
etc level domains too, which, in my view, it should definitely, and this
is the approach Firefox has taken. I had a look
on the Firefox lists for this and couldn't find any discussion about this...

Best regards,

Matt

Daniel Rall wrote:
> Redirecting to the right place...
>
> Section 4.3.3 seems somewhat relevant, and does seem in line with
> Firefox's behavior, with one possible exception -- if DNS information
> exists for a subdomain, the wildcard is not applied for that
> particular subdomain, or any its subdomains. It's not immediately
> clear to me how this exception could be applied to SSL certs.
> Firefox's behavior seems fairly reasonable to me, if not the norm.
>
> Matt (or anyone), do you know of any discussion on the Firefox
> development lists about this behavior?
>
>
> ----- Forwarded message from Matt Bodley <mattb@mkjb.com> -----
>
> Date: Thu, 06 Sep 2007 09:39:40 +1200
> From: Matt Bodley <mattb@mkjb.com>
> To: Daniel Rall <dlr@collab.net>
> Subject: Re: patch SSL certificate warning
>
> Daniel Rall wrote:
>
>> On Wed, 05 Sep 2007, Matt Bodley wrote:
>>
>>
>>
>>> Hi,
>>>
>>> I am wondering whether anyone is working on fixing the "hostname does
>>> not match" warning when a hostname such as "xxx.secondlevel.domain.com"
>>> is accessed with an SSL Cert authorized for "*.domain.com".
>>>
>>> This is an interesting issue as FireFox has responded accordingly, and
>>> treats the above as valid, but Internet Explorer doesn't yet.
>>>
>>> Because, really, it should behave like FireFox....
>>>
>>>
>> Matt, can you point us to the RFC that documents the proper behavior
>> here? Every app I've ever used (up until Firefox) does not have this
>> behavior.
>>
>> Thanks, Dan
>>
>>
>
> Hi Dan,
>
> http://www.ietf.org/rfc/rfc1034.txt explains the treatment for things
> like MX records, and also IP addresses in DNS records, which are
> consistent with what I mentioned, I cannot seem to find any specific RFC
> on SSL certificates however..
>
> I agree that up until now, most apps do not have this behavior. However,
> I think the current treatment was imposed by default by Microsoft in IE,
> and I think most would agree that it is much better for the Internet in
> general to have the behavior as Firefox is leading, as it reduces the
> cost of websites worldwide and increases the security of those websites
> (there is no lesser security with this behavior, and more people will
> opt for SSL certificates in this manner as the cost is lower).
>
> Best regards,
>
> Matt
>
>
>
> ----- End forwarded message -----
>

-- 
Best Regards,
Matt Bodley
Managing Director
MKJB Limited
Level 12, Unit 10, 135 Hobson St
Auckland Central, Auckland 1010
PO Box 6804, Wellesley Street
Auckland 1141, New Zealand
T: +64 9 358 9199
F: +64 9 909 6033
M: +64 21 428 046
I: http://www.mkjb.com/