The SSL certificate can be a localhost certificate, but in that case the application using CAS, CAS itself, and the web browser need to all be on the same server. Which is to say that there's an edge case useful for quick trying out CAS and development work but useless for any real production deployment.
SSL certificates are issued to authenticate a domain name not an IP address. http://www.rapidssl.com/ssl-certificate-support/ssl-tech-faq.htm > In moving from a development to production test environment, I found the > following to be true to make things works- > 1. The common name (CN) used to generate the certificate MUST be a DNS name > of the server hosting the CAS service. It CANNOT be localhost or IP address > of the server. > 2. The init-params passed to the CAS filter (serverName, loginUrl, > validateUrl) via the web.xml should also contain the DNS name of the server > as in https://my-server:8443/cas/login or my-server:8080 (for the > serverName). It CANNOT contain localhost, as in > https://localhost:8443/cas/login or localhost:8080 (for serverName). > > Could anyone confirm these statements? I am in a situation where CAS, Tomcat, > Webapp will be deployed within a closed system of sorts with no access to > anything inside the box (web.xml etc). So, I need to be set everything up > beforehand (not possible since DNS name etc is unknown) or set things up > programatically. At present I am considering either going through the trouble > of modifying web.xml programatically or modifying the CASFilter code as was > suggested previously on this forum. > > Your thoughts are much appreciated! > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
