Andrew, You raise many interesting points in your letter. I've interlaced my comments below:
>It seems to me that every hosted DN would need to have its own CERT. Sure, >the server could have just one CERT, with all of your DNS users sharing it, >but then the identity being confirmed would be that of the ISP. What good >would that do for me as a purchaser, to access the Encrypted Key of the ISP >if the company with whom I am transacting business is simply one of their >hosted Domain Names? You're right with only one exception. Certificates are issue for a single domain name. Period. Not an IP address, not a server, but only one FQDN. Thwate does offer one type of certificate, the "supercert" which is valid for a parent domain and all sub-domains underneath, but it's not quite compatible across all browsers. >If there is a way around having to purchase one CERT per Domain Name, I >would like to discover it. However, if I am understanding this correctly, Ditto here. I think it's ridiculous that a certificate will not automatically apply to all sub-domains. When you've got multiple servers, or multiple hosts which are used on a very large site to manage the sub-domains and you have to purchase a yearly certificate subscription for each, it's not only expensive, but a pain, and I'm not sure what the justification is for this. If the root domains are secure, why shouldn't the sub domains be as well???? Maybe the certifying authorities need the money. Who knows. >multiple domains can share one IP (which is how I host most domains), but I >never did understand the use of Name-Based VH's. >In what context are Name-Based VH's of value? From what Jeff states, >obviously not on SSL. Name based virtual hosts are critical anytime you've got redundant servers. For example, consider two servers www1.x.y and www2.x.y. These two server are used for redundancy/fail-over and load balancing. With the advent of name based virtual hosts, both servers can use identical configuration files. This reduces the administrative time since the config files are the same. It also give you the ability to setup a continuous replication of the drives to that all changes on one machine automatically transfer to the other machines in the cluster. This is a really good thing. However, since cert's only apply to one domain, you must purchase one cert for each domain/sub-domain on each computer. So, if you've got two redundant servers hosting one site with four sub-domains each, you just had to purchase (8) certificates yearly. Talk about $$$$. So there's my two cents. As I see it, there are 3 reasons you would use this type of security, 1.) Authenticate the connection, 2.) Secure/Encrypt the data, 3.) Authenticate the individual you're doing business with. Items #1 and #2 in my opinion are the only things you as a consumer/client/customer should depend on SSL for. Given that, there is no reason that all certificates could not be provided domain wide. As to item #3? Well, I kind of take the stand that it's the duty of the client to verify the integrity of the person you're doing business with--not a false reliance on SSL to indicate "this is someone I should give my money to." How do you get around this problem? To my knowledge there isn't any reliable way. In the interim, I have one domain on one IP on one server that takes care of all my SSL needs for all of the sub-domains. However, this is only going to work for so long. I don't get the redundancy I need and administratively it's not very efficient. Oh well. If anyone has come up with any other great ideas, I'd love to hear them. >Andrew L. >The ACL Group, Inc. David Buerer TecnoGenesis, LLC ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
