5 ms·

Not _exactly_ as easy, you also need a valid https cert, and set up a cronjob to renew it. And for some other reply here, "as easy as it was in 2003" really do

Not _exactly_ as easy, you also need a valid https cert, and set up a cronjob to renew it. And for some other reply here, "as easy as it was in 2003" really doesn't mean "easy" :v

TheCoelacanth 4y ago
You don't have to have that. Expectations have just increased since 2003.
- cma 4y ago
  iOS won't let websockets work without https so I think you can't do things like self-host jitsi meet. Many appliance type devices won't allow adding self-signed certificates either.
  - the_jesus_villa 4y ago
    To be fair, you couldn't self host jitsi meet in 2003 either
  - TheCoelacanth 4y ago
    Websockets didn't exist in 2003, so that's just a case of higher expectations.
    - cma 4y ago
      Back to plain sites and not websockets, browsers didn't go through a missing https warning process in 2003 either so there are higher barriers and not just expectations.
KronisLV 4y ago
> Not _exactly_ as easy, you also need a valid https cert, and set up a cronjob to renew it. Web servers like Caddy automate this for you: you just indicate that you want HTTPS for a particular site and the rest is taken care of for you (in the case of public sites and HTTP-01 challenges, at least). Link: https://caddyserver.com/docs/quick-starts/https https://caddyserver.com/docs/quick-starts/https Even Apache2 has mod_md which does pretty much the same thing (sans DNS-01 provider integrations, at least out of the box), so it's going to be good enough for most cases and similarly easy to Caddy. Link: https://httpd.apache.org/docs/2.4/mod/mod_md.html#mdomain https://httpd.apache.org/docs/2.4/mod/mod_md.html#mdomain Nginx integrates well with certbot, which does take a bit more work and configuration, but even that is passable: https://certbot.eff.org/ https://certbot.eff.org/ Things can get a bit tricky when you want to run your own CA or ensure mTLS, but in most cases neither will be necessary. As for whether you even need HTTPS in the first place, I'd say that it won't hurt in most cases and will guard against MitM, the ISP included.
- aidenn0 4y ago
  Can't do http challenges because my ISP blocks port 80 inbound.
  - m_sahaf 4y ago
    You configure Caddy to disable certain challenge types[0], which in this is the HTTP challenge, like so: example.com { tls { issuer acme { disable_http_challenge } } file_server } [0] https://caddyserver.com/docs/caddyfile/directives/tls#acme https://caddyserver.com/docs/caddyfile/directives/tls#acme
  - KronisLV 4y ago
    > Can't do http challenges because my ISP blocks port 80 inbound. My ISP also put me behind CGNAT, which effectively meant that all of the inbound traffic got dropped. I worked around that by getting the cheapest VPSes that I could find and then setting up WireGuard and simply forwarding the traffic to my homelab servers. So I got all of the compute that I have available locally, all of the RAM and all of the cheap HDD storage, but a static IP address. I actually wrote about the process a few years ago: https://blog.kronis.dev/tutorials/how-to-publicly-access-your-homelab-behind-nat https://blog.kronis.dev/tutorials/how-to-publicly-access-you... (note that you probably would only want to forward 80 and 443 ports in most cases, not everything; outside of testing boxes) Personally, I opted for Time4VPS in the end, which I use for the rest of my hosting as well: https://www.time4vps.com/linux-vps/?affid=5294#annually https://www.time4vps.com/linux-vps/?affid=5294#annually (affiliate link, they do have good discounts at the moment for yearly billing, though) Then again, something like Scaleway Stardust instances could also be a really good fit, when they are available: https://www.scaleway.com/en/stardust-instances/ https://www.scaleway.com/en/stardust-instances/ For those not chasing after the savings of a few Euros, Hetzner is also going to be more than enough: https://www.hetzner.com/cloud https://www.hetzner.com/cloud (or DigitalOcean, or Vultr, or any other VPS provider out there)
    - aidenn0 4y ago
      I don't need port 80 now that DNS challenges are easily automated. Port 443 is open, so that's fine. Also, if I have a VPS, why not just serve from the VPS?
shanebellone 4y ago
"Not _exactly_ as easy, you also need a valid https cert, and set up a cronjob to renew it. And for some other reply here, "as easy as it was in 2003" really doesn't mean "easy" :v" Took me 15 minutes. https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/install-and-setup/tunnel-guide/local/#set-up-a-tunnel-locally-cli-setup https://developers.cloudflare.com/cloudflare-one/connections...
seized 4y ago
Super easy with the right DNS provider and something like go-acme/Lego. Add a crom job and done. Yeah, not zero effort but compared to early Let's Encrypt with HTTP-01 and such it's quote easy. https://github.com/go-acme/lego https://github.com/go-acme/lego

Not _exactly_ as easy, you also need a valid https cert, and set up a cronjob to renew it. And for some other reply here, "as easy as it was in 2003" really doesn't mean "easy" :v

TheCoelacanth 4y ago

You don't have to have that. Expectations have just increased since 2003.

cma 4y ago
iOS won't let websockets work without https so I think you can't do things like self-host jitsi meet. Many appliance type devices won't allow adding self-signed certificates either.
- the_jesus_villa 4y ago
  To be fair, you couldn't self host jitsi meet in 2003 either
- TheCoelacanth 4y ago
  Websockets didn't exist in 2003, so that's just a case of higher expectations.
  - cma 4y ago
    Back to plain sites and not websockets, browsers didn't go through a missing https warning process in 2003 either so there are higher barriers and not just expectations.

KronisLV 4y ago

> Not _exactly_ as easy, you also need a valid https cert, and set up a cronjob to renew it. Web servers like Caddy automate this for you: you just indicate that you want HTTPS for a particular site and the rest is taken care of for you (in the case of public sites and HTTP-01 challenges, at least). Link: https://caddyserver.com/docs/quick-starts/https https://caddyserver.com/docs/quick-starts/https Even Apache2 has mod_md which does pretty much the same thing (sans DNS-01 provider integrations, at least out of the box), so it's going to be good enough for most cases and similarly easy to Caddy. Link: https://httpd.apache.org/docs/2.4/mod/mod_md.html#mdomain https://httpd.apache.org/docs/2.4/mod/mod_md.html#mdomain Nginx integrates well with certbot, which does take a bit more work and configuration, but even that is passable: https://certbot.eff.org/ https://certbot.eff.org/ Things can get a bit tricky when you want to run your own CA or ensure mTLS, but in most cases neither will be necessary. As for whether you even need HTTPS in the first place, I'd say that it won't hurt in most cases and will guard against MitM, the ISP included.

aidenn0 4y ago
Can't do http challenges because my ISP blocks port 80 inbound.
- m_sahaf 4y ago
  You configure Caddy to disable certain challenge types[0], which in this is the HTTP challenge, like so: example.com { tls { issuer acme { disable_http_challenge } } file_server } [0] https://caddyserver.com/docs/caddyfile/directives/tls#acme https://caddyserver.com/docs/caddyfile/directives/tls#acme
- KronisLV 4y ago
  > Can't do http challenges because my ISP blocks port 80 inbound. My ISP also put me behind CGNAT, which effectively meant that all of the inbound traffic got dropped. I worked around that by getting the cheapest VPSes that I could find and then setting up WireGuard and simply forwarding the traffic to my homelab servers. So I got all of the compute that I have available locally, all of the RAM and all of the cheap HDD storage, but a static IP address. I actually wrote about the process a few years ago: https://blog.kronis.dev/tutorials/how-to-publicly-access-your-homelab-behind-nat https://blog.kronis.dev/tutorials/how-to-publicly-access-you... (note that you probably would only want to forward 80 and 443 ports in most cases, not everything; outside of testing boxes) Personally, I opted for Time4VPS in the end, which I use for the rest of my hosting as well: https://www.time4vps.com/linux-vps/?affid=5294#annually https://www.time4vps.com/linux-vps/?affid=5294#annually (affiliate link, they do have good discounts at the moment for yearly billing, though) Then again, something like Scaleway Stardust instances could also be a really good fit, when they are available: https://www.scaleway.com/en/stardust-instances/ https://www.scaleway.com/en/stardust-instances/ For those not chasing after the savings of a few Euros, Hetzner is also going to be more than enough: https://www.hetzner.com/cloud https://www.hetzner.com/cloud (or DigitalOcean, or Vultr, or any other VPS provider out there)
  - aidenn0 4y ago
    I don't need port 80 now that DNS challenges are easily automated. Port 443 is open, so that's fine. Also, if I have a VPS, why not just serve from the VPS?

shanebellone 4y ago

"Not _exactly_ as easy, you also need a valid https cert, and set up a cronjob to renew it. And for some other reply here, "as easy as it was in 2003" really doesn't mean "easy" :v" Took me 15 minutes. https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/install-and-setup/tunnel-guide/local/#set-up-a-tunnel-locally-cli-setup https://developers.cloudflare.com/cloudflare-one/connections...

seized 4y ago

Super easy with the right DNS provider and something like go-acme/Lego. Add a crom job and done. Yeah, not zero effort but compared to early Let's Encrypt with HTTP-01 and such it's quote easy. https://github.com/go-acme/lego https://github.com/go-acme/lego