Well that’s interesting! Thanks for the additional info. I have one idea for a way to work around the problem and another idea on how to debug it further.
The workaround is to try adding --preferred-challenges http
to the command line. This will cause Certbot to use a different challenge type which might work better for your setup.
My best solution to help debug the problem is a little trickier. First, run sudo certbot certonly --standalone -d www.cupon2go.com --debug-challenges --verbose
. This will cause to print a lot of output to the terminal as well as stop with the message:
-------------------------------------------------------------------------------
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
-------------------------------------------------------------------------------
Press Enter to Continue
When you see this, on another machine run:
openssl s_client -connect www.cupon2go.com:443 -servername foo
You should see something like the following output from Certbot:
Performing handshake with ('::ffff:1.2.3.4', 12345, 0, 0)
Server name (foo) not recognized, dropping SSL
If you don’t, something is preventing the request from getting to Certbot.
If you see that output, hit enter on your terminal running Certbot to have it continue. In the output immediately after pressing enter, you should see output like:
JWS payload:
{
"keyAuthorization": "WKzRwxWSbT8sXWbP0Uza8Whb5i69VdGch26BFrvt6qM.qlCO-llhghLuz3W3Wk82B6PmWgycWFnRHW0Y76uixHA",
"type": "tls-sni-01",
"resource": "challenge"
}
You’ll probably have to scroll back up to see this because Certbot generates a lot of output in this mode. What you want here is the value of the keyAuthorization
after the .
character. For the above value, this is qlCO-llhghLuz3W3Wk82B6PmWgycWFnRHW0Y76uixHA
.
Make a note of this value and run Certbot again with the same command. In the output shortly before Certbot stops again, you should see output like:
{
"identifier": {
"type": "dns",
"value": "www.cupon2go.com"
},
"status": "pending",
"expires": "2017-11-06T20:59:13.60235025Z",
"challenges": [
{
"type": "dns-01",
"status": "pending",
"uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/M2a96xHX6lrhkxevtKjks0Q4YqH9W97TszZAmzAtPFKa/72641828",
"token": "sbPnxEw5_48Zv9UQ7ZBpkewasUKicGw_ffX4MIh6y3g"
},
{
"type": "http-01",
"status": "pending",
"uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/M2a96xHX6lrhkxevtKjks0Q4YqH9W97TszZAmzAtPFKa/72641829",
"token": "n-yKedsuggIzArF18wOXD211bpJ4u9rtVCjSb_xH8WM"
},
{
"type": "tls-sni-01",
"status": "pending",
"uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/M2a96xHX6lrhkxevtKjks0Q4YqH9W97TszZAmzAtPFKa/72641830",
"token": "N4ZbiR5GbQnOD_ggNkHbyM53HtJi57FAa1l35oYMnDI"
}
],
"combinations": [
[
2
],
[
0
],
[
1
]
]
}
Here what you want is the token for the token for the “tls-sni-01” challenge. From the output above, that would be N4ZbiR5GbQnOD_ggNkHbyM53HtJi57FAa1l35oYMnDI
.
Using these two values, you can construct what name Let’s Encrypt is looking for in the certificate. Concatenate this token value to the value you obtained before, adding a “.” in the middle. Using these example values, this would be:
N4ZbiR5GbQnOD_ggNkHbyM53HtJi57FAa1l35oYMnDI.qlCO-llhghLuz3W3Wk82B6PmWgycWFnRHW0Y76uixHA
Now to construct the value Let’s Encrypt is looking for, run the following command replacing <ka>
with the long value you just constructed:
echo -n <ka> | sha256sum | cut -f 1 -d ' ' | sed -e 's/^\(.\{32\}\)/\1./' -e 's/$/.acme.invalid/'
Continuing with the example values, this would give you:
c89a9958936426b77bc1fe3b28bbf022.2c79bc847b1edfec64d62a58ec14fbc0.acme.invalid
This would be the name Let’s Encrypt is looking for in the certificate. On another machine, run:
openssl s_client -connect www.cupon2go.com:443 -servername <domain>
where domain is the output of the shell command above. When you do this, if you haven’t made any mistakes and I haven’t made any mistakes in my explanation, you should see something like:
Performing handshake with ('::ffff:1.2.3.4', 123456, 0, 0)
::ffff:1.2.3.4 - - Incoming request
output from Certbot and output from openssl s_client
that starts with:
CONNECTED(00000003)
depth=0 CN = dummy
Hopefully the --preferred-challenges
workaround is enough, however, I would be interested in knowing where you start seeing different output when following my lengthy debugging process.
I hope this helps!