https://www.reddit.com/r/geminiprotocol/comments/1i2u622/certificates_on_both_sides/
created by tinspin on 16/01/2025 at 17:26 UTC
1 upvotes, 1 top-level comments (showing 1)
Why does gemini have both server and client certificates?
Would it not be simpler to just use the client ones?
Comment by IHeartBadCode at 16/01/2025 at 18:23 UTC
5 upvotes, 1 direct replies
To prove identity. Each certificate indicates that they are who they say they are. The server certificate indicates that, yes that is the server you were expecting. The client certificate indicates to the server, yes you are who you say you are.
Now Gemini pretty much encourages TOFU, so at the start both the client and server don't know each other and they just "trust" each other at first and use the exchanged certificates to ensure that you are at least speaking to the person whom you started this whole thing with.
It the HTTPS world, a client certificate isn't really needed because most websites have various other means by which you are authenticated. TLS has optional mutual authentication[1] and HTTPS relies on TLS, and so most sites take the whole "optional" thing as that. Optional.
1: https://en.wikipedia.org/wiki/Mutual_authentication
In Gemini, which also uses TLS, it's strongly suggested that what is optional, be actually used. But again, you can establish a TLS connection no problem with Gemini with just the server certificate and use status 10 and 11 to implement some sort of "logging in" process. But as the protocol indicates:
Clients are strongly RECOMMENDED to use a Trust on First Use or "TOFU" certificate-pinning system, which does not reject self-signed certificates as invalid, as the basis of their validation system. Under such an system, the first time a Gemini client connects to a server, it accepts whichever certificate it is presented. That certificate's fingerprint and expiry date are saved in a persistent database, associated with the server's hostname and port. On all subsequent connections to the same hostname on the same port, the received certificate's fingerprint is computed and compared against the one stored in the database. If the fingerprints do not match but the previous certificate's expiry date has not passed, this is considered potential evidence of a Man-In-The-Middle attack. Clients MAY augment this basic system with additional security measures, e.g. comparing certificates received from multiple network perspectives and/or using DNS-Based Authentication of Named Entities (DANE) [RFC6698].
It's strongly suggested to do it the way it's mostly seen out in the wild. But anything using TLS can have both client and server certificates, even HTTPS.