SSL + E-mail: Certificate solution?


#1

I’ve recently found a possible solution to the certificate issues Dreamhost has. RFC 2818[1] defines a “subjectAltName” field that can be used to denote an alternate certificate authority, namely Dreamhost. Has this solution been explored?

I don’t know what clients support this certificate field, but it would be a step in the right direction. Thanks!

[1] http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2818.html#sec-3.1


#2

We have thought about setting up our own CA.

That said, this still doesn’t really address the primary issue here, which is not getting most clients to accept the certificate as valid, but rather getting certain clients to accept a certificate which is for a different hostname than the one the user is connecting to.


#3

Verifying that the host connected to is who they say they are is an important function of SSL. So I’m hoping that nobody (even a very good hacker) would be able to defeat that cryptographic protection without spending a substantial bit of time and effort.

That said, I think some kinds of organizations might want to set up CAs, since even with the costs of certificates falling to $50 and below, some (particularly nonprofit) organizations don’t have a lot of money.

Does anyone know the procedure for getting a root certificate supported by the major browsers?


#4

I was under the impression that the Subject Alternative field did just that.

Additional details can be found in RFC 3280 Sect 4.2.1.7, X.509v4 Sect 8.3.2.1, or at the following URLs:

http://enterprise.netscape.com/docs/cms/61/cert/admin/app_ext.htm
http://developer.novell.com/ndk/doc/ncslib/index.html?page=/ndk/doc/ncslib/npki_enu/data/a2ueh70.html