Andrew, Thanks. Indeed one wildcard certificate will lead to a single point of failure if the private key is compromised. I also think browsers are designed to persistently raise hell about (paraphrasing) "the actually server name being different from server certificate". thereby deteriorating the user experience.
________________________________
From: [EMAIL PROTECTED] on behalf of Andrew William Petro
Sent: Fri 5/18/2007 3:10 PM
To: Yale CAS mailing list
Subject: Re: Wildcard SSL Certificates
Uday,
Consider the consequences if one of your hosts is compromised.
If you've used wildcard certs, the Adversary lays hands on the private key that
authenticates and secures communication with *all* of your secure hosts
matching the wildcard. Additionally, the Adversary gains a critical piece of
what would be necessary to set up his own purportedly secure host within your
domain. Compromise of a single host has potentially system-wide consequences.
If you've used hostname-specific certs, the Adversary lays hands on only on the
private key that authenticates that particular host. Compromise of a single
host has single-system consequences (or otherwise leaks out depending upon what
RDBMS passwords the Adversary finds on the host, etc. etc., but in any case
isn't exacerbated by a wildcard cert.
An alternative approach for economizing on SSL certificates is to establish a
certifying authority, train your users to trust that, and then use it to sign
the certificates of your hosts. Under this approach, only that certifying
authority cert (which you should carefully guard) has the system-wide
consequences. Compromise of individual hosts only yields ability to
man-in-the-middle individual machines.
Anecdotally, I believe at least one major university considered this issue and
concluded that in terms of total cost of ownership, commercial certs are for
them actually the most cost effective way to go. The effective cost of
measures to establish, secure, and distribute the public key of a certifying
authority and the certificates signed by it was expected to exceed the cost of
purchasing commercial SSL certs.
Andrew
Uday Kari wrote:
Does anyone have thoughts about using wildcards in server names for SSL
Certificates with CAS? For instances, a certificate with *.yourdomain.com will
presumably secure email.yourdomain.com, test.yourdomain.com,
production.yourdomain.com or for that matter cas.yourdomain.com. Our liaison
for the Certification Authority (CA) is urging us to adopt this "wildcard"
policy as a possible cost saving measure to get just one wildcard certificate
for all the servers if we have to adopt SSL. I am pretty sure CAS can either
handle this out-of-the-box (YES? HOW?) or I can extend the open source API to
do so. That is less of a concern for me than right now than, should I do this?
Therefore I am floating this balloon. Any pros/cons? Thanks, Uday Kari
________________________________
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
<<winmail.dat>>
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
