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

forgive me here - despite best efforts rather non-precise way of asking precise question!

i pointed towards following website on generating server side key/cert (pem file) twisted python tls server: https://twistedmatrix.com/trac/browser/trunk/twisted/test/server.pem

as can see, code here generates pem file contains python source (subsequently removed!) , certificate, , private key.

from here, used following generate public key (since pyopenssl apparently has no way of exporting it)

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

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

however, corresponding starttls_client.py example seems want use same "server.pem" file. surely wrong? (limited!) understand of tls client given copy of public key, , used handshaking. nontheless tried it, , wasn't overly surprised when didn't work:

failure: twisted.internet.error.connectionrefusederror: connection refused other side: 111: connection refused. 

i tried specifying public.key had exported, generated (seemingly common) empty error openssl.crypto:

openssl.crypto.error: [] 

so explained - can tell me how produce need client side, agree tls connection server , it's cert/private key?

thanks :)

edit - following comment - server.pem , client.crt (as used in code) shown below:

server.pem:

-----begin private key----- miievwibadanbgkqhkig9w0baqefaascbkkwggslageaaoibaqddgvgemyhamhkk jkhrwhwabfameraqbadkwrgtk2an4oh2bgsck1r4nmqzmhmsgwrxnhz/p9ygodmj z8irh7mwyvzipodljrhp46kqhimm8j9vzromrbnqmc1zhgtgzcwu0tscgc5wwrkf rwc2pbnrbwi514/1auemavefgaxguoa88twz9mx/j2npxhno/h0eb69wdmernnam ih46/85+ehl+1psemdfspxujgww1a2lvw1lubkgvkam3iyvvl/bxgfavgfsezpuv c1ad1mnwpg5vwalsavttstaoobkytoyuz+gdi6jomagqij0jfzodb+dpul0mohqu pv8jiayjagmbaaecggebal2pv7mxgn+tchgetwz6apfnms8fefdd6h09nhwklkch mymjt4v4ftagiipmv/racqvdwrbahqd6cv92k/udjw2l9uhkwhwo2/+n/cy7f5uv +buml9doygkjzzy77fzmkpco1zw1eya5ycps4zzozgo5hjdihka3klrurdw8n4ya p97ncbtmdpmllydfeqfymwfzqyl38nczq0gvesx1ovrhc5o7oymesbtxze3khe05 +yyho7qwpuufd8gw3stbja0d21cu/n83+e7ymr6zuwt+nrxfuvb4hqjhqugpaen0 ad7/rnavesmlxm4qesrke1bhhywm6dc0bbexzvj5/2ecgyea/rtsucorcuowkhni c26prxzllock/zgsdhip0sllbv1ayxb7unbqbonc4o9lcqllpvyckxgqefwmz1am bkw1fyl9m7f/4xndwlemyxfnyaqajf8sk8ebmokn/ihoocfvoitbtn9fyuidplqm +ktxd+xlhsdkvvwvbwyyal6fg4scgyeaxcqu3wrxgmbdqhfw8ytowgvkpdcgdwps muro65cztdxhrpxc7crbueg0thuhinx+rqyjrqcpc0cy0jbbgxy77klp2dublcsq 5n/cmtfkoegucrj22csjekkrk1jvupzgha5m3ozfzxzs4/vqxugn+dchzybtbmp8 n+k14ktqhzscgyea4wphytjzs7st+wozaj56o+sq6zbq7jwtzihqefj5s4zj+ju7 vzlloeyoihhklf+96ys9clefssrxzs6ilk0d0yzh/rmi8w+0k/httasbrhudbzdg ljkjvm41vrkpc/sc3z7s1cppnrtn1u/0jjzh+wwg8i5rj5e1csdi67gr+t8cgyea v/5doqeagvbseinrkq40dumh7ys3nkyp1tqdg6qfjnmdokfbwvsfavniprx09yoy smuibxf6abf954y9yuoybvtd5jqwzdbbr1twqee4m0y708rnodiyxu1o75fwzyuo 7s3uifb5sruj57ryc8rfbract9mxmarcslxh54r3btecgybuhcbtb9z07pkcdab2 pner/whrw8e8hv1vch8svjj+cq7tun15rk8zsmucbnshprce8lbnuou5kkjeogrn 1pnlxd8tsgrq+5qvpfs8psxjsptuzmfauak1uy2qdmetj1xddfvek2hb0/4lplpt zpuigmuntyg50i40lpusdj46jg== -----end private key----- -----begin certificate----- miid+dccauacaws5bjanbgkqhkig9w0baqufadcbvzelmakga1uebhmcvusxgdaw bgnvbagtd0dsb3vjzxn0zxjzaglyztetmbega1uebxmkr2xvdwnlc3rlcjesmbag a1ueaxmjbg9jywxob3n0mrwwggydvqqkexnud2lzdgvkie1hdhjpecbmywjzmsqw igydvqqlextbdxrvbwf0zwqgvgvzdgluzybbdxrob3jpdhkxktanbgkqhkig9w0b cqewgnnly3vyaxr5qhr3axn0zwrtyxryaxguy29tmcaxdte0mdkxodeyntiznfoy dzixmtqwodi1mti1mjm0wjcbvzelmakga1uebhmcvusxgdawbgnvbagtd0dsb3vj zxn0zxjzaglyztetmbega1uebxmkr2xvdwnlc3rlcjesmbaga1ueaxmjbg9jywxo b3n0mrwwggydvqqkexnud2lzdgvkie1hdhjpecbmywjzmsqwigydvqqlextbdxrv bwf0zwqgvgvzdgluzybbdxrob3jpdhkxktanbgkqhkig9w0bcqewgnnly3vyaxr5 qhr3axn0zwrtyxryaxguy29tmiibijanbgkqhkig9w0baqefaaocaq8amiibcgkc aqeaw4l4hpmbwjh5ji5ia8ivgaxwdbkweg2nzmeyeytmjekidgrrapna+jzkmzhz ehsk1zr2fz/wbqhzo8/ceye5smr2yqtnsyaxz+oiqh4jdpcfb86zjk2zudhnc4ye xswsfnlbhbnocfkzbuvgtj2zuw8codep9qfbdafrh4gl4fdmvpe8gfzl/49pz8yt ap4dhgevchthqztqjooeov/ofnh5ftaunpnruqv1crlsnqni1cnzbmyofzgjn4mf vzfwv4bwlyh0ns6br3nqa9tj8kyovvmpugl7buk2jqgymltslgfhg4uozjaieio9 ixwtg2/g6bi9dkiarqb/iygmcqidaqabma0gcsqgsib3dqebbquaa4ibaqadhfu7 avp6uwolijigyyv/l7purlf7mahz+t5z5pw9j13tgr3wwwa4qh37qjow5rt44gye nrtn42vmwh/1bmte2r5nosjpgw3hglzrgaakbzi8tr9/e5alve1yogk0uhdqd7zs u3a6y0pdksgdiynathcic7qbper0/pmli4b5+b7c+ngr7/0bc3r4yvzzdua1nulm 9e50jixgvr7z46iz5s3idlcb/fkx2aawgzftfhbrk0s6r0cxsjyf7eup7kpy2njq u5nhmq8aofz/s7lgalflsrwgy4vkwjhapixq9bfhrgbjfpxvg5q1ij4aqymc+wsd jo9lzzyikrrx435w -----end certificate----- 

client.crt:

-----begin certificate----- miid+dccauacaws5bjanbgkqhkig9w0baqufadcbvzelmakga1uebhmcvusxgdaw bgnvbagtd0dsb3vjzxn0zxjzaglyztetmbega1uebxmkr2xvdwnlc3rlcjesmbag a1ueaxmjbg9jywxob3n0mrwwggydvqqkexnud2lzdgvkie1hdhjpecbmywjzmsqw igydvqqlextbdxrvbwf0zwqgvgvzdgluzybbdxrob3jpdhkxktanbgkqhkig9w0b cqewgnnly3vyaxr5qhr3axn0zwrtyxryaxguy29tmcaxdte0mdkxodeyntiznfoy dzixmtqwodi1mti1mjm0wjcbvzelmakga1uebhmcvusxgdawbgnvbagtd0dsb3vj zxn0zxjzaglyztetmbega1uebxmkr2xvdwnlc3rlcjesmbaga1ueaxmjbg9jywxo b3n0mrwwggydvqqkexnud2lzdgvkie1hdhjpecbmywjzmsqwigydvqqlextbdxrv bwf0zwqgvgvzdgluzybbdxrob3jpdhkxktanbgkqhkig9w0bcqewgnnly3vyaxr5 qhr3axn0zwrtyxryaxguy29tmiibijanbgkqhkig9w0baqefaaocaq8amiibcgkc aqeaw4l4hpmbwjh5ji5ia8ivgaxwdbkweg2nzmeyeytmjekidgrrapna+jzkmzhz ehsk1zr2fz/wbqhzo8/ceye5smr2yqtnsyaxz+oiqh4jdpcfb86zjk2zudhnc4ye xswsfnlbhbnocfkzbuvgtj2zuw8codep9qfbdafrh4gl4fdmvpe8gfzl/49pz8yt ap4dhgevchthqztqjooeov/ofnh5ftaunpnruqv1crlsnqni1cnzbmyofzgjn4mf vzfwv4bwlyh0ns6br3nqa9tj8kyovvmpugl7buk2jqgymltslgfhg4uozjaieio9 ixwtg2/g6bi9dkiarqb/iygmcqidaqabma0gcsqgsib3dqebbquaa4ibaqadhfu7 avp6uwolijigyyv/l7purlf7mahz+t5z5pw9j13tgr3wwwa4qh37qjow5rt44gye nrtn42vmwh/1bmte2r5nosjpgw3hglzrgaakbzi8tr9/e5alve1yogk0uhdqd7zs u3a6y0pdksgdiynathcic7qbper0/pmli4b5+b7c+ngr7/0bc3r4yvzzdua1nulm 9e50jixgvr7z46iz5s3idlcb/fkx2aawgzftfhbrk0s6r0cxsjyf7eup7kpy2njq u5nhmq8aofz/s7lgalflsrwgy4vkwjhapixq9bfhrgbjfpxvg5q1ij4aqymc+wsd jo9lzzyikrrx435w -----end certificate----- 

a side of tls connection can use private key and certificate prove identity other side during tls handshake. commonly, server side , client side not. however, it's possible client use own private key , certificate prove identity server (and it's possible neither side bother proving identity other, though less common client-side identification).

the private key is, name suggests, kept private. basic point of certificate prove possess private key. therefore if share private key other people, certificates become less useful because of can prove have same private key - leaving peer you're proving uncertain of talking to.

the public key isn't commonly used part of tls connection. because it's big random number , it's inconvenient identify entities using big random numbers. instead there certificate lot of human-friendly metadata combined public key , signed private key (usually not your private key, instead certificate authority's private key - when have "self-signed certificate", name suggests, certificate signed own private key).

you extracted public key pem using command openssl x509 -pubkey -noout -in server.pem > public.key isn't particularly useful running tls server.

instead want certificate:

openssl x509 -in server.pem > cert.pem 

this step not strictly not necessary. apis loading certificate pem search through big pile of other garbage until finding certificate , load it.

however make sense split certificate out in case in order supply , client. echoclient_ssl.py linked wants certificate use "trust root". wants able establish trust chain (basically, chain of signatures going certificate server presented issuing entity, issuing entities certificate its issuing entity, , on until reaches certificate in trust root). in case, if use exact same certificate on server , in client's trust root, chain short (the certificate signed own private key, chain has 1 link).

separating out certificate , giving client simulates real world usage client wouldn't have access server's private key (which makes sense reasons discussed above).