CoSign: Collaborative Single Sign-On  

cosign-discuss at
general discussion of cosign development and deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unknown CA

Sorry for the late reply, but Graeme was absolutely correct, this problem is caused by using a self-signed cert when trying to connect to cosignd. The quick and easy solution (for testing purposes) would be to also put a copy of the self-signed cert into cosignd's CA directory. That way cosign will be able to 'verify' the signer of the cert your service is presenting (because the cert is the signer, see?)

In response to another problem this evening, though, Mark Montague provided some stunningly thorough suggestions that would have made this easier to diagnose for you and really belong in our archive. First of all, as Mark has reminded us many times, start by verifying your cert:

openssl verify -CApath /var/cosign/CA -purpose sslclient /var/cosign/certs/mycert.cert

*but* verification will succeed on a self-signed cert even though mod_cosign won't like it at all (as you so aptly discovered for us, Sam). We can figure out why this is by going the next step:

( from here on in I'm simply quoting Mark )

Looking at the OpenSSL source code, error 144 reason 134 is
(see ssl/s3_clnt.c from OpenSSL if you're really interested).

So perhaps you don't have the necessary certs on your machine
to verify the server certificates used by the cosign server?
Let's try connecting to the cosign server without using mod_cosign
and see if the openssl program gives any better diagnostic messages.

First make sure you have OpenSSL version 0.9.7 or later:

    aegis# openssl version
    OpenSSL 0.9.7c 30 Sep 2003

If you do, run this command:

cat /dev/null | openssl s_client \
-connect \
-CApath /opt/certs/CA \
-cert /etc/httpd/ssl.crt/ \
-key /etc/httpd/ssl.key/ \
-starttls smtp

Between the lines of dashes below, I've included the output I get when I run
this command so you can compare it to what you get. I've XXXXX'ed out
the key, of course. Note that I've elected to use a UMWebCA cert
for my cosign-enabled web server instead of an InstantSSL or other
commercial cert. Not that this should matter as long as your
commercially-signed certificate has the "sslclient" purpose enabled
(see the openssl verify command above).

Read through your output and compare it to this. In Sam's case, there will be a line
that says:

verify error:num=19:self signed certificate in certificate chain

but you may very well see other errors, and those might help us figure out what is

------------------------------------------------------------------------ -----

cat /dev/null | /opt/SUNWconn/crypto/bin/openssl s_client -connect -CApath /opt/certs/CA -cert /opt/www/etc/cosign/certs/cosign-client-cert.pem -key /opt/www/etc/ssl.key/server.key -starttls smtp
depth=1 /C=US/ST=Michigan/L=Ann Arbor/O=University of Michigan/OU=ITCS/CN=UM Web CA/emailAddress=webmaster@xxxxxxxxx
verify return:1
depth=0 /C=US/ST=Michigan/L=Ann Arbor/O=University of Michigan/OU=ITCS/
verify return:1
Certificate chain
0 s:/C=US/ST=Michigan/L=Ann Arbor/O=University of Michigan/OU=ITCS/
i:/C=US/ST=Michigan/L=Ann Arbor/O=University of Michigan/OU=ITCS/CN=UM Web CA/emailAddress=webmaster@xxxxxxxxx
1 s:/C=US/ST=Michigan/L=Ann Arbor/O=University of Michigan/OU=ITCS/CN=UM Web CA/emailAddress=webmaster@xxxxxxxxx
i:/C=US/ST=Michigan/L=Ann Arbor/O=University of Michigan/OU=ITCS/CN=UM Web CA/emailAddress=webmaster@xxxxxxxxx
Server certificate
subject=/C=US/ST=Michigan/L=Ann Arbor/O=University of Michigan/OU=ITCS/
issuer=/C=US/ST=Michigan/L=Ann Arbor/O=University of Michigan/OU=ITCS/CN=UM Web CA/emailAddress=webmaster@xxxxxxxxx
No client certificate CA names sent
SSL handshake has read 1863 bytes and written 2536 bytes
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: AA5B7F3E856566F841AC00A4F45399900378DE554ECD4385787274E04A8911F9
Key-Arg : None
Start Time: 1092091691
Timeout : 300 (sec)
Verify return code: 0 (ok)
220 COokie SIGNer ready

------------------------------------------------------------------------ -----

I hope this is helpful,


On Jul 26, 2004, at 1:41 PM, Sam Noble wrote:

I suspect that the majority of my problem stems from my lack of experience
with OpenSSL.

The following error is plaguing me and hopefully somebody here will have
some insight:

Jul 21 14:23:50 machine cosignd[25423]: f_starttls: snet_starttls: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
Jul 21 14:23:50 machine cosignd[25423]: snet_getline: Connection reset by peer

I have configured cosignd with:


where weblogin-bundle.pem was generated by

cat weblogin.crt thawte.pem > weblogin-bundle.pem

Note that I saw the same thing when thawte.pem was in my CADIR (and
properly hashed) and I was using COSIGNCERT=/path/to/weblogin.crt

It is my belief that thawte.pem has the appropriate data inside because in
either case, using

openssl verify -purpose sslclient/sslserver -capath <proper path> weblogin.crt (or weblogin-bundle.pem with the *wrong* capath/cafile)


The apache2 cosign filter reports the following when configured with the
same parameters (and the same cert) on the same machine:

[Wed Jul 21 13:41:59 2004] [error] [client 134.X.X.X] snet_starttls: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

I don't really understand why I'm having MORE trouble using certificates
that I've paid for than I did with certificates that I signed myself.


... "In, as you say, the mud." ...

Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010