5 ms·

Or use Caddy https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https

by ssijak 8y ago

graup 8y ago
Looks cool, but it's not free for commercial use. Instead of paying $25/instance/mo I can set it up myself with the https-portal docker config.
- mortond 8y ago
  Or just build Caddy from source?
- cabraca 8y ago
  their github source is still apache 2.0 licensed. just compile it yourself and you're good to go.
- bpizzi 8y ago
  It's not free if you use the binaries builded/downloaded from caddyserver.com. It's still free if you build the binaries yourself from source [0]. [0] https://caddyserver.com/products/licenses https://caddyserver.com/products/licenses
  - andmarios 8y ago
    Binaries from github should also be free, though they do not have external plugins compiled in.
  - edwinyzh 8y ago
    Great! I didn't know about that.
  - morpheuskafka 8y ago
    And there is a Docker Hub image freely licensed building from source: https://github.com/abiosoft/caddy-docker https://github.com/abiosoft/caddy-docker
- mpranjic 8y ago
  Caddy is free. Caddy binaries are not free, which is different. You're free to build it yourselves (or use a prebuilt docker image).
stephenr 8y ago
Sure, if you want to play "guess which crazy decision the author makes will bite users in the ass next". The project has a very poor history of bad decisions.
- y4mi 8y ago
  i know of one example, which was admittedly beyond silly (caddy wouldn't start when lets encrypt had an outage), and they back paddled very quickly after it blew up, and provided a fix within hours iirc. your comment however paints a different picture... if you know other examples, please enlighten us.
  - stephenr 8y ago
    The issue you're aware of is when I became aware of the project (because of the outages and ensuing coverage here on HN). My issues are: - that problem was caused not by a 'bug' but by a deliberate decision that the author made, and defended. I wouldn't use the term 'back peddled' so much though: Even after relenting and changing the allowed expiry window, the behaviour was essentially the same, albeit with a smaller failure window. AFAIK Caddy to this day won't start with a valid certificate if it can't renew it, if the expiry is within 7 days. - before the TLS-SNI-01 challenge was disabled on the LE side, Caddy's behaviour was to randomly select a challenge to use. When I questioned the author about this his response was "oh well that would be too much load for LE". The problem there is that the ACME protocol handles this exact scenario - you query the ACME server to find out which of the challenges you want to use, it will allow you to continue with. As I pointed out at the time, I personally wasn't aware of this before the TLS-SNI issue, but as demonstrated by his response, neither was he. If his project's entire reason for being is registering certs via ACME, wouldn't you expect him to know the basic information/control flow when requesting a cert? - the author has no apparent concept or understanding of 'separation of concerns' - apparently anything that isn't a single file go binary is all too much for the world to bare, regardless of the disastrous results his approach has given the world. I'm all for competing approaches to solving a problem, but when someone essentially ignores any competing approach that doesn't fit their existing narrative of "I have the sole solution to this problem", it's not a sign of someone who is really interested in solving the problem, it's someone interested in pushing their solution. That's fine for a salesman, I guess. Not so much for an 'engineer'. Edit: - the 'ads via headers' stunt was just plain weird and creepy, and shows that the author and his partners have no real sense for business. This is demonstrated in their 'Basic' paid support, which states: "We usually respond within 1-2 business days.". USUALLY!? You're paying $25 a month per instance, so you.. I dunno, don't have to install certbot once, and your support response timeframe includes the term "usually". Sweet fucking Jesus.

Or use Caddy https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https

by ssijak 8y ago

Or use Caddy https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https

Looks cool, but it's not free for commercial use. Instead of paying $25/instance/mo I can set it up myself with the https-portal docker config.

mortond 8y ago
Or just build Caddy from source?
cabraca 8y ago
their github source is still apache 2.0 licensed. just compile it yourself and you're good to go.
bpizzi 8y ago
It's not free if you use the binaries builded/downloaded from caddyserver.com. It's still free if you build the binaries yourself from source [0]. [0] https://caddyserver.com/products/licenses https://caddyserver.com/products/licenses
- andmarios 8y ago
  Binaries from github should also be free, though they do not have external plugins compiled in.
- edwinyzh 8y ago
  Great! I didn't know about that.
- morpheuskafka 8y ago
  And there is a Docker Hub image freely licensed building from source: https://github.com/abiosoft/caddy-docker https://github.com/abiosoft/caddy-docker
mpranjic 8y ago
Caddy is free. Caddy binaries are not free, which is different. You're free to build it yourselves (or use a prebuilt docker image).

stephenr 8y ago

Sure, if you want to play "guess which crazy decision the author makes will bite users in the ass next". The project has a very poor history of bad decisions.

y4mi 8y ago
i know of one example, which was admittedly beyond silly (caddy wouldn't start when lets encrypt had an outage), and they back paddled very quickly after it blew up, and provided a fix within hours iirc. your comment however paints a different picture... if you know other examples, please enlighten us.
- stephenr 8y ago
  The issue you're aware of is when I became aware of the project (because of the outages and ensuing coverage here on HN). My issues are: - that problem was caused not by a 'bug' but by a deliberate decision that the author made, and defended. I wouldn't use the term 'back peddled' so much though: Even after relenting and changing the allowed expiry window, the behaviour was essentially the same, albeit with a smaller failure window. AFAIK Caddy to this day won't start with a valid certificate if it can't renew it, if the expiry is within 7 days. - before the TLS-SNI-01 challenge was disabled on the LE side, Caddy's behaviour was to randomly select a challenge to use. When I questioned the author about this his response was "oh well that would be too much load for LE". The problem there is that the ACME protocol handles this exact scenario - you query the ACME server to find out which of the challenges you want to use, it will allow you to continue with. As I pointed out at the time, I personally wasn't aware of this before the TLS-SNI issue, but as demonstrated by his response, neither was he. If his project's entire reason for being is registering certs via ACME, wouldn't you expect him to know the basic information/control flow when requesting a cert? - the author has no apparent concept or understanding of 'separation of concerns' - apparently anything that isn't a single file go binary is all too much for the world to bare, regardless of the disastrous results his approach has given the world. I'm all for competing approaches to solving a problem, but when someone essentially ignores any competing approach that doesn't fit their existing narrative of "I have the sole solution to this problem", it's not a sign of someone who is really interested in solving the problem, it's someone interested in pushing their solution. That's fine for a salesman, I guess. Not so much for an 'engineer'. Edit: - the 'ads via headers' stunt was just plain weird and creepy, and shows that the author and his partners have no real sense for business. This is demonstrated in their 'Basic' paid support, which states: "We usually respond within 1-2 business days.". USUALLY!? You're paying $25 a month per instance, so you.. I dunno, don't have to install certbot once, and your support response timeframe includes the term "usually". Sweet fucking Jesus.