Okay, the question that should be asked is, to quote the sociologist
Erving Goffman, "What the hell is going on?".
(please forgive if I tell you nothing new on ssl)
>verify depth is 0
>depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
>verify error:num=19:self signed certificate in certificate chain
>verify return:0
>97148:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:983:
ssl.el uses OpenSSL's s_client command to establish the ssl connection
to the desired remote endpoint. The purpose of using ssl is to secure
the communication between server and client. Securing means two
things: Encrypt the session information so only server and client can
decipher it and, as a prerequisite, ensure that (in this case) the
client is /really/ talking to the server he want's to talk to.
The failing occurs in this prequisite: The client cannot verify the
authenticity of the remote server. The identity of the endpoint is
given by a digital certificate that belongs to the endpoint only. To
check the identity the client has to have the relation "certificate X
belongs to ssl.server.xxx" established outside the ssl connection.
That's how the checking works: "Is the certificate that is presented
by the remote server /truly/ the identity of ssl.server.xxx?".
Know add some more complexity: It is not reasonable to assume a client
being able to obtain and check all certificates it may encounter in
it's lifespan. Obtaining and checking would literally mean getting a
copy of every certificate, call the company or issuer of the
certificate and compare the checksum (fingerprint) of your copy with
their original.
Therefor there is the concept of a certification authority or CA: The
CA does the checking and /digitally signs/ the servers certificate.
The client in turn now can rely on this CA's signature: You accept the
CA, so you accept all certificates signed by the CA.
Now you can have not just one CA but a CA, a sub-CA, a sub-sub-CA
etc. and you build a chain of trust: that's what the "verify depth" is
about. Setting it to zero /would/ mean: don't check at all but due to
a bug (?) in openssl it performs the checking even if you use depth 0
(see man s_client).
I am not that familar with OpenSSL's output but this line:
>depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
^^^^^^^
Looks like the certificate of ssl.server.xxx is at the end of a trust
chain of 2 other certificates. The question is: who's on the top of
the chain?
You can try this, for example on google:
,----
| david@thinkpad ~ % openssl s_client -verify 3 -host imap.googlemail.com -port 993 -showcerts
`----
and you get a list of the complete trust chain for goolgemail
(stripped the certificate information):
,----
| CONNECTED(00000004)
| depth=1 /C=US/O=Google Inc/CN=Google Internet Authority
| verify error:num=20:unable to get local issuer certificate
| verify return:0
| ---
| Certificate chain
| 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.googlemail.com
| i:/C=US/O=Google Inc/CN=Google Internet Authority
| -----BEGIN CERTIFICATE-----
| [...]
| -----END CERTIFICATE-----
| 1 s:/C=US/O=Google Inc/CN=Google Internet Authority
| i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
| -----BEGIN CERTIFICATE-----
| [...]
| -----END CERTIFICATE-----
| ---
| Server certificate
| subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.googlemail.com
| issuer=/C=US/O=Google Inc/CN=Google Internet Authority
`----
That's the complete trust chain for imap.googlemail.com.
This means: If you happen to have the first certificate (depth=1) you
trust the last one because the last is signed by the second that is
signed by the first, the one you trust.
Fortunatly operating systems ship with a list of common "depth 1"
certificates, e.g. in /etc/ssl/certs. If I point openssl to this
directory using the -CApath switch:
,----
| david@thinkpad ~% openssl s_client -verify 3 -host imap.googlemail.com -port 993 -showcerts
|
| CONNECTED(00000004)
| depth=2 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
| verify return:1
| depth=1 /C=US/O=Google Inc/CN=Google Internet Authority
| verify return:1
| depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.googlemail.com
| verify return:1
`----
It happily verifies the complete chain (no verify error).
What you should try:
1. try to set the -CApath to where the bundle of preinstalled
certificates are
2. if this does not work, get the whole trust chain and look who's
on the top; if you cannot get the top-certificate by yourself
(e.g. asking the responsible person (whoever this might be))
HTH
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... maus.david@gmail.com
Attachment:
pgpx8aa5eqyMd.pgp
Description: PGP signature