Much confusion about subject and domain names

[mika]

My domain is: www.surfingdirt.com

I ran this command:
certbot certonly --agree-tos --email something@gmail.com --webroot -w /var/lib/letsencrypt/ --cert-name surfingdirt -d api.surfingdirt.com -d beta-api.surfingdirt.com […] -d surfingdirt.com -d www.surfingdirt.com

I also ran this (and similar commands for other domains):
sudo certbot certonly --agree-tos --email something@gmail.com --webroot -w /var/lib/letsencrypt/ --cert-name drawmeakicker -d www.drawmeakicker.com -d drawmeakicker.com

My web server is: nginx/1.15.5 on Ubuntu 18.04

The version of my client is: certbot 0.27.0

My problem is the following:

• some of my users are reporting their browser refusing to connect (on Android: ERR_CONNECTION_RESET for example, but similar things happen on iOS)
• I ran Hardenize and it reported a problem: the domain name does not match the subject in the certificate (see https://www.hardenize.com/report/surfingdirt.com/1585242809#www_certs). It “sees” that the certificate’s subject is drawmeakicker.com (which I also own and manage)

• Indeed, on my mac, the following openssl (1.0.2k) command reports a “link” to drawmeakicker: openssl s_client -connect www.surfingdirt.com:443 -prexit
  CONNECTED(00000003)
  depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
  verify return:1
  depth=1 C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3
  verify return:1
  depth=0 CN = www.drawmeakicker.com
  verify return:1

  Certificate chain
  0 s:/CN=www.drawmeakicker.com
  i:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
  1 s:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
  i:/O=Digital Signature Trust Co./CN=DST Root CA X3

  Server certificate
  -----BEGIN CERTIFICATE-----
  …
  -----END CERTIFICATE-----
  subject=/CN=www.drawmeakicker.com
  issuer=/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3

• However, the same command on some of my other machines does not indicate a problem (openssl 1.1.1) since it reports api.surfingdirt.com instead of drawmeakicker.com:
  CONNECTED(00000005)
  depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
  verify return:1
  depth=1 C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3
  verify return:1
  depth=0 CN = api.surfingdirt.com
  verify return:1

  Certificate chain
  0 s:CN = api.surfingdirt.com
  i:C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3
  1 s:C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3
  i:O = Digital Signature Trust Co., CN = DST Root CA X3

  Server certificate
  -----BEGIN CERTIFICATE-----
  …
  -----END CERTIFICATE-----
  subject=CN = api.surfingdirt.com

So I’m super confused. I don’t see why the certificate for drawmeakicker.com has anything to do with that of surfingdirt.com.

I feel like there is some kind of concept I’m missing here. Are the certbots commands I ran ok?

[bruncsak]

The domains www.surfingdirt.com and surfingdirt.com has no IPv6 addresses. Is that the way you want? It may not be related to your issue, but better to fix just in case, to have consistency.

[9peppe]

@mika

--webroot -w /var/lib/letsencrypt/

where does this come from?

is nginx configured to use that directory?

@mika

some of my users are reporting their browser refusing to connect (on Android: ERR_CONNECTION_RESET for example, but similar things happen on iOS)

these user are probably trying to connect over ipv6, and your server does not respond. You have to tell nginx to listen on ipv6 too, or remove the aaaa record SSL Server Test: drawmeakicker.com (Powered by Qualys SSL Labs)

@mika

I ran Hardenize and it reported a problem: the domain name does not match the subject in the certificate (see Hardenize: Comprehensive web site configuration test). It “sees” that the certificate’s subject is drawmeakicker.com (which I also own and manage)

They are right, you probably send both certificates, scroll the page and you'll find the right certificate. You only need one.

[Osiris]

@mika

Indeed, on my mac, the following openssl (1.0.2k) command reports a “link” to drawmeakicker: openssl s_client -connect www.surfingdirt.com:443 -prexit

CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3
verify return:1
depth=0 CN = www.drawmeakicker.com
verify return:1

Try adding -servername www.surfingdirt.com to the command on your OpenSSL 1.0.2k (Mac). This sends the hostname in the TLS handshake. On OpenSSL 1.1.1 this is send automatically without the extra servername option, so that version showed the correct certificate.

The fact you're seeing another certificate without the servername option on OpenSSL 1.0.2 is perfectly normal. Please read more about server name indication to learn why this is happening.

Also, this is most likely unrelated to the connection reset issue.

[mika]

Thanks everyone for your insight.

After posting this, I removed the IPV6 aaaa because I realized my Nginx conf did not handle it. I think that fixed the problem in the sense that users were not using ipv6 to get to the sites anymore. Obviously that’s not the ideal long term solution.

I also read up on SNI and can finally make sense of the situation.

Many thanks!

[9peppe]

@mika

After posting this, I removed the IPV6 aaaa because I realized my Nginx conf did not handle it. I

you know, your nginx probably has a listen 443 ssl; directive, you'd have to add, directly below, a listen [::]:443 ssl; directive. (in the appropriate server block)

---

you may even want to go for:

listen 443 ssl http2;
listen [::]:443 ssl http2;