Well, you say:
the certs are proper in server and client
But at least one of the systems disagrees:
Received fatal alert: certificate_unknown
This message means that one party (you don't say whether you are showing client-side or server-side logs) received an explicit alert message from the server, of class "fatal" and value 46 (0x2E, aka "certificate_unknown"). As specified in the TLS 1.0 standard:
Some other (unspecified) issue arose in processing the
certificate, rendering it unacceptable.
The "other" means that it is not a problem of the certificate being expired or revoked, or using an unsupported cryptographic algorithm. There can be many causes for a received certificate being "unacceptable", foremost of which being the impossibility of building a valid chain from an a priori known trusted root CA down to the certificate itself (normally, systems should send an "unknown_ca" alert in that case, but many do not have such precision in reporting errors with certificates).
To further investigate the issue, you should:
Activate full logging on both client and server. You show logs from the system who received the alert message; you should have a look at the logs from the other system, who sent the alert message;
Verify the configuration of both systems, in particular, for the one who sent the alert message (i.e. not the one which threw the "received fatal alert" exception, but the other one) what trust anchors it is using to validate the peer's certificate;
Check what certificate chains the systems are actually sending. Since this occurs before the encryption is activated, the certificates ought to be visible to some network monitoring tool à la Wireshark. Notably, check the order: in SSL/TLS, the end-entity certificate comes first, then the CA which issued it, then the CA which issued that CA, and so on.
Remember too that client certificates make sense only as authentication, not as authorization. Even if the client sends a certificate that the server can validate with regards to a trusted root, this only tells to the server who is at the other end of the line. It is still up to the server to decide whether that specific client should be allowed to proceed or not. This normally entails mapping the client certificate to an identity or a role, e.g. by extracting some specific field from the certificate. This process is completely outside of the scope of TLS itself, but must still occur, so there is some software and, crucially, some configuration on the server side that you probably wish to check.
In the other direction (validation of the server's certificate by the client), the rules are specified in RFC 2818, at least in the context of HTTPS: the intended server name (as extracted from the target URL) should appear in the server's certificate. Outside of HTTPS, it is up the each client application to decide whether the certificate they got from the server is the right one, i.e. that the certificate is valid (properly issued by a trusted CA and so on), but also that the identified server is indeed the one the client should be talking to. There again, configuration.