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.
It produced this output:
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for api.asiainspection.cn
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. api.asiainspection.cn (tls-sni-01): urn:ietf:params:acme:error:unenge. Requested d66b1ea63d3cc1957931e74b721fb592.de8636590e46d47a65e9e8055a6d98da.acme.invalid fr
IMPORTANT NOTES:
The following errors were reported by the server:
Domain: api.asiainspection.cn
Type: unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge.
Requested
d66b1ea63d3cc1957931e74b721fb592.de8636590e46d47a65e9e8055a6d98da.acme.invalid
from 52.83.226.25:443. Received 2 certificate(s), first certificate
had names “api.asiainspection.cn”
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address
My web server is (include version): nginx/1.10.3 (Ubuntu)
The operating system my web server runs on is (include version): Ubuntu
My hosting provider, if applicable, is:
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):
I deleted some file in /etc/letsencrypt and restore them from the backup.
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address
You can change to a different authentication method with the existing certificate, but you’ll need to pick one that will work.
If you specify -d api.asiainspection.cn in your Certbot command line together with the options related to the new authentication method, Certbot should update its renewal configuration for the existing certificate and then the new options will be used for future renewals.
@_az’s diagnosis is right: --nginx only works when you’re running nginx. You might be able to use --webroot if there’s a place on the disk where you can place static files that Tomcat will then serve. There are also other options if this isn’t the case.
When using Tomcat, you normally also need a script that converts the new certificate and key from PEM format into another format that Tomcat can understand, such as PFX, since Tomcat apparently can’t read these files in PEM format. Such a script could be run automatically from Certbot if you specify it to Certbot using the --deploy-hook option.
Hi Schoen,
I tried certbot certonly --webroot -w /usr/local/tomcat/webapps -d api.asiainspection.cn, but got below errors:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for api.asiainspection.cn
Using the webroot path /usr/local/tomcat_8081/webapps for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. api.asiainspection.cn (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://api.asiainspection.cn/.well-known/acme-challenge/FihAluCYTq-0hZr_49N-C8uDVfT2zQeh0S3pr6p2JT0: “Apache Tomcat/7.0.86 - Error report<!–H1 {font-family:Tahoma,Arial,sans-serif;color:white;bac”
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for api.asiainspection.cn
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. api.asiainspection.cn (tls-sni-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested a6dba7ddee3eda4c9aac9aed7188c499.a8301f7b63ca0b9ace0fe5488ea2a6e2.acme.invalid from 52.83.226.25:443. Received 2 certificate(s), first certificate had names “api.asiainspection.cn”
IMPORTANT NOTES:
The following errors were reported by the server:
Domain: api.asiainspection.cn
Type: unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge.
Requested
a6dba7ddee3eda4c9aac9aed7188c499.a8301f7b63ca0b9ace0fe5488ea2a6e2.acme.invalid
from 52.83.226.25:443. Received 2 certificate(s), first certificate
had names “api.asiainspection.cn”
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
Is it correct that if you create files in /usr/local/tomcat_8081/webapps, you can see the files on the web under http://api.asiainspection.cn/? For example, if you created a file /usr/local/tomcat_8081/webapps/test.txt, would it be visible at http://api.asiainspection.cn/test.txt?
Hi @schoen, here is what happened:
We applied current certificate with nginx running and serving 80/443. later we stopped nginx and converted that key to pfx, and tomcat serving 80/443 directly. It’s working fine but now we need to renew.
FYI if we put test.txt under /usr/local/tomcat_8081/webapps, http://api.asiainspection.cn/test.txt won’t be accessible because our application in tomcat intercept all the request and tomcat is not serving static html pages. We can make http://api.asiainspection.cn/test.txt accessible but the test.txt has to be in /usr/local/tomcat_8081/webapps/ROOT/WEB-INF/, will this work?
Note that the specific filename used is different for every renewal attempt (it is a random string created by the certificate authority). You wouldn’t expect to find the old ones still on disk, because they have no continuing relevance and are normally deleted automatically by Certbot after the certificate issuance either succeeds or fails.
Thanks @schoen, we added a static folder in our application and allow everything from the static folder can be accessed publicly, then specify that folder as the web root, then certificate renewed.