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: euat.udc.es
I ran this command: certbot --apache -d euat.udc.es
My web server is (include version): Apache/2.4.29 (Ubuntu)
The operating system my web server runs on is (include version): Ubuntu 18.04.6
My hosting provider, if applicable, is: Im runinng from a University VPS which I access through a VPN
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 : Yes (Webmin 1.994)
The version of my client is: certbot 0.27.0 (Previously tried through snap, same result)
I created the path to .well-known/acme-challenge/ and uploaded and tested I can access from a windows client outside the network
I have tried turning off apache ssl
I have the exact same problem on another Ubuntu 16.04 machine running letsencrypt and have been warned my certificate will expire in 6 days. Same problem completing the challenge.
I tried a manual (http preference challenge) install but was unable to get to the point of asking my to upload a file. For this manual attempt the feedback is "Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS."
I dont use bind or and DNS on the machines. DNS is handled by the University which created the VPS.
It looks like your university firewall is blocking requests when they have a user-agent from Let's Encrypt. The first curl with the -A uses the same user-agent string as the actual Let's Encrypt servers. You can also see the failure using Let's Debug.
curl -I http://euat.udc.es/.well-known/acme-challenge/Test123 -A "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
curl: (56) Recv failure: Connection reset by peer
curl -I http://euat.udc.es/.well-known/acme-challenge/Test123 -A "Something Else"
HTTP/1.1 404 Not Found
Date: Mon, 06 Jun 2022 16:24:31 GMT
Server: Apache/2.4.29 (Ubuntu)
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=iso-8859-1
Hi, thanks for the really fast and detailed reply.
Is it possible that the machine that I manage is blocking requests and not the University itself?
How might I determine if it is in my Ubuntu installation?
Secondly, is there a way that I can obtain the key files for a certificate, upload them to the server, and install something on the server that can then be confirmed (which is what I thought was the http challenge). As though I didn't have SSH access.
I understand the manual is a horrible solution, but I only have 6 days before the other server certificate expires and there seems to be something to do with HSTS (I think) that blocks the general community from accessing the site as it doesn't have a working certificate. At least that is what they were complaining about.
When the certificate on euat.udc.es expired, I was unable to renew it. I tried for 3 days, using different strategies. I upgraded the server at that point from Ubuntu 16.04 to 18.04 hoping that there was an issue with the server and I could rebuild the network etc. (besides I was stuck with PHP 7.2 and it needed updating. The problem persisted. This included that no one could access the site from public IP. I noticed that the web could be viewed if I used the IP address, but not if I used the domain. I imagined that the problem that CERTBOT was having was related to the fact that no traffic using the FQDN could get through either. Then I found some information about HSTS or whatever it is, and when I cleared my Chrome SSL sites I saw that the server was working, on port 80 and so I installed an alternative SSL certificate - OPENSSL I believe . to see if I could get something working.
When I was then able to test the domain/.well-known/acme-challenge with the FQDN I removed the alternative SSL files, turned off SSL so that Certbot could connect at port 80 but the error persists.
I have another server (ciencias.udc.es) running a letsencrypt certificate that will expire in 6 days if I don't solve the problem with euat.udc.es. Given that the problem exists in both Ubuntu 16 and Ubunto 18 Im looking for a more specific area where the problem might be.
I should add that on the current problem, (euat.udc.es) which expired a week ago, I uninstalled letsencrypt completely, uninstalled Certbot, tried Certbot with snap, no luck, This is why in this server I am trying to install a new certificate, but in the other server, which still has an active certificate, I am hoping to be able to renew it. But they both produce the exact same error: Challenge failed. And I am assuming that its for the same reason.
First, you did not yet remove the self-signed cert. You can see it is still being sent using this SSL Decoder Test Site. This is not affecting your cert renewal, just wanting to clarify where you are.
You say certbot can connect at port 80 but we have shown this is not the case. And, technically it is not certbot that connects to port 80 but the Let's Encrypt Servers that do this. Certbot is the acme client which asks the Let's Encrypt server for a cert. The LE Server then makes the connection to prove you control the domain name. This is failing as we've shown.
You should focus on why these curl and Let's Debug tests are failing. Once those are fixed your cert renewal should be fine.
Oh, curl and Let's Debug tests to this domain fail in the same way as your other domain. That is, user-agent strings used by Let's Encrypt Servers fail but other user-agents are fine.
Both domains are almost certainly restricted by the same thing. And this is most likely a university level firewall. Or, at least a single firewall common to these two domains.
By "removed" I mean I renamed the ssl config file and temporarily removed all installation information. I then turned off ssl to try to run Certbot clean on port 80 to avoid redirects to https.
When that still failed, I gave up (day 5 of trying everything) and put the self-signed certificate back online as it seemed to at least allow people to access the site albeit with the warnings in the url bar. And then came here.
Thank you all for helping out with the issue. In the end as suggested by several members, it was an issue with the University network managers. Apparently they began to manage Let's encrpt certificates (without anyone informing me of this) but since I already was using the service, I take it they added my IPs to allow access. All solved. Thanks again!