Further research suggests this might not be an issue with the signing authority; were the weblogin or other certs recently upgraded to SHA-2, or the SHA256 hash? If so, what is our fix, given the errors below?
— Kai On Dec 14, 2015, at 10:07 AM, Kai Lanz <l...@stanford.edu> wrote: > Starting Sunday, Dec. 13, at about 4am, we started getting errors from > webauth on our department server, Pangea. > We have the following in apache’s error_log: > > [Sun Dec 13 17:00:01 2015] [error] mod_webauth: curl_easy_perform: error(35): > error:0D0890A1:asn1 encoding routines:func(137):reason(161) > [Sun Dec 13 17:00:01 2015] [error] mod_webauth: mwa_get_service_token: > couldn't get new service token from webkdc > [Sun Dec 13 17:00:01 2015] [emerg] mod_webauth: mwa_get_service_token FAILD!! > [Sun Dec 13 17:00:01 2015] [emerg] mod_webauth: redirect_request_token: no > service token, denying request > [Sun Dec 13 17:00:01 2015] [warn] mod_webauth: failure_redirect: no URL > configured > > Googling for these errors turns up a post from Russ Allbery in 2013 which > says these symptoms occur when the > campus KDC admins renew their SSL cert, and the new cert uses a different > signing authority from the old one. > > Was there an update to the SSL certs on our KDCs over the weekend? It has > broken webauth on our server; we > rely on webauth pretty extensively, and a lot of our pages are now > inaccessible. If Russ’s old post is correct, what > is the new signing authority? How can I incorporate that into our config on > Pangea to fix this? (I have a ca-bundle.crt > file in /usr/share/ssl/certs which I could update if I knew who the new > signer is.) > > — Kai Lanz > Senior System Administrator
