Remove all port-related flags. You don’t need to change the default -port (its default is :2015, but I don’t even think you’ve got any sites unmanaged). You don’t need to set the -http-port to 80, because that’s its default too, as is -https-port defaulted to 443.
Ok, I tried again (using above settings) and all certificates are created correctly: “server responded with a certificate”.
At the end of the process, have around 15 reverse proxies, I have the following output:
Serving HTTPS on port 20015
https://sub.domain.com:20015
https://test.domain.com:20015
Serving HTTP on port 80
http://sub.domain.com
http://test.domain.com
I can confirm that ports 80 and 443 are correctly forwarded to the NAS. Moreover I can see that Caddy has taken port 80, but not port 443 (which not used).
EDIT: It seems it is solved now taking out -port 20015 from the launching instruction, but I still have one problem for the (sole) domain for which I have a purchased certificate:
Ok, so if my understanding is correct, I have to “split” the instruction to ensure it works. I will test it!
By the way, and I am continuing here as it relates to Caddy and QNAP, I have discovered that using HTTPS will create a problem for many QNAP applications used such as Notification Center, Help desk, Malware Remover, Photo Station, Download Station, etc… which are actually standalone applications developed by QNAP but linked to QTS through a proxy (for which the url is for example user.myqnapcloud.com/…).
For those I receive the error “connection refused”.
Should I specify something in the config file of Caddy to tell that it should also take into consideration all other applications?
Which port are you trying to connect to them on? (i.e. is there a port in the browser URL? Is there a port in the reverse proxy config in the Caddyfile?)
No, basically I connect, via https (443) to port 8080 of my QNAP where I can access to QTS (the NAS interface, eg test.myqnapcloud.com). From there you can open different applications, most of them within the same window, which are basically separate applications which are proxied and embedded to QTS, just with a different path (e.g. test.myqnapcloud.com/malware_remover/).
I am sorry that I cannot be more specific. What I know is that with Caddy in http I had not this error.
No, you’ll need to check your browser’s dev console.
Open it up and go to the Network tab, then reload the problem page. You can then inspect each request to determine what URL was used for the request, what port, etc. and what the response was.
As I have at least 2 subdomain which will require so, can I put it in the specific part of the conf fail or should it be on the general section linked to addheader?
X-Frame-Options doesn’t allow for multiple subdomains to be set; the options are deny, sameorigin, and allow-from [uri].
You can use Content-Security-Policy: frame-ancestors [option...] instead, which can specify multiple origins the frame can be loaded to - Content-Security-Policy obsoletes X-Frame-Options.
Which, in the examples I gives above, I think it is the case, right (honest question)?
Indeed I basically only use reverse proxies to access to my QNAP and it’s various parallel services (Couch Potato, Sonarr, Transmission, etc…) which I don’t think would have such problem.
If I had to wager, I’d say yes. It looks like it’s loading them out of subdirectories: https://test.domain.com/apps/qdesk, https://test.domain.com/apps/netmgr, https://test.domain.com/malware_remover, etc., so sameorigin might just be what you need.