Between 2013 and 2023, I wrote a series of books for Manning, O’Reilly, and the Pragmatic Bookshelf:
Every once in a while, someone would come up to me at a conference with a copy of one and ask me to sign it. I’d make some gag about that ruining the resale value, but would do what they asked.
Over time, however, more and more people bought ebooks rather than physical ones. Occasionally someone would make the obvious gag of asking me to sign their ebook. I would usually look around for a felt marker and threaten to deface their Kindle or PDF reader before backing off.
It occurred to me, however, that there was actually a solution to this problem. Sure, I can’t sign an ebook, but I could digitally sign one, right?
Wait, what does that even mean?
A digital signature is an encrypted hash. You take a digital document and compute a smaller string from it, called a hash. Then you generate a public / private key pair. You pick one and call it your private key, which you share with nobody, and the other becomes your your public key, which you share with everybody. The key (sorry) is that either key can be used to encrypt data, and the other key is then used to decrypt it.
You can accomplish several things this way. I’ll apologize ahead of time for the simplified explanation, but here’s the essence:
- If I encrypt a message with YOUR PUBLIC key, only you can decrypt it, because only you have your private key. You can then send me a reply encrypted with MY PUBLIC key, and only I can read it, and so on. That’s secure communication.
- As an alternative, if you send me a document, I can compute a small hash (sometimes call a digest) from it using a known algorithm. I then encrypt the hash with MY PRIVATE key and send it to you. You can compute the same hash and compare it to the one you get by decrypting the one I sent you with my public key. If they match, we have achieved (1) integrity, meaning the document wasn’t changed in transit, and (2) non-repudiation, meaning only I could have sent the hash encrypted with my own private key.
That hash encrypted with a private key is called a digital signature, because it had to come from the signer (the only one with the private key). We also know the document wasn’t altered or the resulting hash wouldn’t be the same. A hacker could alter the document, but they couldn’t sign it because they don’t have the private key.
One more step and then I can get to the point: I need a way to send my public key to you. A certificate is a document that contains both my public key and my business information, along with an expiration date and other info. Of course, anybody can generate their own certificate (called a self-signed certificate), so normally you pay a trusted third party to validate and digitally sign your certificate, forming a certificate chain. A self-signed certificate carries no real trust value.
My nerdiest joke ever
Getting back to my goal, I didn’t want people sending me copies of their ebook for me to digitally sign. Instead I decided to generate a PDF and sign that. The generated PDF had the name of the book along with my scanned signature, and I would then digitally sign the result.
The returned PDF would then be …
… wait for it …
A self-signed certificate signed with my self-signed certificate.
(Insert rimshot here)
All of these steps can be done programmatically. I occasionally used to teach a course on the Java security libraries used to create hashes, keys, and signatures. Also, there are several libraries you can use to generate PDFs. So in principle this silly little application could be done — it would just take some work.
Enter AI, because hey, it’s 2025
You’re no doubt familiar with the classic Monty Python sketch about the Ministry of Silly Walks.
The applicant says, “I have a silly walk, and I’d like to get government backing to develop it.”
After watching it, the minister replies, “It’s not terribly silly, is it?”
The applicant responds, “I think with government backing, I could make it a lot more silly.”
Well, I looked at the APIs for generating PDFs and the APIs for signing and validating documents, and saw how low-level and tedious they both were. I could probably fight my way through them, but it’s not like I didn’t have any other (real) work to do. The coding looked annoying enough that it discouraged me from attempting the project.
That’s before I encountered Claude Code, however, which could write a lot of the annoying parts for me. With AI, I could make the project a lot more silly.
To make a story short long
With agent assistance, the overall project took me a few days, which included figuring out how to package and deploy it online. You can try it out here.
Fill in a name, pick one of my books from the drop-down list, and click the generate button. Here’s a sample result:
That’s the generated PDF opened inside Adobe Reader. You might notice that blue band at the top:
Yeah, don’t we all. What’s the problem here? Open the signature panel, and you see something like this:
If you can’t read it, the key (sorry again) sentence is, “Signer’s identity is unknown because it has not been included in your list of trusted certificates and none of its parent certificates are trusted certificates.”
In other words, it’s a self-signed certificate, and you shouldn’t trust self-signed certificates. At least it also says, “Document has not been modified since this signature was applied.” So I’ve got that. Which is nice.
Validating the certificate
If you don’t want to open the document in Adobe Reader to get to the signature panel, there’s an alternative. You see that QR code in the lower left corner? Underneath it says, “Scan to verify certificate authenticity”. The service will also validate the certificate. Just follow the link in the QR code and it should say that everything is fine (other than it being self-signed, but you knew that).
The application is written as a Spring Boot restful web service, so it’s in Java with a very simple HTML / CSS front end. All the code is in this GitHub repository, and you’re welcome to it. I used Java 21, for no reason other than to tell Spring to use virtual threads, but most everything works under Java 17. The libraries I used were:
- Spring Boot 3.4
- PDFBox 3.0 for all the generation and signing
- BouncyCastle for the cryptograhic features
- ZXing for generating the QR code
- JUnit, of course, though I threw in some property-based testing with jqwik as well
The app comes with a Gradle build file for compiling, testing, and running the app.
If you want to customize it for your own use, there’s only one awkward part. After fighting with the code for way too long trying to line up my scanned signature with the signature block (now I understand why CSS devs go insane), I eventually gave up and added it directly to the background image using Canva. So you’ll need to either mask out my signature somehow or replace the background image for the certificate itself. Otherwise, have at it.
See what the rise of AI hath wrought? With AI assistance, I can take my silliest, nerdiest ideas ever and implement them in a couple of days and inflict the results on the world. Sorry (not sorry).
Feel free to comment here, or on my Tales from the jar side newsletter or YouTube channel.
Leave a Reply