2020-07-20 Does a Gemini certificate need a Common Name matching the domain?

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.

Tags:

Comments

On the mailing list, Gary Johnson said he was under the impression that the Gemini specification already made it mandatory to make CNs match the requested domain name, and in support of this position he quoted the following:

Use of the Server Name Indication (SNI) extension to TLS is also mandatory, to facilitate name-based virtual hosting.

But my thinking is this: SNI is how the client tells the server which host it wants to reach in case multiple hosts are hosted on the same IP. Thus, the spec says: in order to facilitate name-based virtual hosting, we want SNI to be part of the standard. That is, both users Alex and Gary could host their sites on a single server, and they could both use their own server certificates. The server would receive requests from clients for either Alex’s site or Gary’s site, know which certificate to send back to the client, and serve the appropriate content. This is the benefit of SNI.

In my mind, this doesn’t require hostname verification, though! Alex’s certificate could have used the common name “Alex Schroeder” and Gary’s certificate could have used the common name “Gary Johnson”. All the client sees is a certificate, which it trusts on first use (TOFU). Users might decide to look at the common name of the certificate, or not. There’s not even the need to provide a common name – we could have generated our certificates using nothing but our email address, or our organization name.

In short, I’m claiming all of these are valid certificates for a Gemini site at alexschroeder.ch, even if they are invalid certificates for a HTTPS site at alexschroeder.ch (maybe? I’m ignoring alt subject name):

openssl x509 -in cert.pem -noout -sha256 -text | grep Subject
        Subject: emailAddress = alex@gnu.org

openssl x509 -in cert.pem -noout -sha256 -text | grep Subject
        Subject: CN = Gemini Wiki

openssl x509 -in /var/lib/dehydrated/certs/transjovian.org/cert.pem \
    -noout -sha256 -text | grep Subject
        Subject: CN = transjovian.org

What do you think? Do you think SNI inherently mandates that the subject have a common name field that matches the domain? It would have to be implied in the X.509 spec somewhere, I guess?

– Alex


– Alex Schroeder 2020-11-30 21:14 UTC


Please make sure you contribute only your own work, or work licensed under the GNU Free Documentation License. Note: in order to facilitate peer review and fight vandalism, we will store your IP number for a number of days. See Privacy Policy for more information. See Info for text formatting rules. You can edit the comment page if you need to fix typos. You can subscribe to new comments by email without leaving a comment.

To save this page you must answer this question:

Just say HELLO