My problem is that trying to set a different ca\issuer, of zeroSSL, doesn’t work, meaning letsencrypt is tried first and only if it fails (rate-limit for example) then zeroSSL is used. And also setting the protocols doesn’t affect anything and TLS1.3 is still supported.
What am I doing wrong? I want to to have 2 listeners of the same domain, on HTTP (80) and HTTPS (443). This is my Caddyfile
4. Error messages and/or full log output:
5. What I already tried:
When trying to set the tls setting this way it still doesn’t work
See how the Caddyfile is structured in the docs below, i.e. “directives” are things that go inside site blocks, not interchangeable with global options.
What are you actually trying to do though? Do you actually have something in front of Caddy that uses the PROXY protocol? Why do you need to change protocols to remove TLS 1.3? That seems like a bad idea, TLS versions are negotiated automatically between the client and server. Do you really need to serve content in both HTTP and HTTPS? Why not just redirect HTTP to HTTPS (Caddy’s default behaviour)?
Thanks a lot! And sorry for my late reply.
Your assumption is correct, I did understand this thing wrong because of the links you’ve posted.
Yes I do have a load balancer that uses the PROXY protocol.
I prefer both HTTP and HTTPS due to network-bandwidth-saving reasons.
And actually I’d like to change protocols in order to enable TLS1.0 and TLS1.1, since my website doesn’t contain\transfer sensitive data and the more old protocols and ciphers I support, the more old platform are able to access the website. For instance according to ssllabs server test, currently caddy2 is unable to support the following platforms:
Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 7 / OS X 10.9
Safari 8 / iOS 8.4
Safari 8 / OS X 10.10
Because the handshake fails.
And for wider coverage of old platforms, obviously the more ciphers the better, but don’t forget that their order in Caddyfile matters, so ciphers which are old and http2-blacklisted should be written last, so the server will attempt using them as last resort, on old browsers, and not make new browser reject the handshake.
So if you use (the default) key_type p256
These got me a very wide coverage: ciphers TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA