Andrew; sending "noop" got me the "250 cosign v3.1.2rc2" response. And your question is actually one that's been brought up before with our local Cosign support team. They had me configure the Cosign block within the apache config to point to a test server, which I did, but they detected connection attempts on the production server. Within the apache config I only have one enabled Cosign block with CosignHostname pointing to the test server.
I did also try s_client pointed at the production server, but got "getaddrinfo: Name or service not known connect:errno=0". However I remember our local support mentioning the need to add an exception of some sort, so that error may be a proper return. I liked Mark's thoughts about centralizing the certificates. This afternoon I'll place pem copies of all certs in cosign-ca-dir for the sake of Cosign and run c_rehash again. Feel free to let me know if there's something else I should be looking at in the interim. I actually just got more feed back on the structure of my Cosign block (the weblogin-test name not in the correct lines), so I may try that first. ________________________________________ From: Andrew Mortensen [and...@weblogin.org] Sent: Wednesday, April 18, 2012 3:27 PM To: Taylor, Dion Cc: emailfwd-markmont; cosign-discuss@lists.sourceforge.net Subject: Re: [Cosign-discuss] Cosign 3.1.2 SSL Error in Apache 2.2.3 on RHEL 5.7 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 unrecognized" message. You should get back something like: 250 cosign v<VERSION NUMBER> If that's working, are you sure you have mod_cosign talking to the same server as your s_client test? andrew On Apr 18, 2012, at 2:03 PM, Taylor, Dion wrote: > 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 a > "CONNECTED(00000003)" message, also a "didn't found starttls in server > response, try anyway..." message. Within the output was also "No client > certificate CA names sent" and "500 Command EHLO unregcognized". I didn't > want to regurgitate the entire output, but let me know if there's certain > pieces that hold important info. > > Could this be some misconfiguration between my ssl.conf parameters and the > certificates they reference? > (I have to step away from the office for a bit, so there will be a delay in > my replies) > > ----------------- > - Dion > ----------------- > > > -----Original Message----- > From: Mark Montague [mailto:m...@catseye.org] > Sent: Wednesday, April 18, 2012 12:31 PM > 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#Configuration > > > I hope this helps. > > -- > Mark Montague > m...@catseye.org > ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
