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.houtza...@capgemini.com] Sent: Wednesday, April 18, 2012 1:12 PM To: emailfwd-markmont; Taylor, Dion Cc: cosign-discuss@lists.sourceforge.net Subject: RE: [Cosign-discuss] Cosign 3.1.2 SSL Error in Apache 2.2.3 on RHEL 5.7 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.capgemini.com > -----Original Message----- > From: Mark Montague [mailto:m...@catseye.org] > Sent: woensdag 18 april 2012 6:31 > To: Taylor, Dion > Cc: cosign-discuss@lists.sourceforge.net > Subject: Re: [Cosign-discuss] Cosign 3.1.2 SSL Error in Apache 2.2.3 > on RHEL 5.7 > > On April 18, 2012 11:49 , "Taylor, Dion" <di...@umich.edu> 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 Unavailable" page. > > > This error occurs when mod_cosign is unable to verify the certificate > used by your institution's central weblogin servers. Make sure you > have the root and any intermediate CA certificates installed for the > CA that signed the certificate used by your central weblogin server. > Also make sure you have a hash symlink for that certificate in the > same directory. > > Under Red Hat Enterprise Linux, I usually install *all* certificates, > including the server's SSL certificate and all CA certificates, in > /etc/pki/tls/certs > > For example: > > [root@schrodingers certs]# ls -l > total 1224 > lrwxrwxrwx. 1 root root 27 Nov 10 12:48 081aa176.0 -> > ecat-test.lsa.umich.edu.crt > lrwxrwxrwx. 1 root root 13 Nov 10 12:48 381ce4dd.0 -> ca-bundle.crt > lrwxrwxrwx. 1 root root 11 Mar 20 03:40 5cc1e784.0 -> umwebCA.pem > lrwxrwxrwx. 1 root root 20 Nov 10 12:48 9ef5f911.0 -> > InCommonServerCA.crt > lrwxrwxrwx. 1 root root 30 Nov 10 12:48 a9e4b937.0 -> > schrodingers.lsa.umich.edu.crt > -rw-r--r--. 1 root root 571442 Apr 7 2010 ca-bundle.crt -rw-r--r--. > 1 root root 651075 Apr 7 2010 ca-bundle.trust.crt > -rw-r--r--. 1 root root 2240 Nov 10 12:47 ecat-test.lsa.umich.edu.crt > lrwxrwxrwx. 1 root root 13 Nov 10 12:48 ecfd737a.0 -> localhost.crt > -rw-r--r--. 1 root root 1712 Nov 10 12:39 InCommonServerCA.crt > -rw-------. 1 root root 1212 Oct 21 13:23 localhost.crt > -rwxr-xr-x. 1 root root 610 Mar 19 12:28 make-dummy-cert > -rw-r--r--. 1 root root 2242 Mar 19 12:28 Makefile > -rw-r--r--. 1 root root 2244 Nov 10 12:47 > schrodingers.lsa.umich.edu.crt > -rw-r--r--. 1 root root 1334 Mar 19 10:56 umwebCA.pem > [root@schrodingers certs]# > > The best way to create the hash symlinks is to run "c_rehash > /path/to/directory/containing/certificates". The c_rehash script is > distributed with the source code of OpenSSL, but it is not included in > the RPM for OpenSSL for some (many?) versions of Red Hat Enterprise > Linux. If you don't have c_rehash, an alternative that will work as > long as you don't have any hash collisions is: > > cd /etc/pki/tls/certs > for i in *.pem *.crt *.cert ; do > ln -s $i `openssl x509 -hash -noout -in $i`.0 done > > I then use the following CosignCrypto directive: > > CosignCrypto > /etc/pki/tls/private/ecat-test.lsa.umich.edu.key > /etc/pki/tls/certs/ecat-test.lsa.umich.edu.crt /etc/pki/tls/certs > > At my institution, incidentally, the certificate used by my central > weblogin servers is in the file umwebCA.pem in the directory listing > above. > > You can verify things (both the correct diagnosis of the problem as > well as potential fixes) by following the instructions for the FAQ "My > certificate is verified, but I'm still getting vague and unhelpful SSL > errors. What else can I do?" at > > http://webapps.itcs.umich.edu/cosign/index.php/Cosign_Wiki:CosignFAQ#C > o > nfiguration > > > I hope this helps. > > -- > Mark Montague > m...@catseye.org > > > ---------------------------------------------------------------------- > - > ------- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second resolution > app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Cosign-discuss mailing list > Cosign-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cosign-discuss This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
