Domain name mismatch with www in common name

Help
1

My domain is: eehmke.de

I ran this command: getssl -w /etc/getssl/ -u -k 3 eehmke.de

It produced this output:
eehmke.de: certificate is valid for more than 30 days (until Jun 1 13:03:34 2020 GMT)

My web server is (include version): Apache 2.4.38-3+deb10u3

The operating system my web server runs on is (include version): Debian 10.3

My hosting provider, if applicable, is: Netcup

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
getssl ver. 2.20

My config file is in /etc/getssl/eehmke.de/getssl.cfg. I have several subdomains that are configured in
SANS=“www.eehmke.de,
mail.eehmke.de,
…”
I understand that the primary domain should not be included in the list. All seems to work well, but when I check the certificate in my firefox browser, it shows www.eehmke.de as the common name. Firefox is happy with this, but when I test the domain in a domain checker, it complains about domain name mismatch. Also, when I use the openssl command to inspect the certificate, it shows
subject=CN = www.eehmke.de
I would expect that the primary domain eehmke.de would be the CN. Is this normal behaviour, or is there a problem?

2

eehmke.de (as a second level domain) is nowhere to be found in your certificate, you need to add it.

see for yourself: https://eehmke.de/

3

That’s the problem. The SANS is explicitely documented not to include the primary domain. Should I insert it nevertheless?

4

Why would you expect this? And especially, why would you expect this if "The SANS is explicitely documented not to include the primary domain"? Leaving aside that the CN is irrelevant to any halfway-modern client, on what basis would you expect that Let's Encrypt would pick a name you never gave it and put it on your cert?

5

I am not familiar with getssl, but I think you can definitely add it.

#create SAN
if [[ -z "$SANS" ]]; then
  SANLIST="subjectAltName=DNS:${DOMAIN}"
elif [[ "$IGNORE_DIRECTORY_DOMAIN" == "true" ]]; then
  SANLIST="subjectAltName=DNS:${SANS//,/,DNS:}"
else
  SANLIST="subjectAltName=DNS:${DOMAIN},DNS:${SANS//,/,DNS:}"
fi
debug "created SAN list = $SANLIST"

check if you enabled

IGNORE_DIRECTORY_DOMAIN

Because the client is documented to do so.

6

As I said, I use the getssl script,and this statement is from the getssl documentation.

7

Ah, my mistake--but that seems like very strange behavior for a client.

8

I’m one of the maintainers of the getssl project and have just been trying to reproduce this, but can’t.

With the following config:
SANS="www.getssl.test"

Calling getssl getssl.test generates a certificate with:

CN=getssl.test
X509v3 Subject Alternative Name: DNS:getssl.test, DNS:www.getssl.test

as expected. @eehmke has opened an issue at https://github.com/getssl/issues so I’ll follow up with them there.

9

What was the value of IGNORE_DIRECTORY_DOMAIN when you did your test?

10

The value of IGNORE_DIRECTORY_DOMAIN was “true”.

The config file is getssl/test/test-config/getssl-ignore-directory-domain.cfg in the test-multiple-domain branch on github and the bats test script for this scenario is getssl/test/9-multiple-domains-dns01.bats

You can see the output of the test in the PR on alpine, centos6, centos7, debian and ubuntu in PR-534

If you can provide me the contents of your custom DNS updater script and the debug output from getssl I’ll try and reproduce your problem and fix it for you.

11

I am sorry, I moved to certbot in the meantime, that does the job as expected. I don’t have the time to do any more analysis of this getssl related problem.

12

No problem, thanks for letting me know