Does a cert need a Common Name matching the domain?

Luke Emmet writes: > > I'm getting "failed to connect to the server: hostname does not > > verify: x509: certificate is valid for celulinde, not > > caranatar.xyz" On Fri, 2020-07-17 at 04:20 -0400, Caranatar wrote: > Ah crap apparently none of the clients I was using to test were > actually > verifying the certificate, and I forgot to change the CN when I > copy/pasted my cert generation command from my laptop. It should be > working now... What do other people think about this? My personal impression was that in a trust on first use (TOFU) world, the common name (CN) of a certificate could be anything. It could be "Alex Schroeder", for example. Or it could be "alexschroeder.ch". Even if it was served as the certificate for another domain, like transjovian.org. After all, the question is only whether you "trust on first use". My impression is that a client that tries to verify that CN and domain match is doing it wrong. What do you think? Sadly, my SSL know-how is weak, so any pointers to how things ought to work in a TOFU world are appreciated. Cheers Alex

On the surface I think you're right, that in the TOFU world, CN shouldn't matter, and neither should subjectAltName, etc. We shouldn't even need wildcard certs, because anything should be accepted. However, I hope someone more knowledgeable can chime in, maybe there's an issue I'm not considering. makeworld ??????? Original Message ??????? On Friday, July 17, 2020 5:09 AM, Alex Schroeder <alex at gnu.org> wrote: > Luke Emmet writes: > > > > I'm getting "failed to connect to the server: hostname does not > > > verify: x509: certificate is valid for celulinde, not > > > caranatar.xyz" > > On Fri, 2020-07-17 at 04:20 -0400, Caranatar wrote: > > > Ah crap apparently none of the clients I was using to test were > > actually > > verifying the certificate, and I forgot to change the CN when I > > copy/pasted my cert generation command from my laptop. It should be > > working now... > > What do other people think about this? My personal impression was that > in a trust on first use (TOFU) world, the common name (CN) of a > certificate could be anything. It could be "Alex Schroeder", for > example. Or it could be "alexschroeder.ch". Even if it was served as > the certificate for another domain, like transjovian.org. After all, > the question is only whether you "trust on first use". > > My impression is that a client that tries to verify that CN and domain > match is doing it wrong. What do you think? Sadly, my SSL know-how is > weak, so any pointers to how things ought to work in a TOFU world are > appreciated. > > Cheers > Alex

On Fri Jul 17, 2020 at 5:26 PM CEST, wrote: > On the surface I think you're right, that in the TOFU world, > CN shouldn't matter, and neither should subjectAltName, etc. > We shouldn't even need wildcard certs, because anything should be > accepted. There's some degree of sense in this, if the certificate is self-signed then none of the metadata attached to it is trustworthy in any sense, and anybody can make a cert with whichever domain(s) they like in the CN/SAN fields, so one could argue it should be ignored. I still wonder, though, if it doesn't make sense to check the domain names and expect them to match (AV-98 does this, for what it's worth), mostly just to help guard against configuration errors and things like that? Cheers, Solderpunk

On Sun, 2020-07-19 at 15:57 +0200, Solderpunk wrote: > I still wonder, though, if it doesn't make sense to check the domain > names and expect them to match (AV-98 does this, for what it's > worth), > mostly just to help guard against configuration errors and things > like > that? > I don't know. Do we HAVE to check? If we only have to check when the common name is an actual domain, how do we detect that, regular expressions? It seems to run counter to what TOFU promised. I fell it should be OK for transjovian.org to serve a wiki, and for alexschroeder.ch:1965 to show that wiki, even though it uses the certificate I used for transjovian.org. If the server domains have to match, then I have to do the SNI thing and server different certificates and that's going to make certificates harder, again. Please don't do this.

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. Thanks, Gary Alex Schroeder <alex at gnu.org> writes: > On Sun, 2020-07-19 at 15:57 +0200, Solderpunk wrote: >> I still wonder, though, if it doesn't make sense to check the domain >> names and expect them to match (AV-98 does this, for what it's >> worth), >> mostly just to help guard against configuration errors and things >> like >> that? >> > > I don't know. Do we HAVE to check? If we only have to check when the > common name is an actual domain, how do we detect that, regular > expressions? It seems to run counter to what TOFU promised. > > I fell it should be OK for transjovian.org to serve a wiki, and for > alexschroeder.ch:1965 to show that wiki, even though it uses the > certificate I used for transjovian.org. If the server domains have to > match, then I have to do the SNI thing and server different > certificates and that's going to make certificates harder, again. > > Please don't do this. -- 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

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

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