I also want to mention that, using curl POST, I'm getting attributes returned via the samlValidate endpoint.
-Alan On Friday, December 13, 2019 at 1:58:17 PM UTC-6, Alan S wrote: > > 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 >>> 'ST-2-Tx60JTe9ZiSCDUEphxs6upVgrfgSFACAS3' 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 <[email protected]> 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 | [email protected] >>> >>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/470a9b8a-091e-4dde-bf55-1965735d0f97%40apereo.org.
