Differences between revisions 29 and 30
Revision 29 as of 2005-04-02 17:00:48
Size: 7606
Editor: anonymous
Comment:
Revision 30 as of 2005-04-04 08:17:57
Size: 7976
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 108: Line 108:
== Denial of Service attack against a CA ==
The CA has to check all possible combinations of them. So the following kind of request could be easily made into a denial of service attack against the CA, there have to be 1024 different domains to be checked:
 (www.|)(t1|t2).(t3|t4).(t5|t6).(t7|t8).(t9|t10).(t11|t12).(t13|t14).(t15|t16).(t17|t18).vhosts.cacert.org

Currently the different browsers, servers and CA´s all implement different and incompatible ways to use SSL certificates for several VHosts on the same server.

The VHost SSL Taskforce tries to find an agreement between those ways, and publish that as an RFC afterwards, so that all the software vendors can agree on one way.

1. Way: SubjectAltName

  • This is the official way, according to the RFC 2818. This was my discussion with Eric Rescorla (the author of the RFC) on the topic:

> Hi Eric,
>
> I would like to know your position regarding Multiple SSL/TLS Vhosts on the
> same machine with the same IP Adress. (Name-based).
>
> In RFC 2818 you have written:
>
>    Matching is performed using the matching rules specified by
>    [RFC2459].  If more than one identity of a given type is present in
>    the certificate (e.g., more than one dNSName name, a match in any one
>    of the set is considered acceptable.) Names may contain the wildcard
>    character * which is considered to match any single domain name
>    component or component fragment. E.g., *.a.com matches foo.a.com but
>    not bar.foo.a.com. f*.com matches foo.com but not bar.com.
>
> I would interpret it as if the solution for the problem is to have several
> identities (dNSName lines) in one certificate for the different DNS Names,
> and that the Browser has to accept any of them:
>
> dNSName: www.customer1.at
> dNSName: www.customer2.com
> dNSName: www.customer3.de
>
> Is that a correct interpretation?

That's certainly one possibility, and it's the only one that will
work with Name Based Virtual Hosts without the domain name extension
(not yet widely deployed)

How can I generate a certificate for that?

Add the following into your openssl.cnf:

[ req_distinguished_name ]
0.subjectAltName                =Alternativer Name 1
0.subjectAltName_default        =DNS:www.welservice.com
1.subjectAltName                =Alternativer Name 2
1.subjectAltName_default        =DNS:sig.cacert.at

How does such a certificate look like?

Host: 212.55.212.241 (provided by jcl) [https://host1.way1.vhosts.cacert.org/] [https://host2.way1.vhosts.cacert.org/]

2. Way: Multiple CommonName´s in the same certificate

How can I generate a certificate for that?

Add the following into your openssl.cnf:

[ req_distinguished_name ]
0.commonName                    = Common Name (eg, YOUR name)
0.commonName_default            = www.domain1.com
0.commonName_max                        = 64
1.commonName                    = Common Name (eg, YOUR name)
1.commonName_default            = www.domain2.org
1.commonName_max                        = 64

How does such a certificate look like?

openssl x509 -in server.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 63209 (0xf6e9)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=support@cacert.org
        Validity
            Not Before: Mar  6 03:06:42 2005 GMT
            Not After : Mar  6 03:06:42 2007 GMT
        Subject: CN=www.domain1.com, CN=www.domain2.com

Host: 212.55.212.242 (provided by jcl) [https://host1.way2.vhosts.cacert.org/] [https://host2.way2.vhosts.cacert.org/]

3. Way: Regular Expressions as CommonName: (www|mail).futureware.at

Host: 212.55.212.243 (provided by jcl) [https://host1.way3.vhosts.cacert.org/] [https://host2.way3.vhosts.cacert.org/]

== Isn't this way useless too? Does this buy us anything a wildcard certificate doesn't? Why not simply use *.futureware.at? This works now, but does not allow us to use multiple different domain names... - FlavioCurti

== You could use it for www.futureware.(at|org) I guess. And for that, www.futureware.* does not work. But I also think that it is mostly useless. - Sourcerer

Denial of Service attack against a CA

The CA has to check all possible combinations of them. So the following kind of request could be easily made into a denial of service attack against the CA, there have to be 1024 different domains to be checked:

  • (www.|)(t1|t2).(t3|t4).(t5|t6).(t7|t8).(t9|t10).(t11|t12).(t13|t14).(t15|t16).(t17|t18).vhosts.cacert.org

4. Way: Multiple certificates in the certificate chain/graph

Host: 212.55.212.244 (provided by jcl) [https://host1.way4.vhosts.cacert.org/] [https://host2.way4.vhosts.cacert.org/]

5. Way: TLS "server name indication".

  • There is a TLS extension called "server name indication". It is currently not implemented by NSS . There are RFEs, you can search bugzilla. I'm not aware of any client or server that implements this extension at this time, but if you are, that might provide an incentive to add it to NSS .

[http://www.mail-archive.com/mozilla-crypto%40mozilla.org/msg06633.html]

Host: 212.55.212.245 (provided by jcl) [https://host1.way5.vhosts.cacert.org/] [https://host2.way5.vhosts.cacert.org/]

Discussion

Here, all related parties (Software vendors, ...) are invited to comment on pros/cons of the different ways.

A message from our legal department: In the situation of ISP´s hosting WebShops of their customers, it is necessary to have a bind the Vhosts to the different customers, so that they are liable for what they do. Having one certificate with all the names in it would give legal problems to the ISP. (author can be contacted through sourcerer)

Interoperability Test

Vendor/App

SubjectAltName

Several CN´s

Regexp

Several Cert

TLSserverNam

Testsystem1

[https://host1.way1.vhosts.cacert.org/ Host1/1]

[https://host1.way2.vhosts.cacert.org/ Host1/2]

[https://host1.way3.vhosts.cacert.org/ Host1/3]

[https://host1.way4.vhosts.cacert.org/ Host1/4]

[https://host1.way5.vhosts.cacert.org/ Host1/5]

Testsystem2

[https://host2.way1.vhosts.cacert.org/ Host2/1]

[https://host2.way2.vhosts.cacert.org/ Host2/2]

[https://host2.way3.vhosts.cacert.org/ Host2/3]

[https://host2.way4.vhosts.cacert.org/ Host2/4]

[https://host2.way5.vhosts.cacert.org/ Host2/5]

CAcert

Yes

Yes

No

Firefox

No

No

Yes

Konqueror

Yes

Yes

No

IE

Yes

Yes

No

Opera

Safari

Useless ways

Multiple CommonName´s and a wildcard first CommonName in the same certificate

How can I generate a certificate for that?

Add the following into your openssl.cnf:

[ req_distinguished_name ]
0.commonName                    = Common Name (eg, YOUR name)
0.commonName_default            = *.*.*
0.commonName_max                        = 64
1.commonName                    = Common Name (eg, YOUR name)
1.commonName_default            = www.domain1.com
1.commonName_max                        = 64
2.commonName                    = Common Name (eg, YOUR name)
2.commonName_default            = www.domain2.org
2.commonName_max                        = 64

How does such a certificate look like?

openssl x509 -in server.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 63209 (0xf6e9)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=support@cacert.org
        Validity
            Not Before: Mar  6 03:06:42 2005 GMT
            Not After : Mar  6 03:06:42 2007 GMT
        Subject: CN=*.*.*, CN=www.domain1.com, CN=www.domain2.org

== Why is that way useless?

Because it is insecure. With a *.*.* wildcard certificate, you could impersonate www.amazon.com, www.paypal.com and everyone else you want with one certificate.

VhostTaskForce (last edited 2012-11-04 18:30:18 by HannoBoeck)