It’s a rhetoric question. I think it does not because the Gemini world uses “trust on first use” (TOFU). That is, a Gemini client visits a Gemini server for the first time, and if it doesn’t know the certificate, it silently stores a fingerprint of said certificate. The next time the Gemini client visits the same Gemini server, the client verifies that the fingerprint still matches. If it does, then nobody has been meddling with the encryption. If it has changed, a warning is usually shown to the user.
The benefit is that we can use self-signed certificates. No promises are made, and you might run into a trap on your first use, but once you begin to trust a site, you can be sure that nobody is meddling with your encryption as long as the fingerprints stay the same.
Now, when you create a new, self-signed certificate, you are asked a few questions. Here’s an example. First, the openssl command to create new certificates, then the openssl output, and at the end, when it comes to the list of questions, I leave them all blank (entering a dot) except for the Common Name (CN). There, I provide any name I want:
openssl req -new -x509 -newkey ec \ -pkeyopt ec_paramgen_curve:prime256v1 \ -days 1825 -nodes -out cert.pem -keyout key.pem Generating an EC private key writing new private key to 'key.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:. State or Province Name (full name) [Some-State]:. Locality Name (eg, city) :. Organization Name (eg, company) [Internet Widgits Pty Ltd]:. Organizational Unit Name (eg, section) :. Common Name (e.g. server FQDN or YOUR name) :Gemini Wiki Email Address :.
Now, if I were using this certificate for a traditional website, I would have to use my domain name as the common name or as the “alt subject name”, and I would have to get the certificate signed by a certification authority, and so on. We don’t want to do all this in the Gemini World, so we’re free to pick any common name. You could pick a “fully qualified domain name” (FQDN) or you could pick “YOUR name” – that’s it. Just any name you want, actually. These questions and their significance is regulated by X.509.
An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed.
Thus, it’s true that on the web, we need to use those signed certificates. But for Gemini, we can pick the identities we want: our organisations, ourselves as individuals, it doesn’t matter. All that matters is that clients (and their users) “trust on first use” (TOFU).
So now we’re getting to the question I have: I have two websites, alexschroeder.ch and transjovian.org; on the web, browsers get the respective certificates when visiting one or the other. On Gemini, I thought I’d save myself some time and just use one certificate for both sites. And now some Gemini clients are complaining: they’re visiting the first site and getting the certificate for the second site, and the common name doesn’t match the hostname, and so they raise an error.
What do you think?
I think they’re wrong, for the reasons explained above. I could have used a certificate with the common names “Alex Schroeder” or “The Transjovian Council” and I decided to use the certificate with the common name “transjovian.org” – in the TOFU world, I don’t think it should matter whether this certificate “belongs” to alexschroeder.ch. The mismatch is irrelevant. All that matters is whether you trust it.