Twisted Python and TLS - what does the client code need for handshaking? (I thought just public key!)

Question

Forgive me here - despite best efforts this is a rather non-precise way of asking a fairly precise question!

I was recently pointed towards the following website for help on generating a server side key/cert (pem file) for my Twisted Python TLS server: https://twistedmatrix.com/trac/browser/trunk/twisted/test/server.pem

As you can see, the code here generates a PEM file that contains the python source (subsequently removed!) and the certificate, and private key.

From here, I used the following to generate a public key (since pyOpenSSL apparently has no way of exporting it)

openssl x509 -pubkey -noout -in server.pem > public.key

I then used the server.pem file generated above in the "starttls_server.py" sample found here: https://twistedmatrix.com/documents/14.0.0/core/howto/ssl.html

However, the corresponding starttls_client.py example seems to want to use the same "server.pem" file. Surely this is wrong? My (limited!) understand of TLS was that the client would be given a copy of the public key, and this would be used for the handshaking. Nontheless I tried it, and wasn't overly surprised when it didn't work:

Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.

I also tried specifying the public.key I had exported, but this generated a (seemingly common) empty error from OpenSSL.crypto:

OpenSSL.crypto.Error: []

So with all that explained - can someone tell me how to produce what I need client side, to successfully agree a TLS connection with my server and it's cert/private key?

Thanks :)

EDIT - Following a comment - server.pem and client.crt (as used in my code) now shown below:

Server.pem:

Client.crt:

Jean-Paul Calderone · Accepted Answer

A side of a TLS connection can use a private key and a certificate to prove its identity to the other side during the TLS handshake. Commonly, the server side does this and the client side does not. However, it's also possible for the client to use its own private key and certificate to prove its identity to the server (and it's also possible for neither side to bother proving its identity to the other, though this is even less common than client-side identification).

The private key is, as the name suggests, kept private. The basic point of the certificate is to prove that you possess a certain private key. Therefore if you share the private key with other people, your certificates become less useful because all any of you can prove is that you have that same private key - leaving the peer you're proving this to uncertain about which of you it is actually talking to.

The public key isn't commonly used by itself as part of a TLS connection. This is because it's just a big random number and it's inconvenient to identify entities using just big random numbers. So instead there is a certificate which is a lot of human-friendly metadata combined with the public key and then signed by a private key (usually not your private key, instead usually by a certificate authority's private key - but when you have a "self-signed certificate", as the name suggests, your certificate is signed by your own private key).

You successfully extracted the public key from the PEM using the command openssl x509 -pubkey -noout -in server.pem > public.key but this isn't particularly useful for running a TLS server.

Instead you want the certificate:

openssl x509 -in server.pem > cert.pem

This step is not strictly not necessary. The APIs for loading a certificate from a PEM will search through a big pile of other garbage until finding the certificate and then load it.

However it does make sense to split the certificate out in this case in order to supply it and only it to the client. The echoclient_ssl.py you linked to wants the certificate to use as the "trust root". It wants to be able to establish a trust chain (basically, a chain of signatures going from the certificate the server presented back to an issuing entity, from that issuing entities certificate back to its issuing entity, and so on until it reaches a certificate in the trust root). In this case, if you use the exact same certificate on the server and in the client's trust root, the chain is very short (the certificate is signed by its own private key, so the chain only has one link).

Separating out the certificate and giving the client only that simulates real world usage where the client wouldn't actually have access to the server's private key (which makes sense for the reasons discussed above).

Twisted Python and TLS - what does the client code need for handshaking? (I thought just public key!)

Answers (1)

Related Questions