Okay, via curl, this looks good (see the response below), and I'm getting 
the authenticated username returned. So, this is a good step forward in 
troubleshooting. Do you have advice for debugging the Apache module? I'm 
not sure what would cause it to be so "quiet."

-Alan

Enter service ticket ID: ST-3-AVml3Z3uyCXQCJ8-xpO9C4OV5sQSFACAS3
*   Trying CAS_SERVER_IP...
* Connected to CAS_SERVER (CAS_SERVER_IP) port 443 (#0)
* found 3 certificates in /etc/ssl/InCommon/chain.crt
* found 582 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
*      server certificate verification OK
*      server certificate status verification SKIPPED
*      common name: CAS_SERVER (matched)
*      server certificate expiration date OK
*      server certificate activation date OK
*      certificate public key: RSA
*      certificate version: #3
*      subject: CERT_INFO
*      start date: Wed, 09 Oct 2019 00:00:00 GMT
*      expire date: Thu, 08 Oct 2020 23:59:59 GMT
*      issuer: C=US,ST=MI,L=Ann Arbor,O=Internet2,OU=InCommon,CN=InCommon 
RSA Server CA
*      compression: NULL
* ALPN, server did not agree to a protocol
> GET /cas/serviceValidate?service=https%3a%2f%2fAPP_SERVER%2fauth%2f&ticket
=ST-3-AVml3Z3uyCXQCJ8-xpO9C4OV5sQSFACAS3 HTTP/1.1
> Host: CAS_SERVER
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 
< Cache-Control: no-store
< Pragma: 
< Expires: 
< Strict-Transport-Security: max-age=15768000 ; includeSubDomains
< X-Content-Type-Options: nosniff
< X-Frame-Options: DENY
< X-XSS-Protection: 1; mode=block
< Content-Type: application/xml;charset=UTF-8
< Content-Language: en-US
< Transfer-Encoding: chunked
< Vary: Accept-Encoding
< Date: Fri, 13 Dec 2019 19:42:02 GMT
< 
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationSuccess>
        <cas:user>MY_USER_NAME</cas:user>
        </cas:authenticationSuccess>
</cas:serviceResponse>
* Connection #0 to host CAS_SERVER left intact


On Friday, December 13, 2019 at 12:05:48 PM UTC-6, Alan S wrote:
>
> Ray--I requested an update to the ticket TTL and will report back with the 
> results. Thanks!
>
> -Alan
>
> On Friday, December 13, 2019 at 11:17:01 AM UTC-6, rbon wrote:
>>
>> Alan,
>>
>> When running manual tests, you can increase the ST time timeout, 
>> https://apereo.github.io/cas/6.1.x/ticketing/Configuring-Ticket-Expiration-Policy.html#service-ticket-policies
>> By default it only lasts 10 seconds, which may not be enough time for you 
>> to copy and paste.
>>
>> Ray
>>
>> On Fri, 2019-12-13 at 07:57 -0800, Alan S wrote:
>>
>> Thank you, David. If I include the service and ticket, with the cert 
>> chain specified, this is the response. Note that I used the ticket from the 
>> browser login attempt to test this--do I need to initiate the login request 
>> via curl? I also would think a validation error would show up in my logs, 
>> but, after the 'CAS Service' line, it simply stops generating auth_cas 
>> logs. I'll contact our CAS server team to request server logs from these 
>> connections.
>>
>> -Alan
>>
>> curl -v --cacert /etc/ssl/InCommon/chain.crt https:
>> //CAS_SERVER/cas/serviceValidate?service=https%3a%2f%2fAPP_HOST%2fauth%2f'&'ticket=ST-2-Tx60JTe9ZiSCDUEphxs6upVgrfgSFACAS3
>>
>>
>> *   Trying CAS_SERVER_IP...
>> * Connected to CAS_SERVER (CAS_SERVER_IP) port 443 (#0)
>> * found 3 certificates in /etc/ssl/InCommon/chain.crt
>> * found 582 certificates in /etc/ssl/certs
>> * ALPN, offering http/1.1
>> * SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
>> ''' SNIP! '''
>> * ALPN, server did not agree to a protocol
>> > GET /cas/serviceValidate?service=https%3a%2f%2fAPP_HOST%2fauth%2f&
>> ticket=ST-2-Tx60JTe9ZiSCDUEphxs6upVgrfgSFACAS3 HTTP/1.1
>> > Host: CAS_SERVER
>> > User-Agent: curl/7.47.0
>> > Accept: */*
>> > 
>> < HTTP/1.1 200 
>> < Cache-Control: no-store
>> < Pragma: 
>> < Expires: 
>> < Strict-Transport-Security: max-age=15768000 ; includeSubDomains
>> < X-Content-Type-Options: nosniff
>> < X-Frame-Options: DENY
>> < X-XSS-Protection: 1; mode=block
>> < Content-Type: text/html;charset=UTF-8
>> < Content-Language: en-US
>> < Transfer-Encoding: chunked
>> < Vary: Accept-Encoding
>> < Date: Fri, 13 Dec 2019 15:40:32 GMT
>> < 
>> <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
>>     <cas:authenticationFailure code="INVALID_TICKET">Ticket 
>> &#39;ST-2-Tx60JTe9ZiSCDUEphxs6upVgrfgSFACAS3&#39; not 
>> recognized</cas:authenticationFailure>
>> </cas:serviceResponse>
>> * Connection #0 to host CAS_SERVER left intact
>>
>>
>>
>> On Thursday, December 12, 2019 at 10:06:26 PM UTC-6, dhawes wrote: 
>>
>> On Thu, 12 Dec 2019 at 18:09, Alan S <sco...@sfasu.edu> wrote: 
>> > 
>> > Still wrestling with this, I'm now specifying just the serviceValidate 
>> endpoint to remove any possible problems with SAML attribute delivery. My 
>> Apache configuration now looks like this: 
>> > 
>> > LoadModule auth_cas_module /usr/lib/apache2/modules/mod_auth_cas.so 
>> > 
>> > CASCookiePath /var/cache/apache2/mod_auth_cas/ 
>> > CASLoginURL https://CAS_SERVER/cas/login 
>> > CASValidateURL https://CAS_SERVER/cas/serviceValidate 
>> > CASDebug On 
>> > 
>> > <LocationMatch ^/auth/> 
>> >     AuthType CAS 
>> >     AuthName "Autentication required" 
>> >     CASAuthNHeader CAS-User 
>> >     Require valid-user 
>> > </LocationMatch> 
>> > 
>> > My logs never show a response validation: 
>> > 
>> > [Thu Dec 12 16:54:20.821632 2019] [auth_cas:debug] [pid 20232] 
>> mod_auth_cas.c(2675): entering check_vhost_config() 
>> > [Thu Dec 12 16:54:20.904208 2019] [auth_cas:debug] [pid 20233] 
>> mod_auth_cas.c(2675): entering check_vhost_config() 
>> > [Thu Dec 12 16:54:29.432630 2019] [auth_cas:debug] [pid 20238] 
>> mod_auth_cas.c(2159): [client CLIENT_IP:44734] Entering cas_authenticate() 
>> > [Thu Dec 12 16:54:29.432643 2019] [auth_cas:debug] [pid 20238] 
>> mod_auth_cas.c(610): [client CLIENT_IP:44734] CAS Service 
>> 'https%3a%2f%2fAPP_HOST%2fauth%2f' 
>> > [Thu Dec 12 16:54:29.432652 2019] [auth_cas:debug] [pid 20238] 
>> mod_auth_cas.c(558): [client CLIENT_IP:44734] entering getCASLoginURL() 
>> > [Thu Dec 12 16:54:29.432663 2019] [auth_cas:debug] [pid 20238] 
>> mod_auth_cas.c(535): [client CLIENT_IP:44734] entering getCASGateway() 
>> > [Thu Dec 12 16:54:29.432671 2019] [auth_cas:debug] [pid 20238] 
>> mod_auth_cas.c(625): [client CLIENT_IP:44734] entering redirectRequest() 
>> > [Thu Dec 12 16:54:29.432681 2019] [auth_cas:debug] [pid 20238] 
>> mod_auth_cas.c(637): [client CLIENT_IP:44734] Adding outgoing header: 
>> Location: 
>> https://CAS_SERVER/cas/login?service=https%3a%2f%2fAPP_HOST%2fauth%2f 
>> > [Thu Dec 12 16:54:34.729642 2019] [auth_cas:debug] [pid 20235] 
>> mod_auth_cas.c(2159): [client CLIENT_IP:44736] Entering cas_authenticate(), 
>> referer: 
>> https://CAS_SERVER/cas/login?service=https%3a%2f%2fAPP_HOST%2fauth%2f 
>> > [Thu Dec 12 16:54:34.729659 2019] [auth_cas:debug] [pid 20235] 
>> mod_auth_cas.c(682): [client CLIENT_IP:44736] Modified r->args (now ''), 
>> referer: 
>> https://CAS_SERVER/cas/login?service=https%3a%2f%2fAPP_HOST%2fauth%2f 
>> > [Thu Dec 12 16:54:34.729749 2019] [auth_cas:debug] [pid 20235] 
>> mod_auth_cas.c(1832): [client CLIENT_IP:44736] entering 
>> getResponseFromServer(), referer: 
>> https://CAS_SERVER/cas/login?service=https%3a%2f%2fAPP_HOST%2fauth%2f 
>> > [Thu Dec 12 16:54:34.729853 2019] [auth_cas:debug] [pid 20235] 
>> mod_auth_cas.c(610): [client CLIENT_IP:44736] CAS Service 
>> 'https%3a%2f%2fAPP_HOST%2fauth%2f', referer: 
>> https://CAS_SERVER/cas/login?service=https%3a%2f%2fAPP_HOST%2fauth%2f 
>> > [Thu Dec 12 16:54:35.031085 2019] [auth_cas:debug] [pid 20236] 
>> mod_auth_cas.c(2159): [client CLIENT_IP:44754] Entering cas_authenticate(), 
>> referer: 
>> https://CAS_SERVER/cas/login?service=https%3a%2f%2fAPP_HOST%2fauth%2f 
>> > [Thu Dec 12 16:54:35.031100 2019] [auth_cas:debug] [pid 20236] 
>> mod_auth_cas.c(682): [client CLIENT_IP:44754] Modified r->args (now ''), 
>> referer: 
>> https://CAS_SERVER/cas/login?service=https%3a%2f%2fAPP_HOST%2fauth%2f 
>> > [Thu Dec 12 16:54:35.031149 2019] [auth_cas:debug] [pid 20236] 
>> mod_auth_cas.c(1832): [client CLIENT_IP:44754] entering 
>> getResponseFromServer(), referer: 
>> https://CAS_SERVER/cas/login?service=https%3a%2f%2fAPP_HOST%2fauth%2f 
>> > [Thu Dec 12 16:54:35.031241 2019] [auth_cas:debug] [pid 20236] 
>> mod_auth_cas.c(610): [client CLIENT_IP:44754] CAS Service 
>> 'https%3a%2f%2fAPP_HOST%2fauth%2f', referer: 
>> https://CAS_SERVER/cas/login?service=https%3a%2f%2fAPP_HOST%2fauth%2f 
>> > 
>> > Any idea what could be causing this "Secure Connection Failed" issue on 
>> a 5.3 server connection? (I've tried connecting on the latest mod_auth_cas 
>> master and v1.2 tag.) 
>>
>> I'd expect to see a CURL error or the validation response printed out. 
>>
>> Are there any logs on your CAS server that show the service validation 
>> from mod_auth_cas? Can you ensure that you can "curl 
>> https://CAS_SERVER/cas/serviceValidate"; from the host running Apache 
>> and mod_auth_cas? 
>>
>> -- 
>>
>> Ray Bon
>> Programmer Analyst
>> Development Services, University Systems
>> 2507218831 | CLE 019 | rb...@uvic.ca
>>
>> I respectfully acknowledge that my place of work is located within the 
>> ancestral, traditional and unceded territory of the Songhees, Esquimalt and 
>> WSÁNEĆ Nations.
>>
>

-- 
- 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+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/22563189-f8ea-4e4f-8706-966f4b13abfd%40apereo.org.

Reply via email to