使用客户端身份验证实现 java SSL 和 TLS 服务器套接字

Question

I'm working on a project which consists on developping a TLS and SSL JAVA TCP/IP (Socket) server.

The Server must accept TLS and SSL TCP/IP Connections.

Actually i developed a multithreaded Server which can accept and respond to many clients in the same time but i still don't see a solution to make it work with TLS and SSL connections

I have read about the SSLServerSocket and ServerSocketFactory but I didn't get how can they help me with the certificate:

I didn't know how to give the socket The CA file path (the private certificate path) (eg: CAfile=D:\\projects\\mytools\\eclipse\\TunRootCA1.pem or rootcert.crt) like in Stunnel

let me describe the situation more precisely: actually, the project i'm working on, consists on developing a server JAVA application which connects with POS devices working with TLS or SSL certificate. The server has to accept the flow and make some fonctional controles (such as amounts,PAN, ...) then switch it to a third party server. The server has to work with a one side certificate verification: the clients use a certificate (.ca) downloaded from a national authority web site and the server uses a certificate signed from the same national authority agency all parts of the server are ready except the TLS and SSL connection thanks

I'd appreciate if anyone can describe me steps (with code samples) to implement a JAVA SSL and TLS server TCP/IP socket (with the above described behaviour)

Thanks a lot

Answer 1

Unfortunately this is not how TLS/SSL works.

The client initiates a connection and sends a public certificate to my server

The client initiates a connection, receives the server certificate, verifies it, receives a certificate request from the server, and sends its own certificate if it can.

The server must authentify the certificate received with its private certificate (stocked in some predefined path)

Meaningless. There is no such thing as a private certificate. The server verifies the certificate (a) by checking its digital signature and (b) by forming a trust chain from its signer to a signer it trusts.

The server sends a positive response back to the client.

The server either completes the TLS/SSL handshake or sends a TLS alert or closes the connection. There is no positive response to an accepted client certificate.

The client sends its message to the server (clear messages).

The channel is now encrypted in both directions.

The server sends its responding messages to the client (clear message).

The channel is now encrypted in both directions.

Your requirement is both non-TLS-compliant and insecure as stated. Review it.