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
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
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:
When initiating the certificate request, use a hook (program or code) to copy the validation file to all your servers (Both SG and US)
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).
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. 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:
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, 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):
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…)