Announcement Announcement Module
No announcement yet.
Non-Localhost in casProxyTicketValidator Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Non-Localhost in casProxyTicketValidator


    I have CAS working perfectly on a single server, as long as the casValidate property of the casProxyTicketValidator uses "localhost":

    <bean id="casProxyTicketValidator"
    		<property name="casValidate">
    		<property name="serviceProperties">
    			<ref local="serviceProperties" />
    		<property name="trustStore"><value>&#91;my location&#93;</value></property>
    However, if I put the ip address of the server in place of "localhost" it fails to authenticate.
    I've tried creating the SSL certificate with the ip address as the name, in stead of localhost, but that doesn't seem to work.

    Any ideas?


  • #2
    Re: Non-Localhost in casProxyTicketValidator

    How does it fail? Do you have any other information to go on?



    • #3
      Yeah, it says

      DEBUG [net.sf.acegisecurity.ui.AbstractProcessingFilter] Authentication request failed: net.sf.acegisecurity.AuthenticationServiceExceptio n: HTTPS hostname wrong: should be <[my ip address]>

      I think that it gets that info from the casProxyTicketValidator url. And it makes it sound as though that doesn't match what is the "first and last name" listed in my keystore. However, I've recreated the certificate and imported several times using the ip address as the common name, and it still doesn't work. But when I re-create the cert using localhost as the common name, and change the url in the casProxyTicketValidator to use localhost, everything works.



      • #4
        I'd imagine the "CN" in your SSL certificate is not the IP address, so your keystore is rejecting it when you do the callback. Could you use a DNS hostname that matches the name presented in the SSL certificate?


        • #5
          See that's what it looks like to me as well. However, I've re-created the cert and keystore several times, per the contacts example, using the IP. When I view the cert that is received from the browswer, it shows the IP address. Yet the error is saying that it isn't right. <shrug>

          Is there a different way to create the cert what would allow it to accept an IP address?



          • #6
            Not that I'm aware of. I've always used hostnames, editing my local hosts file if I needed to test against a fake hostname.


            • #7
              Hello everybody,

              I am a new Acegi Security user and I have the same problem that jpwinans explains.

              My acegi-cas web app is running on:
              • JDK 1.5
                Tomcat 5.5.9
                Acegi Security 0.8.2
                CAS 2.0.12
                Windows XP

              First, I created the SSL certificate with the CN as localhost and the application works if you where accessing it from the same machine, but from another machine it did not work, I got

              The connection was refused when attempting to contact localhost&#58;8443
              Then I created a new SSL certificate with the CN as the IP address ( of the machine where Tomcat is running. Then the application did not work accessing it from the local machine nor from another one. And we got the same exception as jpwinans:

              &#91;DEBUG,AbstractProcessingFilter,http-8443-Processor22&#93; Authentication request failed&#58; net.sf.acegisecurity.AuthenticationServiceEx
              ception&#58; HTTPS hostname wrong&#58;  should be <>
              I want to know if somebody has found a solution for this problem specially in windows.

              Thank you in advance


              • #8
                What do you have set against your CasProxyTicketValidator.casValidate property? It should be https://properHostName:8443/cas/proxyValidate, not an IP address. I have never seen this problem before, except in connection with the earlier post. Have you tried taking Acegi Security out of the equation? ie: Using the stock-standard CAS client to validate a ticket from your CAS server and confirming the client is able to validate successfully?


                • #9
                  This thread has tips towards the bottom that may help troubleshoot:
                  Last edited by robyn; May 16th, 2006, 03:16 AM.