7 ms·

Just wanted to jump on this for Caddy users [1]: > Until further notice, when starting Caddy, we recommend using the '-disable-tls-sni-challenge' flag. This wi

by mholt 9y ago

Just wanted to jump on this for Caddy users [1]: > Until further notice, when starting Caddy, we recommend using the '-disable-tls-sni-challenge' flag. This will require either HTTP or DNS challenges to be functional in order to renew your certificates. By default, Caddy randomly chooses either the HTTP or TLS-SNI challenge to obtain and renew certificates. Your sites will likely not go offline even if you do not use this flag because Caddy tries up to 2 times per day, 30 days out, to renew an expiring certificate, as long as you keep it running. The chances that it would choose TLS-SNI sixty times in a row is extremely low. (We -- meaning myself and many people who contributed their feedback and code -- thought about these kinds of scenarios and Caddy is prepared to handle them.) However, since the TLS-SNI challenge will fail 100% of the time while it is disabled on the server end, might as well have the client not even try it. Also note that all certificate maintenance routines are logged to the process log, so be sure you always run Caddy with the '-log' flag in production so you can see what's going on. Since this outage may be temporary, check back later about re-enabling it. I recommend having more than one way to perform verifications when possible. (For Go programmers, the xenolf/lego library [2] supports all verification methods -- and is being upgraded for ACMEv2 currently; Sebastian is doing an awesome job! It also supports numerous DNS providers for easy setup of the DNS challenge.) One more thing: wait for a full report from Let's Encrypt rather than speculating. Most questions can't be answered until there's more information. I don't think there's anything you need to do, no alarms to raise... just use another verification method until we get more info. [1]: https://twitter.com/caddyserver/status/950926718004428800 https://twitter.com/caddyserver/status/950926718004428800 [2]: https://github.com/xenolf/lego https://github.com/xenolf/lego

orastor 9y ago
nice one caddymeister
stephenr 9y ago
> randomly What? How does that make any sense? Why wouldnt you just try all undetstood (and not manually disabled) challenges until you get a successful result? This isnt like picking an ephemeral port number.
- codemac 9y ago
  So an attack against one challenge doesn't deterministically succeed.
  - stephenr 9y ago
    The much greater likely scenario is an error in comms/le (such as this issues today) means Caddy will un-deterministically fail
    - codemac 9y ago
      That is a trade-off for false negatives rather than false positives. It is not an unreasonable choice when dealing with certificates.
      - stephenr 9y ago
        The default client recommended by LE (certbot) supports multi-challenge registration/renewal. I'm pretty sure I trust their judgement over that of the Caddy project, given their (Caddy) history of weird decisions that backfire and cause user issues.
- mholt 9y ago
  In addition to what was already mentioned, it's also to be polite. Imagine if Caddy and other clients already did what you suggest: Let's Encrypt would suddenly be receiving ~50% more traffic during an already-stressful time. When we were first integrating ACME into Caddy, traffic spikes like this were a problem (for other reasons, long since fixed), which we now are very sensitive to avoid.
  - stephenr 9y ago
    The default recommended client does support multi challenge, and from what the logs show, the ACME protocol even handles this without extra load - it returns the challenge modes it will accept. I wasnt aware of this and you arent either apprently. The difference is, I'm not shipping a commercial web server package whose key feature is LetsEncrypt (and thus ACME) support.
benatkin 9y ago
Cool. Now's a good time to remind everyone that Caddy became popular as a fully open source web server and now charges for commercial use of its binary. https://caddyserver.com/products/licenses https://caddyserver.com/products/licenses However, there's little technically in place to prevent people from using the free version for commercial products. The result of this is that there's probably a bunch of people who downloaded Caddy when it was free for commercial use, who probably just upgraded it, and are now violating the license. A sticky situation. Better to just use nginx or apache (actually apache compares favorably to nginx when it's used properly) until another thing like caddy comes along that's free. Ironically it's quite a similar tax to $10 SSL certificates, only it's a higher upfront cost, of $25. If people were willing to pay $25 for every HTTP server, HTTPS everywhere could have started growing quickly without LetsEncrypt.
- interfixus 9y ago
  Or perhaps now is not a particularly good time to introduce some random personal vendetta-point into a discussion of a wholly unrelated subject.
- bennofs 9y ago
  I don't get this. Is caddy so hard to build from source that you'd pay 10$ for a binary? The source code is ASL licensed so allows commercial use.
  - politelemon 9y ago
    It's probably not very hard, however for an organisation or a team with several members, paying $X can be worth it - they don't have to spend effort on building and maintaining it (allows them to focus on other tasks), just deploy the binaries and contact Caddy when they need some support.
    - kungito 9y ago
      I feel like some misinformation is spread here since what you are really only paying for is building from source. The whole project is open source and you can even use commercially the source. You just have to build it yourself. Does it not make sense that these guys would like to earn some money from this effort? That way they are also more incentivised to continue with the effort. What kind of company finds it too costly to build Caddy themselves AND can't affort paying the license?
kuschku 9y ago
If you use caddy, you'll have other issues to think about anyway. The DNS RFCs (and later the URL RFCs) standardize hostnames to be a set of labels, separated by ".", a relative hostname ending in a label, an absolute hostname ending in a dot. If you are in a corporate system, your DNS resolver will try to append its domain to any relative hostname. So in the domain kuschku.de, if I do ping lithium, it will resolve to lithium.kuschku.de, and use that IP address. This feature is used for example by kubernetes' DNS resolver. This also means that if I enter the domain caddyserver.com, and try to ping it, it will first resolve to caddyserver.com.kuschku.de (or caddyserver.com.svc.default.cluster.local). Now, to avoid these unnecessary lookups, you can simply try to access caddyserver.com. — a valid domain, valid URL, and per RFC it should point at the original, outside of any corporate domain. Except, it doesn't work. Nginx, Apache, IIS, as well as the GCP, Azure and AWS ingress system support absolute URLs. (And all major websites in the Alexa Top 1 million that don't use caddy or traefik also support this. As does news.ycombinator.com.) Caddy does not support serving these (instead mholt recommends you just copy-paste every config rule you have twice), and the bug was closed as WONTFIX.

by mholt 9y ago

orastor 9y ago

nice one caddymeister

stephenr 9y ago

> randomly What? How does that make any sense? Why wouldnt you just try all undetstood (and not manually disabled) challenges until you get a successful result? This isnt like picking an ephemeral port number.

codemac 9y ago
So an attack against one challenge doesn't deterministically succeed.
- stephenr 9y ago
  The much greater likely scenario is an error in comms/le (such as this issues today) means Caddy will un-deterministically fail
  - codemac 9y ago
    That is a trade-off for false negatives rather than false positives. It is not an unreasonable choice when dealing with certificates.
    - stephenr 9y ago
      The default client recommended by LE (certbot) supports multi-challenge registration/renewal. I'm pretty sure I trust their judgement over that of the Caddy project, given their (Caddy) history of weird decisions that backfire and cause user issues.
mholt 9y ago
In addition to what was already mentioned, it's also to be polite. Imagine if Caddy and other clients already did what you suggest: Let's Encrypt would suddenly be receiving ~50% more traffic during an already-stressful time. When we were first integrating ACME into Caddy, traffic spikes like this were a problem (for other reasons, long since fixed), which we now are very sensitive to avoid.
- stephenr 9y ago
  The default recommended client does support multi challenge, and from what the logs show, the ACME protocol even handles this without extra load - it returns the challenge modes it will accept. I wasnt aware of this and you arent either apprently. The difference is, I'm not shipping a commercial web server package whose key feature is LetsEncrypt (and thus ACME) support.

benatkin 9y ago

Cool. Now's a good time to remind everyone that Caddy became popular as a fully open source web server and now charges for commercial use of its binary. https://caddyserver.com/products/licenses https://caddyserver.com/products/licenses However, there's little technically in place to prevent people from using the free version for commercial products. The result of this is that there's probably a bunch of people who downloaded Caddy when it was free for commercial use, who probably just upgraded it, and are now violating the license. A sticky situation. Better to just use nginx or apache (actually apache compares favorably to nginx when it's used properly) until another thing like caddy comes along that's free. Ironically it's quite a similar tax to $10 SSL certificates, only it's a higher upfront cost, of $25. If people were willing to pay $25 for every HTTP server, HTTPS everywhere could have started growing quickly without LetsEncrypt.

interfixus 9y ago
Or perhaps now is not a particularly good time to introduce some random personal vendetta-point into a discussion of a wholly unrelated subject.
bennofs 9y ago
I don't get this. Is caddy so hard to build from source that you'd pay 10$ for a binary? The source code is ASL licensed so allows commercial use.
- politelemon 9y ago
  It's probably not very hard, however for an organisation or a team with several members, paying $X can be worth it - they don't have to spend effort on building and maintaining it (allows them to focus on other tasks), just deploy the binaries and contact Caddy when they need some support.
  - kungito 9y ago
    I feel like some misinformation is spread here since what you are really only paying for is building from source. The whole project is open source and you can even use commercially the source. You just have to build it yourself. Does it not make sense that these guys would like to earn some money from this effort? That way they are also more incentivised to continue with the effort. What kind of company finds it too costly to build Caddy themselves AND can't affort paying the license?

kuschku 9y ago

If you use caddy, you'll have other issues to think about anyway. The DNS RFCs (and later the URL RFCs) standardize hostnames to be a set of labels, separated by ".", a relative hostname ending in a label, an absolute hostname ending in a dot. If you are in a corporate system, your DNS resolver will try to append its domain to any relative hostname. So in the domain kuschku.de, if I do ping lithium, it will resolve to lithium.kuschku.de, and use that IP address. This feature is used for example by kubernetes' DNS resolver. This also means that if I enter the domain caddyserver.com, and try to ping it, it will first resolve to caddyserver.com.kuschku.de (or caddyserver.com.svc.default.cluster.local). Now, to avoid these unnecessary lookups, you can simply try to access caddyserver.com. — a valid domain, valid URL, and per RFC it should point at the original, outside of any corporate domain. Except, it doesn't work. Nginx, Apache, IIS, as well as the GCP, Azure and AWS ingress system support absolute URLs. (And all major websites in the Alexa Top 1 million that don't use caddy or traefik also support this. As does news.ycombinator.com.) Caddy does not support serving these (instead mholt recommends you just copy-paste every config rule you have twice), and the bug was closed as WONTFIX.