Hello. Welcome to Caddy.
matrixebiz.cc seems to be currently operating. Did it stop when you started Caddy?
Otherwise, Let’s Encrypt will refer to the current server, which will fail to issue a certificate.
Also, Is there a Caddyfile there?
Hello, thanks for responding, no it doesn’t stop it just keeps repeating the message;
[matrixebiz.cc] [matrixebiz.cc] acme: error presenting token: presenting with standard provider server: could not start HTTPS server for challenge -> listen tcp :443: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted. (attempt 1/2; challenge=tls-alpn-01)
2020/01/21 20:42:29 [INFO] [matrixebiz.cc] acme: Obtaining bundled SAN certificate
2020/01/21 20:42:29 [INFO] [matrixebiz.cc] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2408526145
2020/01/21 20:42:29 [INFO] [matrixebiz.cc] acme: use tls-alpn-01 solver
2020/01/21 20:42:29 [INFO] [matrixebiz.cc] acme: Trying to solve TLS-ALPN-01
2020/01/21 20:42:30 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2408526145
2020/01/21 20:42:31 [ERROR][matrixebiz.cc] failed to obtain certificate: acme: Error -> One or more domains had a problem:
[matrixebiz.cc] [matrixebiz.cc] acme: error presenting token: presenting with standard provider server: could not start HTTPS server for challenge -> listen tcp :443: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted. (attempt 2/2; challenge=tls-alpn-01)
Should I specifically open ports 80 and 443 for Caddy?
Thanks@matrixebiz You’ll need to make sure that ports 80 and 443 are not used by any other process so that Caddy can bind to them to obtain certificates for your sites.
Hello, I made sure nginx was not running to free the ports but I think the ports only get opened by Windows firewall when nginx is running due to a rule in my firewall settings so I’ll have to check Windows firewall and add an exception for Caddy as well but is my command line syntax correct to run a high traffic streaming server?
caddy.exe file-server --domain matrixebiz.cc --path c:\www
or are there some other tweeks I can do to the command or have a config file for it to load? It looks like the documentation is written for a Linux box so won’t work in Windows, especially with the --path switch to where my index.html file is etc… Python I would need to do like C:\www but with Caddy does it want the windows path like c:\www ? Thx
@matrixebiz I have a hunch or hint as to what may be going on, but I’m not sure yet. Still investigating…
Does this error ("could not start HTTPS server for challenge -> listen tcp :443: bind: Only one usage of each socket address") happen consistently every time you run the command? And does it repeat every few seconds? Please paste the full output, especially over about 10 seconds or more.
That should work fine on Windows, but I’m not sure. Maybe you need a capital C.
The command line interface should be the same for Windows.
I think it is safe to include this option in the Caddyfile.
If you have Caddyfile in the same location as caddy.exe, no options are required.
When I looked at matrixebiz.cc, there was a nginx sign.
First, stop nginx and start Caddy.
Let’s Encrypt does domain authentication for certificates. Caddy automates that task.
If nginx is running, Let’s Encrypt will look for nginx and it will fail.
before going through more troubleshooting, will this Web server be able to handle thousands of streaming requests at a time? Why I’m wanting to change to something other than Nginx is because when Nginx and Apache are getting hammered, it seems to stop serving requests for a bit.
EDIT: okay I just tried b13 on a regular Windows 10 machine using a caddy file;
localhost
root * /www/
file_server
and in my Browser localhost:2015 was able to load my index.html located at C:\www
So that means my syntax is correct and should work if I change localhost to matrixebiz.cc
but can someone check and see why beta13 is not working on Windows Server 2016 (Get an error in a Window about the App cannot run … then exits and see Access denied) and when I do caddy start and stop with beta12 I get this;
C:\Caddy>caddy stop
2020/01/23 18:27:41.481 e[33mWARNe[0m failed using API to stop instance {“endpoint”: “http://localhost:2019/stop”, “error”: “performing request: Post http://localhost:2019/stop: dial tcp [::1]:2019: connectex: No connection could be made because the target machine actively refused it.”}
stop: performing request: Post http://localhost:2019/stop: dial tcp [::1]:2019: connectex: No connection could be made because the target machine actively refused it.
So I have to kill the task
I can do ‘caddy run’ then ctrl+c to close the server down but if I do ‘caddy start’ then the ‘caddy stop’ fails.
I’m sure it is capable of that. If not, we’ll find a way to tune it. But we stick pretty close to the Go standard library which shuttles a fair portion of all Internet traffic.
Unfortunately I’m not familiar enough with Windows or Windows Server to know what in the system is misconfigured here 
Hopefully someone else with more expertise can step in.
We usually recommend using caddy run in production for this reason (fewer system calls, thus less that can go wrong), but ultimately it’s probably a permissions or some sort of system misconfiguration.
Hi Matt, okay everything looks to be setup correctly now but this is what I get now;
(Ports 80 and 443 were open);
Something else I need to add to my config?
C:\Caddy>caddy run
2020/01/23 23:40:06.149 e[34mINFOe[0m using adjacent Caddyfile
2020/01/23 23:40:06.158 e[34mINFOe[0m admin admin endpoint started {“address”: “localhost:2019”, “enforce_origin”: false, “origins”: [“localhost:2019”]}
2020/01/23 23:40:06.159 e[34mINFOe[0m http server is only listening on the HTTPS port but has no TLS connection policies; adding one to enable TLS {“server_name”: “srv0”, “https_port”: 443}
2020/01/23 23:40:06.159 e[34mINFOe[0m http enabling automatic TLS certificate management {“domains”: [“matrixebiz.cc”]}
2020/01/23 23:40:06.159 e[34mINFOe[0m http enabling automatic HTTP->HTTPS redirects {“domains”: [“matrixebiz.cc”]}
2020/01/23 18:40:06 [INFO][cache:0xc000393c70] Started certificate maintenance routine
2020/01/23 23:40:06.163 e[34mINFOe[0m tls cleaned up storage units
2020/01/23 23:40:06.174 e[34mINFOe[0m autosaved config {“file”: “C:\Users\Administrator\AppData\Roaming\Caddy\autosave.json”}
2020/01/23 23:40:06.174 e[34mINFOe[0m serving initial configuration
2020/01/23 18:40:07 http: TLS handshake error from 24.104.160.117:54287: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 24.104.160.117:54289: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 96.22.166.250:33818: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 142.116.146.86:45529: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 96.22.166.250:33820: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 142.116.146.86:45531: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 24.104.160.117:54291: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 96.22.166.250:33822: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 96.22.166.250:33824: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 24.104.160.117:54293: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 142.116.146.86:45533: tls: no cipher suite supported by both client and server
2020/01/23 18:40:07 http: TLS handshake error from 96.22.166.250:33826: tls: no cipher suite supported by both client and server
2020/01/23 18:40:08 http: TLS handshake error from 142.116.146.86:45535: tls: no cipher suite supported by both client and server
2020/01/23 18:40:08 http: TLS handshake error from 96.22.166.250:33828: tls: no cipher suite supported by both client and server
2020/01/23 18:40:08 http: TLS handshake error from 24.104.160.117:54295: tls: no cipher suite supported by both client and server
Those just look like clients that are using old/incompatible TLS settings.
I tried to connect to the website with firefox but it wasn’t connecting either.
Would those be clients trying to connect with http ?
Should I change my caddyfile to;
matrixebiz.cc:80 {
root * /www/
file_server
}
matrixebiz.cc:443 {
root * /www/
file_server
}
Okay, it looks like it is working now using the above;
Will the https cert auto renew by looking at the info in my screenshot?
You can make it shorter with just:
matrixebiz.cc {
root * /www/
file_server
}
Yeah, I tried that originally but then I couldn’t resolve http or https, not sure why, so I just separated them and I was able to then access my website
When I have my caddyfile with just the single domain name I get constant scrolling of the bellow;
So I put in both ports specifically like above and that doesn’t happen as much.
That’s odd. Is that phenomenon consistently reproducible? Or is it just a coincidence?
Because those errors just mean that a bunch of clients are spamming your server with old/obsolete TLS handshakes.
Hello, yes, reproducible.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.