Two-way SSL clarification

Question

I am somewhat confused as to how two-way SSL works. How does the client create its certificate to send to the server? Is it generated from the server and distributed to the client?

Also, what is the advantage of two-way SSL over one-way SSL?

Lobster

Answer 1

Both certificates should exist prior to the connection. They're usually created by Certification Authorities (not necessarily the same). (There are alternative cases where verification can be done differently, but some verification will need to be made.)

The server certificate should be created by a CA that the client trusts (and following the naming conventions defined in RFC 6125).

The client certificate should be created by a CA that the server trusts.

It's up to each party to choose what it trusts.

There are online CA tools that will allow you to apply for a certificate within your browser and get it installed there once the CA has issued it. They need not be on the server that requests client-certificate authentication.

The certificate distribution and trust management is the role of the Public Key Infrastructure (PKI), implemented via the CAs. The SSL/TLS client and servers and then merely users of that PKI.

When the client connects to a server that requests client-certificate authentication, the server sends a list of CAs it's willing to accept as part of the client-certificate request. The client is then able to send its client certificate, if it wishes to and a suitable one is available.

The main advantages of client-certificate authentication are:

• The private information (the private key) is never sent to the server. The client doesn't let its secret out at all during the authentication.
• A server that doesn't know a user with that certificate can still authenticate that user, provided it trusts the CA that issued the certificate (and that the certificate is valid). This is very similar to the way passports are used: you may have never met a person showing you a passport, but because you trust the issuing authority, you're able to link the identity to the person.

You may be interested in Advantages of client certificates for client authentication? (on Security.SE).

Chigger

you should replace 'created' with 'signed by' to keep this relevant – Thirdrate

@Thirdrate "Keep this relevant"... Do you mean it's not relevant when using "created" (wording in line with the question) ;-) ? "Issued" might be a better word indeed. – Chigger

CA is a cert signing authority. It doesn't matter how the cert was issued or created, it only matters it is signed by the certified authority. I understand most CAs create/issue public key certs signed by themselves, and could be used, but if an already existing public key is required, it just needs to be signed by the CA. – Thirdrate

@Thirdrate No really, signing is really just the last technical step in the certification process (which consists of issuing a cert). It wouldn't make sense for a CA to sign a cert issued by another CA, since you have to match the Issuer DN to the Subject DN to build the chain when you verify. The cert is only "created" when it is signed, since before that it's a CSR or a bit later the TBSCertificate structure (but still not a cert). You're nitpicking on "creating", but an X.509 certificate has to be signed to exist, and signing it is precisely what turns that data structure into a cert. – Chigger

you are not allowing for the signing of certificates issued by another authority. x509 is signed, but not necessarily by a trusted authority. – Thirdrate

@Thirdrate What you're saying doesn't really make sense. X.509 certs can only have one signature. If you try to sign a cert issued by another CA, then that CA isn't actually issuing that cert: you are (although you're claiming to be them when you're not, and the signature won't verify with the CA cert). Signing is really just a technical step, which bundles the signature to the TBSCertificate part, which altogether forms the newly-created cert. Coming back to the initial point, whoever signs the cert also creates it and vice versa (because X.509 certs only have one signature, unlike PGP keys). – Chigger

@Chigger thank you for this "This is very similar to the way passports are used: you may have never met a person showing you a passport, but because you trust the issuing authority, you're able to link the identity to the person." well explained ... – Planetoid

How to validate the client certificate expiration? My server keeps accepting it as valid even though it has expired, thank you! – Barber

@DiegoRamos That depends entirely on the server you're using, whether it's something you've programmed yourself, using existing libraries or using an existing server as a front-end to your application... – Chigger

Answer 2

What you call "Two-Way SSL" is usually called TLS/SSL with client certificate authentication.

In a "normal" TLS connection to example.com only the client verifies that it is indeed communicating with the server for example.com. The server doesn't know who the client is. If the server wants to authenticate the client the usual thing is to use passwords, so a client needs to send a user name and password to the server, but this happens inside the TLS connection as part of an inner protocol (e.g. HTTP) it's not part of the TLS protocol itself. The disadvantage is that you need a separate password for every site because you send the password to the server. So if you use the same password on for example PayPal and MyPonyForum then every time you log into MyPonyForum you send this password to the server of MyPonyForum so the operator of this server could intercept it and try it on PayPal and can issue payments in your name.

Client certificate authentication offers another way to authenticate the client in a TLS connection. In contrast to password login, client certificate authentication is specified as part of the TLS protocol. It works analogous to the way the client authenticates the server: The client generates a public private key pair and submits the public key to a trusted CA for signing. The CA returns a client certificate that can be used to authenticate the client. The client can now use the same certificate to authenticate to different servers (i.e. you could use the same certificate for PayPal and MyPonyForum without risking that it can be abused). The way it works is that after the server has sent its certificate it asks the client to provide a certificate too. Then some public key magic happens (if you want to know the details read RFC 5246) and now the client knows it communicates with the right server, the server knows it communicates with the right client and both have some common key material to encrypt and verify the connection.

Ploughshare

I created a client-rest-api which calls a server-rest-api (one way post call). My client-rest-api uses certificates issued by the server-rest-api. However my client-rest-api never issued any certificates to the server-rest-api. Does it come under one-way-ssl or two-way-ssl? Event though its just a one way call from client to server, I am thinking its two-way-ssl since here server-rest-api validates that client is having the proper certificates issued by the server? – Dorella

@HimalayMajumdar: If your server has a certificate signed by a CA or if you have hardcoded that certificate into your client (pinning), then yes, it's still proper TLS with client certificate authentication (you call it two-way-ssl). Yay :-). If however your client trusts your server certificate blindly, it is technically still TLS with client certificate authentication, but because the server certificate can not be checked by the client, it's not two-way and it's in most cases a really bad idea. Don't do that :-(. – Ploughshare

Usually when I write Java client calling an https enabled service (self signed https), client usually fails as it doesn't trust the certificate by default. In case of my current java client, I just imported the certs issued by server into my classpath for the server to trust my client, I guess by importing the certs even my client automatically trusts the server. Thanks for your response. – Dorella

Answer 3

In two way ssl the client asks for servers digital certificate and server ask for the same from the client. It is more secured as it is both ways, although its bit slow. Generally we dont follow it as the server doesnt care about the identity of the client, but a client needs to make sure about the integrity of server it is connecting to.

Euphonic