Does a cert need a Common Name matching the domain?

[Gary Johnson]

Hi Alex,

I follow your rationale, and unfortunately, I don't know whether
matching CNs are required by the x509 spec. I think I'd like to hear
Solderpunk weigh in on this issue since it seems like a slightly
ambiguous area in the spec.

Cheers,
  Gary

Alex Schroeder <alex at gnu.org> writes:

> On Mon, 2020-07-20 at 23:11 -0400, Gary Johnson wrote:
>> I was under the impression that the Gemini spec already made it
>> mandatory to make CNs match the requested domain name. That's why I
>> implemented SNI in Space Age. Here's the relevant section of the
>> spec:
>> 
>> From gemini://gemini.circumlunar.space/docs/specification.gmi:
>> -----------------------------------------------------------------
>> 4 TLS
>> 
>> Use of TLS for Gemini transactions is mandatory.
>> 
>> Use of the Server Name Indication (SNI) extension to TLS is also
>> mandatory, to facilitate name-based virtual hosting.
>> -----------------------------------------------------------------
>> 
>> If I'm misunderstanding something here, please clarify.
>
> Hi Gary
>
> Thanks for your response.
>
> 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 at 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?
>
> Cheers
> Alex


-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html