Invalid challenge with different regions

We have used openresty (Nginx based) with lets encrypt + Redis to store SSL
However we use aws route 53 regional routing
one is in US + Redis in US , another one is in SG + Redis in SG

we have encountered below error when issue a new SSL

Responding to challenge for www.khxg.tw authorization…
Invalid challenge: DOMAIN=www.khxg.tw RESPONSE={
“type”: “http-01”,
“status”: “invalid”,
“error”: {
“type”: “urn:acme:error:unauthorized”,
“detail”: “Invalid response from http://www.khxg.tw/.well-known/acme-challenge/awRY-pr_BFdU4kTiJr3AcIn7NzkrBqU1fHB363cUnbE [52.201.120.204]: “\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e404 Not Found\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e404 Not Found\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/cente””,
“status”: 403
},
“uri”: “https://acme-v01.api.letsencrypt.org/acme/chall-v3/203063797/H4lYOw”,
“token”: “REMOVED”,
“validationRecord”: [
{
“url”: “http://www.khxg.tw/.well-known/acme-challenge/awRY-pr_BFdU4kTiJr3AcIn7NzkrBqU1fHB363cUnbE”,
“hostname”: “www.khxg.tw”,
“port”: “80”,
“addressesResolved”: [
“52.201.120.204”,
“18.207.60.197”
],
“addressUsed”: “52.201.120.204”
}
]

We have a question, is it that we cannot request from SG enduser and issue to US openresty
if yes, another best practise suggestions for multiple regions requesting SSL

Thanks

Hi,

Do you mean you use two regional endpoints to separate traffic? And the traffic is distributed to U.S and SG regions? Are you trying to initiate a certificate request from SG server, but the validation servers ends up hitting the U.S. based server(which obviously don’t hold the file)?

If all the above are true, you actually have two options:

  1. When initiating the certificate request, use a hook (program or code) to copy the validation file to all your servers (Both SG and US)
  2. Use route53 DNS API and complete DNS validation instead.

Also, if you already get a certificate for your US based server, you could also copy that certificate from your US based server to the SG servers (if you don’t want to reissue certificate).

Thank you

at some point you have used “uri” in stand of “URL”.

Hi @ianchan0817

checking your domain there is a new certificate - https://check-your-website.server-daten.de/?q=khxg.tw#ct-logs

Issuer not before not after Domain names LE-Duplicate next LE
Let’s Encrypt Authority X3 2019-09-06 2019-12-05 www.khxg.tw - 1 entries duplicate nr. 1

5 days old. And you use that certificate.

The certificate has only the www domain name, so only the www version is secure. But your non-www has a ip.secureserver.net GoDaddy-ip address, so that’s another server.

How did you create that certificate?

What’s your client, what’s your command?


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. https://crt.sh/?q=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:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

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

yes, that’s our case
coz we have two different openresty and redis to store the generated ssl

actually we thousands of domains parking to us
and they just CNAME our domain

if the traffic requested from US then going to US openresty
otherwise going to SG openresty

yes, thanks We use
Docker: FROM openresty/openresty:alpine-fat
actually

inside the containers

My domain is: www.khxg.tw

I ran this command:
this container help on managing it
should be this

It produced this output:
{
“type”: “http-01”,
“status”: “invalid”,
“error”: {
“type”: “urn:acme:error:unauthorized”,
“detail”: “Invalid response from http://www.khxg.tw/.well-known/acme-challenge/awRY-pr_BFdU4kTiJr3AcIn7NzkrBqU1fHB363cUnbE [52.201.120.204]: “\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e404 Not Found\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e404 Not Found\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/cente””,
“status”: 403
}

My web server is (include version):
FROM openresty/openresty:alpine-fat

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

My hosting provider, if applicable, is:
aws

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 versioncertbot-auto --version if you’re using Certbot):

for solutions 1
maybe we share the redis

however, the latency from US application nginx is high to SG redis to store the validation file…

Yeah.
I don’t think sharing the http files across the two containers are a great idea.
It’s better if you could ask all the domains (you have) to cname the txt validation ( _acme-challenge) to one of your API controlled domains.

Or, initiate the certificate issuance request from your US instance and copy the certificate to your Asia instance after you got the certificate. (However, there might be a chance that Let’s Encrypt validation server select the Asia server instead of US server, so it’s safe if you could / would copy the validation files to both of your servers) (This is definitely painful…)

Dehydrated actually provides build-in Route53 support. (https://github.com/lukas2511/dehydrated/wiki/Examples-for-DNS-01-hooks)

Thank you

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