In previous pages I made and TLS server and client. Now I'm going to change the server to make sure only the approved clients can connect.
So I'm looking at the rustls::server::danger::ClientCertVerifier
trait that I need to implement to verify client certificates at the server side.
But a quarter hour later I've noticed that it's in the danger zone.
Perhaps I shouldn't touch it, mainly because implementing that requires implementing the actual signature verification.
so now I'm checking the rustls::server::ClientCertVerifierBuilder
maybe that can work. But that doesn't seem to have a constructor method.
But the docs write at the beginning that there is the rustls::server::WebPkiClientVerifier.
Which can create a verifier for us.
Ideally what I want to do I require client certificate, but if it doesn't authenticate I would still like to see it so I can use it as a kind of friend request. But if this is not possible, I can accept that only the accepted clients may authenticate. That's okay, in that case the certs need to be exchanged out of the band.
So I've changed the server implementation to accept more parameters that contain the root certificates of the users that are trusted or are friends. I've also changed the certificate maker application so it handles the arguments better rather than simply indexing into the args array. The server builds but I'm not sure it works yet.
So I need to do the changes on the client side as well, so the client actually offers its cert.
So the client takes 2 additional arguments that specifies the device certificate and key for the client.
Then I basically need to add with_client_auth_cert() into the client configuration and provide the device client certificate and the private key and it works.
The commands I used was in two terminal were the following:
./server certs/Alice1.crt certs/Alice.crt certs/Alice1.pem certs/Bob.crt
./client certs/Alice.crt "alice" 127.0.0.1:4443 certs/Bob1.crt certs/Bob1.pem
So Bob can connect to Alice fine.
Then I've tested the reverse as well when Alice connects to Bob, it works as well.
This proves that two active nodes each can initiate connection to each other.
I've tested some other cases when there is client certificate presented: it rejects the connection, it also rejects it when I use a different certificate and key.
So mutual TLS works.
I've finished for the day and now we are at the commit 3af3c05f30c1099d4cedb08d1bf532661345221e in the repo (https://git.jxzqj.com/chat2026.git).
With the basic idea is working. Only friends who mutually authenticate to each other can talk. The other side only has an user root cert and the device cert itself does not need to be distributed all the time.
In the next post, I start to design the chat application for real.
See the latest posts below, click the "..." to see them all. Click the tags to filter by tag. You can also subscribe to RSS in those lists.
Double entry bookkeeping explained - english finance
Chat2026 part 10: continuing application design - english chat2026-devblog
If you want privacy, please use a desktop PC - english privacy
YouTube is now practically unsearchable - english rants
Chat2026 part 9: using CRL in the server and client examples - english chat2026-devblog