ignore TLS hostname verification (SSLPeerUnverifiedException)?

[Baron Fujimoto]

This isn't strictly a CAS issue, but we're encountering it trying to test CAS so I'm hoping someone may be able to offer suggestions.

We have a disaster recovery (DR) instance of our login stack that includes CAS (which uses a DR instance of LDAP). These instances have hostnames that follow a convention something like, dr-cas.example.edu and dr-ldap.example.edu. However, they use TLS certificates that use the non dr- versions of their hostnames, e,g, cas.example.edu and ldap.example.edu. The idea being that in the event we actually need to make use of the DR instance of the CAS/LDAP login stack, DNS changes would point cas.example.edu to dr-cas.example.edu, and ldap.example.edu to dr-example.edu.

This presents a challenge though to test the DR instance of our login stack without making the aforementioned DNS changes.

When CAS is started, it throws an exception:

Caused by: javax.net.ssl.SSLPeerUnverifiedException: Hostname verification failed for dr-ldap.example.edu using [org.ldaptive.ssl.HostnameVerifierAdapter@20...63::hostnameVerifier=org.ldaptive.ssl.DefaultHostnameVerifier@41...82]

Is there a way to get CAS to temporarily disable or ignore hostname verification via a property or Java option so that we can confirm things are otherwise working as expected? Any suggestions would be appreciated.

--

Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

[Carl Waldbieser]

Baron,

Couldn't you just put a subject alternative names on the certificate to include both the DR name and the production service name?

Thanks,

Carl Waldbieser

ITS

Lafayette College

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAjLUL16hZqpddPZv2q4-q6JeC1xEK7FpDS_c8SUJnyt0i84EA%40mail.gmail.com.

[Baron Fujimoto]

Hmm, maybe? But then wouldn't we have to update all the certs in use? I was hoping for something we could just enable temporarily that would allow us to test sufficiently to give us enough confidence that it generally works as expected.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CALt4NbPiQvbGxEprZ%3DEFaS3h_3Ohy%2BV53vL-BxqqyFO%2Bzs1pMQ%40mail.gmail.com.

[Carl Waldbieser]

Well, you'd need to at least update all the DR certs in use.  The production service certs could be left alone until they expire, but you'd probably want to eventually consolidate those.

You can probably get ldaptive to ignore the hostname verification when your DR CAS client instance queries your DR LDAP service, but you could just configure it to use the DR LDAP service's current name if you just wanted to quickly verify the service starts up.  Presumably the DR DNS name will still be around during a fail over?

Thanks,

Carl Waldbieser

ITS

Lafayette College 

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAjLUL3SP%3DNzi1DYMhn-%2BgN2AQpUzDqqvWLg%2BKC4Cu%2BCM9qFuQ%40mail.gmail.com.

[Baron Fujimoto]

I should have thought of this sooner, but it appears I can fake it out with an entry in the dr-cas hosts file to point ldap.example.edu to the IP for dr-ldap.example.edu.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CALt4NbPvtvUxxFzJnhZtO2em5N6JGNzPOr4TKQ6pc8BTz002Dw%40mail.gmail.com.