Can’t get origin server cert to work with Win2016+IIS 10
What steps have you taken to resolve the issue?
Obfuscating hostname, IPs, etc for security
Using Windows Server 2016+IIS. Created a CF origin server SSL cert for example.contoso.org. Imported that cert into Personal and verified it shows/looks right. Imported CF Origin Root (both ECC and ESA to be safe) and verified they both show in Intermediate Certification Authorities. Restarted entire server, bound the new origin cert to IIS (tried with no hostname and hostname and also with/without SNI). Restarted again to be safe. Verified I can load INTERNALIP on https from the web server, of course with the expected invalid cert warnings. Same with EXTERNALPUBLICIP on https from random public machine, again with expected cert warnings. However, when I set CF SSL to Full or Strict, get error 520. With CF SSL to Flexible, loads fine.
I’ve got a Config Rule for this specific site so I’ve turn off security level, browser check, etc.
Hello, for reference, for testing, I have 80/http and 443/https allowed to the origin server currently. When I have the config rule set to flexible, I can hit the CF FQDN (ie, proxy through CF) – SSL from client to CF, no SSL CF to origin. If I change the config rule to full or strict, I get the error mentioned after maybe 10 seconds. However, if I browse to the direct public IP on https (can’t give a redacted URL example due to community limits), I get served the page (with the expected SSL cert warnings since I’m using the CF origin on the webserver and not a public cert). In other words, the web server will serve HTTPS directly via its public IP, but for reasons I can’t see, something does NOT work with HTTPS when CF is the “client”.
A bit more info – with the CR set to flexible, the site loads via FQDN via CF proxy and I get the expected IIS log file entries for hits in (ie, on server port 80). With CR on full, FQDN gives the CF 520 error and I don’t get any IIS log file entry. If I hit the origin web server’s public IP on https, I get the expected IIS log file entries (on port 443).
I remember a year ago, I’ve had some issues at first sight with 2012 R2 where ciphers weren’t compatible, therefore I have had to go with RSA origin cert + Authenticated Origin Pulls RSA/Root CA RSA as well.
Never the less, have had to bind both 80 and 443 the public IP.
Check firewall rules.
Have had the redirection from HTTP to HTTPS as well on IIS.
At the end, after trying everything, I end-up paying for an SSL certificate.
Putting that one, and it worked like a charm with Full (Strict) SSL.
However, I cannot remember at the moment, but later again I replaced the paid SSL from Namecheap, tried with new generated Origin CA from the CF dashboard, and it worked - was some I missed in between.
Can update in few days after I check again for feedback, if interested and hopefully would help you as well.
Thanks fritex, I am running Windows Server 2016 (IIS 10). I did the CSR from IIS using 2048-bit key etc. And again, if I go directly to the server’s public IP on 443/https, it servers up the page securely. Of course, since the origin web server is not using a publicly trusted cert chain, I get that warning, but the page loads and it’s encrypted. FWIW, I also have had no problems in this same scenario using a regular publicly trusted cert on the origin server, even from one of the cheap providers. But a huge advantage to CF is not having to do new public certs every year, and the hassle and cost that comes along with it. But I don’t really want to run Flexible mode where the traffic between CF and my origin web server is clear text http.
@someguyUSA Hope below helps in your case. Worked for me 1-2 hours ago and still working.
I am sharing what I’ve checked, tested and done in past hour-two.
Since my Namecheap Sectigo is expiring on Sept 22 this year (1 month), I’ve gone again through this and done it as follows to achieve it working (at least in my case).
You can download my converted and used Cloudflare Origin CA Root (RSA) and Authenticated Origin Pull (RSA) as .p7b from link below (step 22-23):
Went back to the “Certificates” → Trusted Root Certification Authorities
Right Click → All Tasks → Import and imported each one by one here with double-checking to place them into the “Trusted Root Certification Authorities” certificate store
Went to IIS, selected my Website sub.domain.hr
Went to SSL Settings → Require SSL (not checked), Client Certificates is “Ignore”
Right sidebar → Bindings
Having http sub.domain.hr port 80 and public IP
Added https sub.domain.hr port 443 and public IP
Selected https and clicked “Edit”
Type https, IP is IPv4, port is 443, host name is sub.domain.hr, “Require Server Name Indication” is checked and SSL certificate selected the one which I’ve added (only)
Saved
I got warning message “No default SSL site has been created. To support browser withoutn SNI capabilities …”
Made sure Full (Strict) SSL is selected under the SSL/TLS tab of Cloudflare dashboard for the whole zone (no additional Rules configured to separate the sub-domain, except no cache)
Made Sure Authenticate Origin Pulls is enabled
Stopped and started (restart) Web server
Checking HTTP and HTTPS via Chrome on Windows server gives HTTP 404 not found error, however loads fine without any issue and on the “lock icon” I can see Cloudflare Origin Certificate, Origin CA, expiring 2039. (15 years)
Checking via hostname from my home network and mobile phone sub.domain.hr/some-path/phpinfo.php, it’s loading fine and working over HTTPS; no warning, no issue
When I go check the SSL lock icon, since it’s proxied , it’s showing Let’s Encrypt Cloudflare certificate
Nothing changed in the Apache config file for SSL.
What I can offer is, voluntarily I could help you with this on demand, however remotely only or via AnyDesk or something if it’s easier for you also to see.
Thank you so much for the detailed instructions. That is pretty much exactly what I was already trying, except on Win2016/IIS10, I had been just directly importing the .PEM files for the chain/trust. Just to be sure, I deleted those certs and went back through the entire process again exactly following your instructions. The only extra/deviations are in the IIS bindings for 443/SSL. I had to specify the hostname (required to enable SNI) and my web server is behind a NAT firewall, so in binding address I put in the private (not internet routable) IP instead of the public IP (as specified in your instructions).
With SNI+hostname, on the local webserver at https://privateIP, I get this site can’t be reached (connection reset). If I disable SNI and remove the hostname, I get the (expected) warning about the cert mismatch (ie, cert is for xxxx.domain.com while I’m currently browsing privateIP). But if I then configure CF proxy with strict or full, I get the dreaded 520 error. When I check the web server’s IIS logs, there are no hits from that attempt.
I have got a setup something also similar, had to do NATting (for some things as well from local network to get to the outside part earlier with RaspberryPi), however:
Mikrotik router (with a public static IP /29 for Internet + have another /28 IP public static space for the services → single physical port connected)
FortiGate router as firewall (has got the 2nd public static IP from Mikrotik /29, inner local network separated by the VLANs, connection to the main server with one of the 2nd /28 IP space, etc. → separate physical ports connected)
Dell Server (multiple ports used for local network and VLANs + public IP via port connection to the switch in between before FG router) - Windows Server with Hyper-V virtual machines (one of them is that old WS 2012 R2 with that and the needed VMs are assigned with available routing IPs from the 2nd /28 IP space)
In short: Mikrotik → Fortigate → Server → Virtual machine
However, yep, since I got the routable public IP space available so just assign them and make sure over the Fortigate port it’s added/forwarded further
Hm, that’s quite strange. Sounds like something is blocking somewhere?
Could you check the firewall/router logs, if any incomming?
One thing which I haven’t noted is, what I also have added are the Cloudflare IPs under the IIS server (main settings) and also under the particular site sub.domain.hr as well (same on both), as follows:
Eventually I will want to block all non-CF IPs on the PAT/NAT to the web server, but for troubleshooting (and to simplify and reduce potential problems) I am allowing all IPs incoming.
On the same web server, I stopped the original site, created a second IIS site with just the default simple IIS HTML, bound 443 using the same IP and same cert and it works fine on strict, showing the expected CF cert info on a client and the expected IIS logs on 443. What the heck?
This is getting weirder by the minute. Back to the original site. If I reset the IIS site, it will load the site on strict for the first external client. Any further separate external client gets the CF 520 error and then even the first client starts getting 520s. If I reset IIS again, client 1 and 2 can both refresh browsers and continue on until a client 3 tried to come in.
This behavior does NOT happen if I have CF set on flexible!
Ok, more testing done and amending some of my previous information, and I THINK, maybe a solution.
First, I did check the firewall logs and verified it is not in play for this problem. It is always passing SSL traffic incoming from CF to the web server in question.
The weirdness with IIS resets and multiple clients, plus some lack of hits to IIS logs got me thinking about cache issues. So I added a cache rule in CF to bypass the site/URL in question from all caching. So far, and with SSL on strict, I have not been able to break things despite actively trying to.
I missed in between.
, it’s showing Let’s Encrypt Cloudflare certificate
