Hi,
Just thank you - is an understatement, I completely admired with your
prompt response.
Based on your reply, I realized device was having a certificate that
is not matching a common root certificate with my server root
certificate (issuer was found to be different when observed the
details of it). Now i could perform https communication after
reloading correct ca certificates on device.
And I pointed pound config to look in correct certificate location helped! :-)
Thanks again, Your help is lot appreciated.
On 4/19/12, Jakob Bohm <jb-open...@wisemo.com> wrote:
> On 4/18/2012 8:47 PM, Appaji Yelamarthi wrote:
>> Hi there,
>> I'm facing 'Unkown CA' error during ssl handshake messages between
>> client(a network device) and server (pound).
>> sorry am not much familiar with openssl library usage but setting up
>> the pound reverse proxy which use openssl 0.9.8 on redhat linux.
> First off: "Unknown CA" error from server to client means that *client*
> certificate was signed by a CA which the SSL server was not configured
> to trust as an issuer of client certificates.
>> Done a lot of googling but no clear pointers were available yet.
>> Please can anybody mention all possible list of causes behind this
>> error.
>> This error is (thrown by server to client) observed in wireshark. This
>> happens immediately after client sends 'Finished'.
>>
>> Observation:
>> A wireshark debug log (using RSA private key) shows me client and
>> server agreed on cipher sent by client cipher list(1).
>> However openssl cipher command (one of 'AES' i think
>> TLS_DH_RSA_WITH_AES_128_CBC_SHA agreed by client/server) doesn't show
>> up this cipher. Am not suspecting (so eagerly) unknown ca error is
>> just because of this as i may have also done any other mistake.
>>
>> Hence mentioning all steps followed here. Pls correct me in case.
>> 1. Generated private key (not passphrase protected), csr using openssl
>> with a copy of openssl.cnf in a custom directory. this cnf file barely
>> filled with required fields (like OU, CN etc) in 2 mandatory sections
>> as mentioned in man age.
> OK.
>> 2. Received tgz which contains ca, intermediate and server certificate
>> (for test purpose which have a month expiry) from own organization CA.
> OK.
>> 3. As part of setup of this certificates on server, struggling while
>> following not so clear man page of pound and openssl.
> Will try to help you a bit here:
>> 4. Appended private key to server certificate
> OK
>> 5. Appended intermediate cert to ca cert to make chain cert.
> Yes, the file for the server cert as used by pound server should be simply
>
> # cat serverCert.pem ServerKey.pem
> ServerIssuingIntermediaryCACert.pem ServerIssuingCACert.pem >
> /etc/pound/pound.pem
>
>> 6. Verified all certificates using openssl verify command which says
>> OK post copying ca, oem cert (and hash'd.0 ) to openssl certs
>> directory. Here tried various things hashing on individual ca, oem
>> within certs directory so root or ca certificate can be locatable and
>> trustable! There was no clear documentation on this crucial step. Not
>> sure if this hash has to happen on chained cert only or on individual
>> ca, intermediate(oem) certificate only as mentioned in other sources.
> None of this hashing is needed for the *server* cert on the *server*.
>
> And pound won't use it for client certs either, see below
>> 7.Then applied openssl -addtrust command on ca certificate.
> Not useful,
>
> -addtrust is an option to various openssl utility subcommands commands
> and only affects that one run of the openssl command.
>> 8.Now tested using pound https listener with all certs, trust
>> available/a network device which makes https request to pound https
>> listener which use the server and ca (or chain!) certificate in ssl
>> certs directory!!
> Pound takes the server CA certificate from pound.pem and nowhere else,
> there is no point putting it in the openssl cert directory (for server
> cert purposes).
>> All these tests resulted unknown ca error whenever client certificate
>> verification is enabled.
> Because none of those steps configure what *client* certificates to trust.
>> 9. Also tested various other methods unsuccessfully like
>> openssl s_server/s_client and
>> s_server/browser. Though these are not going to be effective as client
>> certificate will not be sent by them as pound ssl listener demands !!
> According to the man page for 2.5 (taken from a Debian system, hope
> it is the same for RedHat), the procedure to configure client
> certificate auth with pound is as follows:
>
> 1. Figure out (from your usage scenario) which Intermediary and top CAs
> issue client certificates you want to trust.
>
> For example if you want to trust all client certificates issued by
> IntermediaryCA1 or IntermediaryCA2, but not any other Client certificates
> issued by other intermediary CAs below that same local or public CA, the
> answer is "IntermediaryCA1 and IntermediaryCA2".
>
> As another example, if you want to trust any client certificates issued
> directly or indirectly from OEMCA1 or PublicCA2, the answer is
> "OEMCA1 and PublicCA2".
>
> 2. Figure out if there are any Intermediary CAs in the chain between the
> CAs from step 1 and the client certificates, but that the clients forget
> to send (some clients are broken that way). There may be none of these,
> for the example, lets say those are "IntermediaryCA3 and IntermediaryCA4".
>
> 3. Figure out the root CAs and Intermediary CAs that issued the
> CA certificates from step 1 (other than the CAs from step 1 themselves).
> There may be none of these, for the example, lets say those are "RootCA3
> and IntermediaryCA5"
>
> 4. Create a file of the PEM certificates from step 1
>
> # cat IntermediaryCA1.pem IntermediaryCA2.pem > /etc/pound/clientCAs.pem
>
> 5. Create a file of the PEM certificates from step 1, 2 and 3
>
> # cat /etc/pound/clientCAs.pem IntermediaryCA3.pem IntermediaryCA4.pem
> RootCA3.pem IntermediaryCA5.pem > /etc/pound/clientVerifyCAs.pem
>
> 6. Set up a cron job that regularly downloads the CRLs for all the
> CAs mentioned in step 1, 2 and 3, then does something like
>
> for crl in /var/lib/pound/crls/*.crl ; do
> if openssl crl -in ${crl} -CAfile /etc/pound/clientVerifyCAs.pem
> -noout ; then
> openssl crl -in ${crl} -outform PEM -out ${crl}.okpem
> fi
> done
> cat /var/lib/pound/crls/*.crl.okpem > /var/lib/pound/clientCRLs.pem
>
> 7. In pound.cfg, add these lines under your HTTPS listener
>
> Cert "/etc/pound/pound.pem"
> # Next line says refuse clients with no client certificates and verify
> # client certificates to depth 9
> ClientCert 2 9
> CAlist "/etc/pound/clientCAs.pem"
> VerifyList "/etc/pound/clientVerifyCAs.pem"
> CRLlist "/var/lib/pound/clientCRLs.pem"
>
>
>>
>> I see the wireshark showing client sending hello, server hello done,
>> client sends its certificate for verification, cypher spec, key
>> exchange etc and finally mac done and sending 'Finished' from its
>> final part of handshake. However Server immediately sends this unknown
>> ca error to client.
>> So assuming either server not configured with ca or chain properly or
>> not locatable or not available in any trust store (should i have to
>> use java like keytool to store and point to?). Here different sites
>> mentioned different things but not sure on any.
>> Another source mentioned client certificate which contain public key
>> should be stored in server in advance so server can trust who is
>> communicating in advance(to counter part man in the middle attack).
>> Also another suggestion to add crl to ca certificate.
>> Checked other possible issues like date/time differences, permissions,
>> openssl big default trust cert file is appended with our root
>> certificate etc.
>> Not sure on how to verify 'extended' part of client certificate if it
>> contains required attribute/values.
>>
>> Does installation of root or chain certificate involve just copying
>> files into ssl certs directory? Should we mandatorily use openssl.cnf
>> removing comments on critical sections and init!?
>> A help or pointers will be greatly appreciated. Pls mention any master
>> list of causes for this error?
>>
>> Need to mention client(device) certificate is also created by own
>> organization as part of factory installation. So not doubting on trust
>> or other part of certificate information.
>>
>>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
> Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
