I guess something we should think about is whether to introduce RFC
2818 hostname checking into urllib.urlopen() and similar utilities.
Presumably one would add an optional arg specifying a file full of
root certs to validate against, and if that arg was present, would
retrieve the hostname info fr
On 9/13/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> > However, there is an alternative to using multiple IP addresses:
> > one could also use multiple "subject alternative names", and create
> > a certificate that lists them all.
>
> Unfortunately, much of the client code that does the hostname
>> However, there is an alternative to using multiple IP addresses:
>> one could also use multiple "subject alternative names", and create
>> a certificate that lists them all.
>
> Unfortunately, much of the client code that does the hostname
> verification is wrapped up in gullible Web browsers o
> However, there is an alternative to using multiple IP addresses:
> one could also use multiple "subject alternative names", and create
> a certificate that lists them all.
Unfortunately, much of the client code that does the hostname
verification is wrapped up in gullible Web browsers or Java HT
> My understanding is that the client tells the server which hostname it
> wants to use; the server should then pass down that information. That's
> how virtual hosting works in the first place. The only difference with
> SSL is that the hostname must have a unique IP address, so that when the
>
On Wed, Sep 12, 2007, Bill Janssen wrote:
>
>>> By the way, I think the hostname matching provisions of 2818 (which
>>> is, after all, only an informational RFC, not a standard) are poorly
>>> thought out. Many machines have more hostnames than you can shake a
>>> stick at, and often provide certs
