Getssl not creating .well-known/acme-challenge/token

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: 3dpdx.org

I ran this command: getssl 3dpdx.org

It produced this output: 3dpdx.org: Certificate on remote domain does not match, ignoring remote certificate

My web server is (include version): Apache/2.2.29

The operating system my web server runs on is (include version): Mac OS 10.9.5 / OS X Server 3.2.2

My hosting provider, if applicable, is: N/A

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): N/A

The getssl command is creating the .well-known directory and the .well-known/acme-challenge directory on my web server, but it is not creating the token file in that directory. Because the token file is not getting created, it is not surprising that access to http://pdx3d.org/.well-known/acme-challenge/token fails, and it is not surprising that I get the Certificate on remote domain does not match, ignoring remote certificate error message.

Running getssl -v does not produce any obvious clues. The question is, why is getssl unable to create the token file after successfully creating the .well-known/acme-challenge directory ?

Hi herbw

Your domain, 3dpdx.org, is returning a certificate for emerald.wiskit.com instead of for your domain so getssl thinks something is wrong and shows the "certificate does not match" error (which isn't particularly helpful - I'll fix).

If you use --force then getssl will skip this check and continue to create a certificate, i.e.

getssl --force 3dpdx.org

It sounds more like a warning?

The Let's Encrypt validation server doesn't care about the certificate. Why does getssl require an extra option to disable this check?

Also, I'm a little bit confused by the "remote domain" part: which remote domain is meant? The Let's Encrypt validation server? Which obviously should be validated! Most of the time, an ACME client is ran on the same server as where the website is hosted, so it most likely would be the local domain for which the certificate might mismatch.. I'm confused.

Hi Osiris

I've just been doing some testing and you're right; it is treated just as a warning, the extra step isn't required to create a certificate.

getssl checks the certificate to see if it needs renewing or if the local copy of the certificate is newer, in which case it copies the local copy to the webserver.

Apologies for the confusion over the terminology - I don't have a remote shell on my hosting provider so I run getssl locally and update the certificate on the "remote" server.

1 Like

Thanks, timkimber.

Just to clarify, if I use --force, will getssl skip the check and continue to return a certificate for emerald.wiskit.com, or will getssl skip the check and return a certificate for 3dpdx.org, as requested?

Note that emerald.wiskit.com serves multiple VirtualHosts (including 3dpdx.org), and eventually I will need certificates for all of these VirtualHosts.

Hi herbw

getssl shouldn't have stopped after printing that warning, but regardless, if you request a certificate for 3dpdx.org it will try and create a certificate for that domain.

Running multiple VirtualHosts on a single webserver should not cause any problems.

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