Troubleshooting SSL Errors
This section contains the most often-cited SSL errors reported by the CAS server and CAS clients in typical CAS integration scenarios.
PKIX path building failed
PKIX path building errors are by far the most common SSL errors reported on the firstname.lastname@example.org mailing list. The problem here is that the CAS client does not trust the certificate presented by the CAS server; most often this occurs because of using a self-signed certificate on the CAS server. To resolve this error, import the CAS server certificate into the system truststore of the CAS client. If the certificate is issued by your own PKI, it is better to import the root certificate of your PKI into the CAS client truststore. See Import Trusted Certificate for examples of importing a trusted certificate into a Java truststore.
If you have multiple java editions installed on your machine, make sure that your app / web server is pointing to the correct jdk/jre version (The one to which the certificate has been exported correctly) One common mistake that occurs while generating self-validated certifcates is that the java_home might be different than that used by the server (especially if it is run within an IDE like Eclipse or Websphere)
No subject alternative names present
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
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:
It is also worth checking that the certificate your CAS server is using for SSL encryption matches the one the client is checking against. For example, if your CAS server's ticket validator URL is https://subdomain.correctdomain.com/<something> and you have accidentally configured Tomcat to use the certificate for *.wrongdomain.com in it's SSL connector. You will get a bad certificate warning in the browser on the login page to hint at a problem but you ignore that warning (because you are using self signed certificates during development) and continue. Ticket validation will then fail with "java.security.cert.CertificateException: No name matching subdomain.correctdomain.com found" because the public key the CAS server is providing is for *.wrongdomain.com. The CAS client looks for the *.wrongdomain.com certificate in cacerts and then tries to find a matching CN or alternate within that certificate. It will completely ignore the beautifully crafted *.correctdomain.com certificate you carefully imported into cacerts.
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.
The above error occurs mainly in Oracle JDK 7 CAS Server installations. In JDK7, SNI (Server Name Indication) is enabled by default. When the HTTPD Server does not send the correct Server Name back, the JDK HTTP Connection refuses to connect and the exception stated above is thrown.
To fix the issue, you must ensure your HTTPD Server is sending back the correct hostname. E.g. in Apache HTTPD, you must set the ServerAlias in the SSL vhost:
Alternatively, you can disable the SNI detection in JDK7, by adding this flag to the Java options of your CAS Servers' application server configuration:
Import Trusted Certificate
By default the Java system truststore is at $JAVA_HOME/jre/lib/security/cacerts. The certificate to be imported MUST be a DER-encoded file. If the contents of the certificate file are binary, it's likely DER-encoded; if the file begins with the text
Once the certificate file is properly in the DER-encoded format, it may be imported using the keytool command.
List Trusted Certificates
Alternatives to Sun keytool Utility
When All Else Fails
If you have read, understood, and tried all the troubleshooting tips on this page and continue to have problems, please perform an SSL trace and attach it to a posting to the email@example.com mailing list. An SSL trace is written to STDOUT when the following system property is set,