...
In most cases this is a hostname/SSL certificate CN mismatch. This commonly happens when a self-signed certificate issued to localhost is placed on a machine that is accessed by IP address. It should be noted that generating a certificate with an IP address for a common name, e.g. CN=192.168.1.1,OU=Middleware,dc=vt,dc=edu, will not work in most cases where the client making the connection is Java. For example the Java CAS client will throw SSL errors on connecting to a CAS server secured with a certificate containing an IP address in the CN.
HTTPS hostname wrong
| Code Block | ||
|---|---|---|
| ||
ava.lang.RuntimeException: java.io.IOException: HTTPS hostname wrong: should be <eiger.iad.vt.edu>
org.jasig.cas.client.validation.Saml11TicketValidator.retrieveResponseFromServer(Saml11TicketValidator.java:203)
org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidator.java:185)
org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:132)
org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(AuthenticationFilter.java:102)
|
The above error occurs most commonly when the CAS client ticket validator attempts to contact the CAS server and is presented a certificate whose CN does not match the fully-qualified host name of the CAS server. There are a few common root causes of this mismatch:
- CAS client misconfiguration (usually a bad serverName init param)
- Complex multi-tier server environment (e.g. clustered CAS server)
- Host name too broad for scope of wildcard certificate
Wildcard Certificates
JSSE support for wildcard certificates is limited to hosts strictly in the same domain as the wildcard. For example, a certificate with CN=*.vt.edu matches hosts a.vt.edu and b.vt.edu, but not a.b.vt.edu.
Simplified Java SSL Guide
...