browser vendors and CAs agreeing on high-assurance certificat es

[Eric Rescorla]

Ben Laurie <ben at algroup.co.uk> writes:

> Ian G wrote:
>> Ben Laurie wrote:
>> ...
>>>> Hopefully over the next year, the webserver (Apache)
>>>> will be capable of doing the TLS extension for sharing
>>>> certs so then it will be reasonable to upgrade.
>>>
>>>
>>> In fact, I'm told (I'll dig up the reference) that there's an X509v3
>>> extension that allows you to specify alternate names in the certificate.
>>> I'm also told that pretty much every browser supports it.
>> 
>> The best info I know of on the subject is here:
>> 
>> http://wiki.cacert.org/wiki/VhostTaskForce
>> 
>> Philipp has a script which he claims automates
>> the best method(s) described within to create
>> the alt-names cert.
>> 
>> (The big problem of course is that you can use
>> one cert to describe many domains only if they
>> are the same administrative entity.)
>
> If they share an IP address (which they must, otherwise there's no
> problem), then they must share a webserver, which means they can share a
> cert, surely?

Actually, the big problem if you run a virtual hosting server
is that every time you add a new virtual domain you need a new
cert with that domain in it. And that applies even if you put
all the names in one cert.

Really, the ServerHostName extension is better.


>> What we really need is for the webservers to
>> implement the TLS extension which I think is
>> called "server name indication."
>> 
>> And we need SSL v2 to die so it doesn't interfere
>> with the above.
>
> Actually, you just disable it in the server. I don't see why we need
> anything more than that.

The problem is that the ServerHostName extension that signals
which host the client is trying to contact is only available
in the TLS ClientHello.

-Ekr

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com