SSL Client Certificate authentication

Question

Is it possible to make a program which uses client certificate authentication with only public and private key( I have not generated any certificate i have only public and private key).

Simply,

I want to make authentication on server with client certificate authentication. But it is hard to make client certificate programmatically.

i want to make client certificate authentication with only public and private key (i have only public and private key, no certificate).

It is possible to send server public key instead of client certificate for client certificate authentication ?

Answer 1

It is possible to send server public key instead of client certificate for client certificate authentication ?

No. The SSL protocol is already defined. And if it was possible it wouldn't accomplish the objective. The server's public key doesn't authenticate the server's identity in any way shape or form.

Answer 2

The TLS protocol only allows for certificates to be exchanged, not raw public keys. Even "PGP keys" (if you wanted to replace X.509 with OpenPGP for authentication in TLS, which is much less supported) are in fact certificates (they're the signed combination of a public key and a set of identifiers and attributes).

This being said, you can perform client authentication using self-signed client certificates and rely on their public keys (but you will need to verify this public key against something your server already knows, such as a known list). You need to understand the security implications for implementing this first. This is not quite the same problem as self-signed server certificates. (I'd suggest keeping a more traditional approach to verifying the server certificate.)

You can make the client send a self-signed certificate (possibly using certain tricks regarding the CA list advertised by the server) and either perform the verification in the TLS stack or later in the application.

Note that many application containers (e.g. Tomcat/Jetty in Java) expect the SSL/TLS layer to verify the client certificate. Hence, if you skip the authentication there (and prefer to do it later on within the container or as part of the application), many application frameworks will be confused. You need to be quite careful to make sure that authentication is actually performed somewhere before performing any action that requires authentication in your application.

For example, it can be OK to have a trust manager that lets any client certificate through in Tomcat/Jetty, but you can't rely on the javax.servlet.request.X509Certificate request attribute to have been verified in any way (which most frameworks would otherwise expect). You'd need to implement some verification logic within your application: for example, having a filter before any authenticated feature that compares the public key in this client certificate with your known list of public keys (or however you want to match the public key to an identifier). Alternatively, you can also perform this verification within your custom trust manager (in Java), this will require less work within the applications.

You could do something similar in an Apache Httpd + PHP setup (for example), using SSLVerifyClient optional_no_ca. Again, your PHP application could not rely on the certificate having been verified, so you would have to implement so verification there too.

Don't do any of this unless you understand at which stage the certificate information you get has been verified.