Let’s add some information and question, so that I can more easily - with your support - idea tidy the problem.
Additional info:
In the caddy config file I am creating around 15 subdomains (sub.domain.com, sub2.domain.com, etc.). → would be this the reason for the problem?
One subdomain already has one purchased certificate (which however I did not specified in the config). → shall I modify the config file to point to the actual valid certificate? How?
Caddy (when I only use HTTP and use 443 to access directly QTS) currently uses port 8964 (HTTPS) and 8963 (HTTP). When trying to use HTTP, beside trying to free up port 443, I simply changed the router port forwarding of 443 and 80 to the two mentioned ports. → is that the correct way to do?
→ shall I understand from the error that the config is correct in terms of port forwarding/settings?
I do not remember how to check, verify and/or change the two ports used by Caddy (8964 and 8963). → How can I see it?
Beside waiting for a week to test again, is there a flag I can use to at least test that the config file is correct and that next week, once discovered what I am not doing well, the certificates can be issued?
There’s multiple ways to go about it. This method should work, but forwarding 80/443 straight to 80/443 on the Caddy host is the simplest method. The error implies that something isn’t working, and doing port detouring might be the cause.
Those are not the default ports Caddy uses, so you must have changed them. If you didn’t do it in your Caddyfile, you probably did it by flag.
Remember, too, that Caddy outputs what sites it is serving, and on what scheme/port, when it starts up. You can double check that output to know for sure what Caddy’s listening on locally.
We recommend, when testing, troubleshooting, and configuring new or problematic HTTPS setups, that you use the LetsEncrypt ACME staging environment. They have relaxed rate limits there, and a rate limit on the production environment won’t stop you from testing on the staging environment. Use the -ca flag when running Caddy to specify which ACME endpoint to use.
So, I tried again. I have completely shut down Qhttpd which was taking port 80 and ensured that ports 80 and 443 were free and forwarded by the router to the Nas.
Not sure. Is the subdomain pointed at the correct IP address in DNS?
There might be more info in the (redacted) AuthURLs, and I can’t do any diagnostics (because I assume you don’t own domain.com and don’t know your real domain).
What I can see is that you got rate limited again at the end there. Did you swap to the staging server while testing?
Why Caddy, even if there are many other other reverse proxies in the config file, if it finds an error (like the above) in one, it stops and does not try to also make the other working? It could could be useful also to try different set-up in one run.
Is the config and port settings correct in the configuration above or I am still misconfiguring something? Is it useful or is it a mistake to use the variable “-port 20015” to launch Caddy (see post above)? Does it make any difference for caddy to listen ports 80 and 443?
This is a conscious decision the developers made when designing Caddy’s core behaviour. When the user configures the server to grab certs for two different sites, but it can only grab one, the question must be raised:
Do we start up with behaviour that is, strictly speaking, not what the user asked for? (i.e. proceed serving one site)
Or, do we tell the user that we’re not able to do what they’ve configured us to do? (i.e. fail out, produce an error for the user to troubleshoot and fix)
The decision was made to have the server strictly only do what the user asks, and be loud and obvious with problems. It’s all too common for simple log entries to be ignored, or worse, never logged at all (we see this constantly). During initial startup and configuration is the best time to ensure a user is aware that the server cannot support the configuration they’ve asked for. This decision was supported by the fact that it is possible, if absolutely necessary, for the user to manually configure Caddy such as to provide a best-effort attempt to serve the sites (for example, via On-Demand TLS).
But, ultimately, if you say “Serve these two sites with managed HTTPS!”, and Caddy can’t serve those two sites with managed HTTPS, it’s going to tell you as much.
The configuration looks serviceable. -port only governs which port Caddy will try to use for non-HTTPS-managed sites, so for all the valid sites with Automatic HTTPS, this flag is irrelevant. (To change the main ports, you’d need -http-port and -https-port.)
You might consider the -email flag (e.g. -email sub@domain.com) to set the default email address instead of specifying it in all the individual sites.
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.
I can send you the unredacted in private (if it is possible).