Can you explain what does this? I only ever see Apache replying to requests to the app domain. Can you provide example URL that reaches IIS for "files"?
Further background:
An ACME client is needed to get an LE cert. Certbot is one and wacs is another (there are many). Your system must "solve" a challenge before being granted the cert. The two most common challenges are HTTP and DNS (link here).
An HTTP challenge request has the format below. Apache is replying to this now. So, perhaps this format of URI is supposed to go to your wacs / IIS system. I don't know. More info about your system construct is needed before designing a cert solution.
curl -I http://app.rclwiring.com/.well-known/acme-challenge/Test404
HTTP/1.1 404 Not Found
Date: Thu, 26 Sep 2024 17:54:10 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html; charset=iso-8859-1
It doesn't help much to get a cert on the Apache system if the cert is actually needed on the IIS system. You'd still need a way to transfer and import it over there (which is needlessly complex)
Yeah, but that is a sideshow. Only affecting port 80 as well.
We were focused on getting app.rclwiring.com working and not sure whether it even belongs in this Apache or their IIS server. That overlap isn't related to the app problem.
@dpoe as an aside, you can happily run Apache on Windows if that makes more sense from a management perspective, you can even run most Apache content on IIS with the right modules installs (so, skip Apache altogether). The benefit of that migration for you it to consolidate the operating systems you are supporting. Migrating systems (and testing them before you go live!) is also an excellent way to understand what's going on and to take real ownership of a system.
As I think others have suggested if you are using Apache on Ubuntu the conventional options are to use Certbot or acme.sh to renew your certs directly on that server specifically for the sites that are on there, don't bother trying to share a wildcard between machines if you don't have to.
Yes you can proxy from IIS and handle or your certs there instead, but to do that your public domains all have to point to the IIS server IP, IIS needs a site with reverse proxy config for each domain pointing back to the Apache site (most commonly just as http internally, but that's up to you). Where that gets complex is the IIS server needs to forward the requests with the right host header to the apache server but of course the public IPs for those hosts point to the IIS server, so the trick is to use a hosts file to tell the windows server to see those domains as being the apache server IP. A bit complicated!
As others have mentioned the most common cause for renewals stopping working after switching to Cloudflare is that you're Cloudflare ssl config is Full Strict mode, so http requests don't reach the server on port 80. Lowering that will fix it and you can still proxy through cloudflare, which also means you get their automatic https while still being able to complete http challenges for your own certs .
If you are always using Cloudflare you could consider using a Cloudflare "origin" certificate, which is a special cert that Cloudflare will trust on the server and means you don't have to manage individual certs on the server itself, then just let Cloudflare do your public https for you.