So last time I've made a program that can issue more certificates and to revoke them.
So I've made an Alice2 certificate that's signed by the Alice's user cert.
Then as a baseline I've made sure it works, so I started the server, then in another terminal I started the client example like this:
./server ../certs/Alice2.crt ../certs/Alice.crt ../certs/Alice2.pem ../certs/Bob.crt
./client ../certs/Alice.crt "alice2" 127.0.0.1:4443 ../certs/Bob1.crt ../certs/Bob1.pem
And it works.
So now start working on the CRLs.
But at this point these applications start to have a really lot of command line arguments.
Maybe improve the argument handling first.
So I've pulled in the clap crate and implemented proper argument handling.
This way the example programs are invoked now like this:
./server --dcf ../certs/Alice2.crt --ucf ../certs/Alice.crt --pkf ../certs/Alice2.pem ../certs/Bob.crt
./client --srcf ../certs/Alice.crt --sn "alice2" --saddr 127.0.0.1:4443 --dcf ../certs/Bob1.crt --dpkf ../certs/Bob1.pem
I've committed this and this is at 4adbe74d32dbbc1b58f9b9a2ccffbbbdcf29b3bd in the repo (https://git.jxzqj.com/chat2026.git)
(And this was the moment I realized that maybe the GIT repo hostname should be configurable in the site generator script just in case I have to move this site somewhere else, so I started to do a major refactoring of the site generator script, so the day ended with that.)
Then I've added the --crl option to both the client and server and used the WebPkiServerVerifier on the client side to use the CRLs.
The server side have always used the WebPkiClientVerifier and that also have an option to specify CRLs.
So in the following example the client specifies that it rejects the Alice2 device:
./server --dcf ../certs/Alice2.crt --ucf ../certs/Alice.crt --pkf ../certs/Alice2.pem ../certs/Bob.crt
./client --srcf ../certs/Alice.crt --sn "alice2" --saddr 127.0.0.1:4443 --dcf ../certs/Bob1.crt --dpkf ../certs/Bob1.pem --crl ../certs/Alice2.crl
In this case the client connection will fail with invalid certificate error. While the server gets a certificate revoked alert.
I've created a Bob2 device certificate and CRL for that too, so the server can also reject that too:
./server --dcf ../certs/Alice2.crt --ucf ../certs/Alice.crt --pkf ../certs/Alice2.pem --crl ../certs/Bob2.crl ../certs/Bob.crt
./client --srcf ../certs/Alice.crt --sn "alice2" --saddr 127.0.0.1:4443 --dcf ../certs/Bob2.crt --dpkf ../certs/Bob2.pem
Now the connection fails on the server side with invalid certifacte error, and client receives and alert that their certificate is revoked.
It works fine.
I've committed this and it has the hash e72f22512ef6143681b0253b98278f9b574d2cb3.
So with this I've completed the 4 tasks I've wanted to check in part 7. In the next part I'm planning to continue the application design.
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