Neither.
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).
If I type now sub.domain.com on the browser I am now redirected to https://sub.domain.com:20015.
Am I still missing something?
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:
sub.domain.com {
tls /share/Public/SSLcertificate.crt /share/Public/SSLprivatekey.key
import gzipconf
import addheader
proxy / http://192.168.1910:8080 {
keepalive 32
transparent
websocket
}
}
Indeed the output that I have from caddy is the following:
Serving HTTPS on port 2015
https://sub.domain.com:2015
I do not understand why it uses port 2015 even if there is no port set on caddy at launch…
Thanks (I am almost there!)
This is expected behaviour. Automatic HTTPS is what configures the ports, as well as the redirect listener.
Caddy automatically enables HTTPS for all your sites, given that some reasonable criteria are met:
- Certificates and keys are not provided by you
Given that you’ve provided your own certificate, you’ll need to configure this manually.
Like so:
https://sub.example.com {
# [site config here]
}
http://sub.example.com {
redir https://sub.example.com{uri}
}
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?
Thanks again
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.
Uhh, do you mean that you connect to Caddy, which proxies to port 8080?
Could some of these be iframes? When you get a connection refused error, can you tell us which request exactly generates that error?
Yes, I use Caddy to connect to [internal IP]:8080 (and other ports for other services) just having ports 80 and 443 opened on the router.
Re iframes, I do not know. How can I confirm you? Can caddy log tell me this?
Thanks a lot!
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.
Finally I managed to look at it. Here is what I am getting:
VM1557:1 Refused to display ‘Welcome dragndropbuilder.com - BlueHost.com’ in a frame because it set ‘X-Frame-Options’ to ‘deny’.
Refused to display ‘Welcome dragndropbuilder.com - BlueHost.com’ in a frame because it set ‘X-Frame-Options’ to ‘deny’.
Refused to display ‘https://test.domain.com/malware_remover/?windowId=q-app-MalwareRemover-1332&v=3.5.2&date=2019-08-01’ in a frame because it set ‘X-Frame-Options’ to ‘deny’.
Looking at here it seems that I have to change the addheader settings here:
(addheader) {
header / {
Strict-Transport-Security "max-age=31536000;"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
Referrer-Policy "strict-origin-when-cross-origin"
-Server
}
}
Should I simply take out the X-Frame-Options "DENY" settings or should I do something else? Is there any downside to do so?
Thanks!
EDIT: doing so it resolves the issues. But I do not know if there is any downside.
Reading here it seems there is a more elegant and secure way to do, but I would need some support in case. 
You could try setting:
X-Frame-Options "allow-from https://example.com" (replacing example.com with the domain name you use to access the site loading the frames).
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.
Why I could not use sameorigin instead, as the call comes from the same sub-domain?
That would work if, for all individual subdomains you’ll be using, they’ll be loading frames from the same subdomain.
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.
It seems indeed working, thanks!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.