Good morning;
I'm attempting to configure Cosign 3.1.2 on a RHEL 5.7 web server, and although
the Cosign block within the apache config file has been verified as
structurally and grammatically correct, I'm getting this error in an SLL error
log (a log that was specified in the ssl.conf):
[erro
On April 18, 2012 11:49 , "Taylor, Dion" wrote:
> [error] mod_cosign: snet_starttls: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>
> When I visit the website in question, I'm able to authenticate to Cosign, but
> then I'm taken to a "Service Temporarily Un
On Apr 18, 2012, at 11:49 AM, Taylor, Dion wrote:
> Good morning;
>
> I'm attempting to configure Cosign 3.1.2 on a RHEL 5.7 web server, and
> although the Cosign block within the apache config file has been verified as
> structurally and grammatically correct, I'm getting this error in an SLL
Hi,
Just my 2 cents: for RHEL the c_rehash tool is in the openssl-perl package
which is available in the "optional" software channel from Red Hat Network.
Regards,
--
Guus Houtzager | Project Resource Center | R21 Infrastructure Services
T. +31 30 689 10 51 | M. +31 6 27 159 035
http://www.nl.c
Thank you Guus, that was actually an earlier snag that I encountered;
/usr/sbin/cacertdir_rehash was present but initially it wasn't immediately
obvious how to track down c_rehash.
-
- Dion
-
-Original Message-
From: Houtzager, Guus [mailto:guus.houtz
Very helpful Mark, thank you. I have the umwebCA.pem and hash link, along with
the UM chain cert and root cert with their respective hash links (as provided
by UM webmaster), and the Geotrust intermediate cert with hash link.
I tried the s_client connection that you and Andrew referenced and got
This suggests to me that you've connected to the weblogin server just fine with
the key/cert pair you gave to s_client. The two output messages you mention
below are benign. To make sure cosignd is processing your commands, you can
enter "NOOP" and hit enter after the "500 Command EHLO unrecogni
This looks OK. Can you confirm (using something like Firefox's Live HTTP
Headers add-on) that the Set-Cookie contains the values you expect? After
you've been redirected to the global logout page, check your cookies to see
that the service cookie's actually invalidated.
andrew
On Apr 17, 2012
