You are correct. Use of https always gets a 404 and use of http gets a 301. Now a while back I enabled X frame options for sameorigin and I enabled HSTS but I have since disabled them both and those don't seem to change anything after and apache restart. Is there any other reasons http request won't go through but https does?
HTTP does not get a 301 for me (or anyone else in this thread and not for the Let's Encrypt server). It fails with connection reset by peer.
2 Likes
I do get a 301 on paths different from /.well-known/acme-challenge/<something>
If I add the last /, it goes on connection reset.
1 Like
Yes, I meant HTTP with the same path as Let's Encrypt server would use. As I showed in my samples on post #39
2 Likes
Jeez I really appreciate all your help but I really don't even know where to go form here. I don't get why our http requests wont go through but our https ones will. We have HSTS disabled. No xframe options. No firewall. No intermediaries between us and the ISP. What else can there be?
We et a 301 for any use of http which we need to make the request. Https gives 404 but that doesn't really matter. Anytime we try to run:
certbot certonly
or use webroot or anything it fails because of a connection reset by peer.
Any more ideas at this point?
Someone earlier asked for you to look for .htaccess files. Did you check that out?
2 Likes
Yeah no .htaccess files exist anywhere. They are missing plus I don't think they are even enabled for use in my apache settings.
You could try using the DNS challenge instead of HTTP. Do you have control of the DNS records?
1 Like
We do not have control of that. None of our websites start with www. DNS-01 extension does not work. We also have no SeverAlias listed for it
The actual name does not matter. But DNS challenge does require ability to update the DNS records. You add a TXT record with challenge data for verification.
You can also get fancy and redirect DNS challenges with CNAME.
1 Like
We do not have the ability to update DNS records unfortunately
Well, somebody at W Mich does 
These are your name servers:
ceas.wmich.edu. 300 IN NS gumby.cc.wmich.edu.
ceas.wmich.edu. 300 IN NS gw.wmich.edu.
ceas.wmich.edu. 300 IN NS ns.wmich.edu.
and
wmich.edu. 300 IN NS dns.merit.net.
But, if DNS challenge is not viable I don't have any other suggestion than purchasing a set of certs using email verification or the like. No other acme system will be able to validate an HTTP challenge either.
I still think the problem is likely a network appliance at the university level that you are not aware of. I say that only because past problems like this were caused by that and it would explain all the symptoms we see.
Best of luck to you.
2 Likes
Let me point to the full-grown elephant in the room:
It's APACHE [notorious for running at all cost]
Have we confirmed there is no name:port overlap?
If not, please show:
apachectl -t -D DUMP_VHOSTS
1 Like
If you stop apache and run certbot with standalone does it validate? If so, then it's the apache config, if not then it's higher up the food chain (possibly an IP blacklisting tool like fail2ban or something on your network redirects /.well-known/acme-challenge to a different server).
5 Likes
If I know my universities, they have a /16 IPv4 subnet and "the modem" is a few sfp+ switches with BGP and a separate DHCP server, with the servers on public IPs and clients on some NAT.
2 Likes
Then how can we explain?:
And:
If I know my universities...
There is definitely a firewall there (somewhere).
3 Likes
IndianaMichigan Jones and the search for the lost appliance.
3 Likes
Running this gives us this error:
[Fri Apr 08 10:41:11.657043 2022] [so:warn] [pid 63834] AH01574: module php7_module is already loaded, skipping
AH00526: Syntax error on line 35 of /etc/apache2/sites-enabled/default-ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/wiki.ceas.wmich.edu/fullchain.pem' does not exist or is empty
Action '-t -D DUMP_VHOSTS' failed.
The Apache error log may have more information.
but this is because the cert no longer exists. We went from trying to renew it to just deleting it and creating a new one. But that's not working either.
We are an IT department that is part of a smaller branch of the college and the requests we make flow through another firewall that is set up by of Office of Information Technology but we have met with them and they told us all of our requests are not being denied by their firewall as they always have. Our packets complete the SSL handshake with acme-challenge
do you have this problem with every server or just this one?
1 Like