403/404 on the secure version of my site (solved)

Hi. I'm having a frustrating problem. I'm using IIS under Windows Server 2016 and win-acme 2.2.8.1635 (release, pluggable, standalone, 64-bit). I create a site, issue a cert, but trying to load the secure version of the site fails with 403. Here were my steps:

I created my site in IIS, just giving it an HTTP binding to data.nischan.com.
Once that was done, I went in my browser to http://data.nischan.com and it worked fine
I then opened an admin command prompt and ran wacs
I hit create certificate, chose the data site, all bindings, continued and got:

Source generated using plugin IIS: data.nischan.com

Plugin IIS generated source data.nischan.com with 1 identifiers
Plugin Single created 1 order
[data.nischan.com] Authorizing...
[data.nischan.com] Authorizing using http-01 validation (SelfHosting)
[data.nischan.com] Authorization result: valid
Downloading certificate [IIS] nischan.com - data, (any host)
Store with CertificateStore...
Installing certificate in the certificate store
Adding certificate [IIS] nischan.com - data, (any host) @ 2024/3/24 to store WebHosting
Installing with IIS...
Adding new https binding *:443:data.nischan.com
Committing 1 https binding changes to IIS while updating site 2
Scheduled task looks healthy
Adding renewal for [IIS] nischan.com - data, (any host)
Next renewal due after 2024/5/18
Certificate [IIS] nischan.com - data, (any host) created

I then went back to the browser and tried the https version and I get:

Access to data.nischan.com was denied
You don't have authorization to view this page.

HTTP ERROR 403

Googling suggested I verify the account IIS runs under has NTFS perms to the folder, which it does. I imagine if it did not, HTTP version would also fail. Any ideas what I can look at to figure out what is going on?

PS - I just noticed something weird. If I do https://data.nischan.com/index.php, I don't get 403 I get 404:

This data.nischan.com page can’t be found

No webpage was found for the web address: https://data.nischan.com/index.php

HTTP ERROR 404

The file is definitely there; it works as non SSL after all. Any idea what is going on here?

Thanks!

1 Like

PS I tried the "Let's Debug" page and it gave me a warning about CloudFlare and enabling strict SSL. I did that, but the LD page still has the same warning. I then just turned off the proxy all together and let the IP pass through. The LD page shown green and happy, but the error on my site persisted.

The Cloudflare DNS proxy is still in place. I get an HTTP error 500. This is usually a comms problems between Cloudflare and your server. Are you sure your port 443 is open to the public internet?

When you get the 403 are you connecting using your local network or the public internet?

curl -I https://data.nischan.com/index.php
HTTP/2 500
x-powered-by: ASP.NET
cf-cache-status: DYNAMIC
server: cloudflare
2 Likes

Ah, sorry, I didn't mention that I turned the proxy back on after I saw it had no effect on the problem. I figured if it didn't fix it, no sense leaving it hang out there. I've reverted it back to passthrough now though.

OK, now I'm really confused. I figured I may as well go ahead and get all my sites staged awhile. So I made another site, ql.nischan.com. Same problem. Then I made manga.nischan.com - and it freaking works. I did the exact same process but this one is fine.

(banging head against wall) lol

I went and tried data.nischan.com again, thinking maybe it magically started to work, but no, it's still the same thing.

DNS is setup the same on them all, well, aside from data being passthrough ATM:


web.nischan.com is an A record with the static IP of the web server.

No, it isn't. It looks proxied as well.

web.nischan.com.	0	IN	A	172.67.141.159
web.nischan.com.	0	IN	A	104.21.94.240
web.nischan.com.	0	IN	AAAA	2606:4700:3031::ac43:8d9f
web.nischan.com.	0	IN	AAAA	2606:4700:3033::6815:5ef0

Your problems are not related to Let's Encrypt certs. This looks like some Cloudflare confusion with some issues with your origin server configuration. You'd probably be better off at the Cloudflare Community forum or an IIS forum.

2 Likes

facepalm D'oh. For some reason I had just assumed that was direct, as I had all my web assets point to it in case I need to move servers it'd make it easy. I guess that made my test earlier pointless, heh. I switched it back to non-proxy. Didn't seem to make a difference though.

Should that domain be working with HTTPS? Because it is not.
https://www.ssllabs.com/ssltest/analyze.html?d=web.nischan.com&hideResults=on

I have lost the plot of this story. Hopefully a different volunteer will help sort you out or you could try the other forums I mentioned.

2 Likes

lol yea, it's a confusing one, I'm not surprised it lost you.

I don't think the Cloudflare setup has anything to do with it; some sites work fine and they are configured exactly the same. I've decided to start fresh, so I'm uninstalling IIS and everything and rebooting then going to try again. Maybe I just messed up some step in the process before.

Well, enabling Cloudflare proxy is considerably different than not doing that.

When proxied that enables their CDN. There is an HTTP(s) connection between the user-agent (like a browser) and the CDN. There is a second connection between the CDN and your origin server.

If both connections use HTTPS then there are two certs. One that Cloudflare gets on your behalf for use by its CDN. The other you get on your origin for CF to your origin. Cloudflare even has an Origin CA cert which is a self-signed cert for use only for this connection. This avoids the need for getting a public CA cert on your origin. With their Origin CA cert you can't then do HTTPS directly to your origin (and you may never need to) and not all ports are supported. But, often times it is a good option.

This forum isn't the best for general server and DNS configuration even though many of us could advise on that. And we sometimes do :slight_smile:

2 Likes

Thanks. Well, what I mean is it was weird to me that several sites worked yet others just didn't want to even though all were proxied. You're right, this got a bit afield from being a LE problem. I actually got it solved; a network engineer friend had dropped by and wiped out my local zone and rebuilt it and now everything works fine. Something had gotten borked on the local zone. (sigh)

Thanks again for the help!

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.