Certificate on remote domain does not match, ignoring remote certificate (example.com != mydomain.net)

[kpebron]

mydomain.net is just a placeholder domain, not the actual domain name of my client's server.

Describe the bug Can't really say its a bug but maybe my procedure is faulty. I know that my server is old and EOL but I am not able to update to latest centos version (client discretion) and we have to make do with what we have. This is also the first time that we will implement SSL for this server since 2015 (been using http://ipaddress).

To Reproduce (All commands except for 1 uses sudo)

1. install getssl via git curl --silent https://raw.githubusercontent.com/srvrco/getssl/latest/getssl > getssl ; chmod 700 getssl
2. generate config file sudo ./getssl -c mydomain.net
3. Edit config file (/root/.getssl/mydomain.net/getssl.cfg)

   CA="https://acme-v02.api.letsencrypt.org"
   ACL=('/var/www/html/.well-known/acme-challenge')

4. Generate certificate sudo ./getssl mydomain.net

In this part, I am unable to generate SSL and getting error:

getssl: ERROR curl "https://acme-v02.api.letsencrypt.org" failed with 60 and returned:

curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html

From here, I swapped the ca-budle.crt from

5. wget --no-check-certificate https://curl.se/ca/cacert.pem
6. sudo mv /etc/pki/tls/certs/ca-bundle.crt /etc/pki/tls/certs/ca-bundle.crt_bk
7. sudo cp -p ./cacert.pem /etc/pki/tls/certs/ca-bundle.crt
8. rerun sudo ./getssl mydomain.net

At this part, I am getting error like title.

By the way, I can open in browser http://mydomain.net/.well-known/acme-challenge/ where the directory is empty

Edit: Another thing I forgot to mention is when I check the SSL certificate (clicking the red strikethrough https) it points to example.com not mydomain.net

Expected behavior Will generate the correct ssl certificate

Operating system (please complete the following information):

• CentOS 6.2 Apache/2.2.15

• Additional context Add any other context about the problem here.

[githubRover]

You might try posting this at the Let's Encrypt community https://community.letsencrypt.org/ The problem is that very old system is not properly validating the cert chain used by the Let's Encrypt API. It is not a problem reaching your domain, it is a problem with that server using the API.

But, either use your real domain name or 'example.com'. Unless mydomain.net is really yours in which case make sure you point that out. It looks like a fake name but it is a real domain belonging to someone.

If you don't get good help there you could try using a different ACME client (search github for acme.sh). And, then use a different Certificate Authority like ZeroSSL or Google CA. Their API cert chain may be better tolerated by that ancient Centos

[timkimber]

Hi @kpebron

I'm not convinced that this is a problem with the certificate chain (but it might be), can you post the logfile?

The message:

Certificate on remote domain does not match, ignoring remote certificate (example.com != mydomain.net)

is just a warning and shouldn't have caused getssl to fail.

If CHECK_REMOTE=true (the default) then getssl gets the current certificate to check expiry, find domains, etc. adding

CHECK_REMOTE="false"

to getssl.cfg will disable this behaviour

[githubRover]

@kpebron Sorry, I did not read past the error in your step 4. Updating the CA store as you did is not the best practice but since that Centos no longer gets updates I don't know that it will cause problems either.

I don't think the most recent problem would be helped by switching CA or ACME client.

[kpebron]

But, either use your real domain name or 'example.com'. Unless mydomain.net is really yours in which case make sure you point that out. It looks like a fake name but it is a real domain belonging to someone.

mydomain.net is just a placeholder to the actual domain name for my client. example.com is part of the error.

[kpebron]

@timkimber

is just a warning and shouldn't have caused getssl to fail.

If it is just a warning then I could move forward, however I forgot to mention but when I check on the ssl certificate (click on the red striketrhough https in browser) the SSL points to example.com, not mydomain.net (placeholder domain).

I will update my question and also try to post it to letsencrypt forum

as for the logfile, I will try to get it asap and post it here.

[kpebron]

@githubRover

Updating the CA store as you did is not the best practice but since that Centos no longer gets updates I don't know that it will cause problems either

I see, so it really boils down to Centos being EOL and mayby LE might reject it. I will try to check if there are other solutions for now.

[githubRover]

@kpebron No, that isn't what I meant. The error in step 4 was caused by the outdated CA Store which you resolved. There is a standard way to do that in Centos rather than what you did. But, I doubt that matters since that version of Centos is no longer updated anyway.

But, if you are seeing a cert with literally the name "example.com" then something is wrong with your server config (or possibly a firewall). It isn't related to GetSSL or Let's Encrypt for that matter but the people at the LE forum often help with such problems anyway. For this kind of problem the actual domain name will be required though. General advice from a general problem description probably won't get the help you need.

[kpebron]

@githubRover

Thank you for responding, yeah in the cert, the domain used is literally example.com not the domain that I wanted, which I did not use anywhere on my configuration. Hence I find it weird and tried asking here to see if there is a misstep that I did when I tried setting SSL to the server.

For additional note, I added ServerName mydomain.net to my vhost after I issued/downloaded the SSL cert using getssl thinking that it may correct the cert downloaded but did not work. I may try it again later by deleting the generated cert and re-issuing.

[githubRover]

The cert with "example.com" would not have been issued by Let's Encrypt. Frankly, it is impossible.

What is probably happening is your server (Apache?) is using a default self-signed cert rather than matching something using SNI. Or, maybe you are redirecting to the https://example.com URL. Which is a valid domain provided specifically for examples.

There is too much info missing. When you post in the Help section at the LE forum you will be asked a series of questions. Much of that is needed to help you with this kind of problem.

[kpebron]

I see. I will try to check it again later. Thank you for your input. I may need to recreate the cert. Since I generated the cert before I set the ServerName in vhost, that may be one of possible reasons. Once I did and found more, I will try to post them here again.

[githubRover]

There is no way Let's Encrypt issued a cert that included the name "example.com".

You can look in the public Certificate CT logs which public CA's log each cert. There is one for that name but issued by DigiCert

You can't get certs just for any name you request. You must satisfy an ACME Challenge (DNS, HTTP, TLS-ALPN). These all involve at least the public DNS record(s) for that domain name. You don't control example.com so cannot possibly have satisfied the ACME challenge for it.

See https://letsencrypt.org/docs/challenge-types/

[kpebron]

OK so I got it working. The reason was the default ssl.conf on apache ( getting certificates on /etc/ssl/file.crt). What I did was renamed ssl.conf to ssl.bkconf so that apache wont read the file without deleting it, then reconfigured the vhost to use the port 443 and correct cert location. The steps done above was correct.