Much confusion about subject and domain names

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?

1 Like

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.

1 Like

where does this come from?

is nginx configured to use that directory?

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 https://www.ssllabs.com/ssltest/analyze.html?d=drawmeakicker.com&hideResults=on

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

2 Likes

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.

3 Likes

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!

2 Likes

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;
2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.