...
PKIX path building errors are by far the most common SSL errors reported on the cas-user@lists.jasig.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
| Code Block | ||
|---|---|---|
| ||
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present |
...
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.
...
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 -----BEGIN CERTIFICATE-----, it is PEM-encoded and needs to be converted to DER encoding. The following example demonstrates a conversion command using OpenSSL.
...