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 web server is (include version):
Apache Tomcat Version 8.5.14
The operating system my web server runs on is (include version):
Ubuntu 14.04.6 LTS
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 panel
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
certbot 0.31.0
Renewing this time failed with the error above, though renewal has worked fine in the past. I’m not sure what has changed that would cause the above message for the domain justatest.com.
The DNS A records for domain justatest.com and www.justatest.com point to my tomcat webserver. The cert on that server handles other virtual hosts (one of which is justatest.com).
Tips to troubleshoot this are gratefully appreciated.
thanks!
jp.
But your error says, that the http answer is wrong (not a https result). So you may have used a wrong authenticator that doesn't work with your Tomcat.
Apologies I’m a newbie so I don’t understand the specific reference in your sentence:
“…But your error says, that the http answer is wrong (not a https result). So you may have used a wrong authenticator that doesn’t work with your Tomcat.”
Which error are you referring to? And what is the authenticator that certbot uses and expects in reply?
using the command certbot certonly --cert-name www.artprocess.net-0001 (by listing the -d domains I wanted and leaving out the justatest ones). The certificate was renewed successfully.
However when I try to add in the justatest domains again using the [certbot certonly --standalone -d www.justatest.com -d justatest.com -d others…] command, I get the unauthorized invalid response error again:
How do I re-create an acme-challenge that will solve this problem? I’ve added a .well-known/acme-challenge directories to the justatest.com webroot and created a test file containing the word ‘success’.
It seems like you might be confusing standalone and webroot. The webroot method involves creating files on your existing webserver (which Certbot should do for you—you don’t have to do it yourself), while the standalone method is a complete alternative to your existing web server, which normally requires you to stop the existing server process while obtaining your certificate.
Right now, there is something listening on http://justatest.com/ on port 80, so if you want to use the standalone method, you would have to shut that down temporarily in order to free up port 80 for Certbot to use.
You’re right, I had confused them at first.
But now I’ve come up against a server renew limit (oops!) as I wasn’t aware that I should have been using the
–dry-run
flag. From what I understand, I need to wait until next week for it to clear.
However even when I tried webroot and specified the directory, the unauthorized error kept occurring. I can’t seem to overwrite the acme-challenge with a new one - is that possible?
I think the original problem stemmed from the fact that I deleted and re-created the justatest directory structure on the webserver some weeks ago. I wasn’t aware of .well-known/acme-challenge directories.
BTW, I don’t see any other “.well-known” directories on the webserver for the artprocess.* domains? Is is possible that the challenge type used is not HTTP-01? How can I confirm which type of challenge is being used?
Certbot creates those for you too, so you should never need to create them yourself. Nor should accidentally deleting them prevent Certbot from working. Remember that what you need to specify with -w when using --webroot is the top level of the site, not the /.well-known/acme-challenge path (Certbot will take care of that part).
If you successfully used any method other than --webroot, you wouldn't necessarily have these directories because they wouldn't have been used, or would have been created in a completely ephemeral way.
You can find out from the logs in /var/log/letsencrypt, or you can look in /etc/letsencrypt/renewal to see what the authentication method used for each certificate was.
If you try again next week and get an unauthorized error, we can try to help figure it out. I agree with @JuergenAuer that it would be helpful to understand what "administrative quarantine" means here and where that message is coming from.
(Currently no Certbot plugin supports the ALPN-01 challenge, which means that if you're using Certbot you're either going to be using HTTP-01 or DNS-01. Most Certbot users use HTTP-01 almost all of the time unless they're creating a wildcard certificate, but plugins other than webroot won't create a /.well-known/acme-challenge directory in a persistent way that you can see.)