So what you are saying is my client app (uportal) is not programmed to be able to handle wildcard certs.
-perry -----Original Message----- From: Marvin Addison [mailto:[email protected]] Sent: Friday, March 20, 2009 10:18 AM To: [email protected] Subject: Re: [cas-user] Configure CAS and SSL > I think from my experience and the experience of others on > this list (both recently and in the past which I found > googling) a wild card cert does not satisfy the second > condition of "The cert on the client must be trusted by the > server" I believe wildcard certs should work in some cases. By default the Java SSL engine (http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.ht ml) uses a HostNameVerifier that requires the cert CN to match exactly the name of the host that presents it. Additionally, it has an explicit check to permit a host if the cert CN is a * character. Here's the source (1.5 JDK): if (hostname.equalsIgnoreCase(certHostname) || certHostname.equals("*")) return true; That may explain why *.your.domain doesn't work. See the "HostnameVerifier Interface" section in the document above to see how you can control the hostname verifier used in an SSL socket connection to overcome the default behavior. Also, commons-ssl has some built-in alternatives, http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/Hostn ameVerifier.html. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
