• solrize@lemmy.world
    link
    fedilink
    English
    arrow-up
    52
    arrow-down
    3
    ·
    4 months ago

    Browsers barf at non https now. What are we supposed to do about certificates?

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      28
      arrow-down
      1
      ·
      4 months ago

      If you mean properly signed certificates (as opposed to self-signed) you’ll need a domain name, and you’ll need your LAN DNS server to resolve a made-up subdomain like lan.domain.com. With that you can get a wildcard Let’s Encrypt certificate for *.lan.domain.com and all your https://whatever.lan.domain.com URLs will work normally in any browser (for as long as you’re on the LAN).

      • solrize@lemmy.world
        link
        fedilink
        English
        arrow-up
        24
        ·
        4 months ago

        Right, main point of my comment is that .internal is harder to use that it immediately sounds. I don’t even know how to install a new CA root into Android Firefox. Maybe there is a way to do it, but it is pretty limited compared to the desktop version.

        • cereals@lemmy.ml
          link
          fedilink
          English
          arrow-up
          8
          ·
          4 months ago

          You can’t install a root CA in Firefox for android.

          You have to install the cert in android and set Firefox to use the android truststore.

          You have to go in Firefox settings>about Firefox and tap the Firefox logo for a few times. You then have a hidden menu where you can set Firefox to not use its internal trust store.

          You then have to live with a permanent warning in androids quick setting that your traffic might be captured because of the root ca you installed.

          It does work, but it sucks.

        • lemmyvore@feddit.nl
          link
          fedilink
          English
          arrow-up
          6
          ·
          4 months ago

          This is not a new problem, .internal is just a new gimmick but people have been using .lan and whatnot for ages.

          Certificates are a web-specific problem but there’s more to intranets than HTTPS. All devices on my network get a .lan name but not all of them run a web app.

        • Petter1@lemm.ee
          link
          fedilink
          English
          arrow-up
          3
          arrow-down
          2
          ·
          4 months ago

          You do not have to install a root CA if you use let’s encrypt, their root certificate is trusted by any system and your requested wildcard Certificate is trusted via chain of trust

          • solrize@lemmy.world
            link
            fedilink
            English
            arrow-up
            13
            arrow-down
            1
            ·
            4 months ago

            That’s if you have a regular domain instead of.internal unless I’m mixing something. Topic of thread is .internal as if it were something new. Using a regular domain and public CA has always been possible.

        • lud@lemm.ee
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          4 months ago

          They didn’t make this too be easy to use. They don’t give a shit about that. That isn’t their job in the slightest.

          They reserved a TLD, that’s all.

          You can use any TLD you want on your internal network and DNS and you have always been able to do that. It would be stupid to use an already existing domain and TLD but you absolutely can. This just changes so that it’s not stupid to use .internal

            • lud@lemm.ee
              link
              fedilink
              English
              arrow-up
              2
              arrow-down
              3
              ·
              4 months ago

              But why are people even discussing that?

              This is about an ICANN decision. TLS has nothing to do with that. Also you don’t really need TLS for self hosting. You can if you want though.

              • JackbyDev@programming.dev
                link
                fedilink
                English
                arrow-up
                1
                ·
                3 months ago

                People can talk about whatever they want whenever they want. The discussion naturally went to the challenges of getting non-self-signed certificates for this new TLD. That’s all.

    • BlueBockser@programming.dev
      link
      fedilink
      English
      arrow-up
      21
      ·
      4 months ago

      Nothing, this is not about that.

      This change gives you the guarantee that .internal domains will never be registered officially, so you can use them without the risk of your stuff breaking should ICANN ever decide to make whatever TLD you’re using an official TLD.

      That scenario has happened in the past, for example for users of FR!TZBox routers which use fritz.box. .box became available for purchase and someone bought fritz.box, which broke browser UIs. This could’ve even been used maliciously, but thankfully it wasn’t.

    • egonallanon@lemm.ee
      link
      fedilink
      English
      arrow-up
      14
      ·
      4 months ago

      Either ignore like I do or add a self signed cert to trusted root and use that for your services. Will work fine unless you’re letting external folks access your self hosted stuff.

      • Findmysec@infosec.pub
        link
        fedilink
        English
        arrow-up
        4
        arrow-down
        1
        ·
        edit-2
        3 months ago

        Private CA is the only way for domains which cannot be resolved on the Internet

      • JackbyDev@programming.dev
        link
        fedilink
        English
        arrow-up
        3
        ·
        3 months ago

        How do you propose to get LetsEncrypt to offer you a certificate for a domain name you do not and cannot control?

    • rushaction@programming.dev
      link
      fedilink
      English
      arrow-up
      10
      ·
      3 months ago

      Quite literally my first thought. Great, but I can’t issue certs against that.

      One of the major reasons I have a domain name is so that I can issue certs that just work against any and all devices. For resources on my network. Home or work, some thing.

      To folks recommending a private CA, that’s a quick way to some serious frustration. For some arguably good reasons. On some devices I could easily add a CA to, others are annoying or downright bullshit, and yet others are pretty much impossible. Then that last set that’s the most persnickety, guests, where it’d be downright rude!

      Being able to issue public certs is easily is great! I don’t use .local much because if it’s worth naming, it’s worth securing.

          • JackbyDev@programming.dev
            link
            fedilink
            English
            arrow-up
            3
            ·
            3 months ago

            So you can access your router’s config page without blasting your password in plaintext or getting certificate warnings. It’s an optional feature.

      • Railing5132@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 months ago

        Same thing we do with .local - “click here to proceed (unsafe)” :D

        Set up my work’s network waay back on NT4. 0 as .local cuz I was learning and didn’t know any better, has been that way ever since.

    • exu@feditown.com
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      1
      ·
      4 months ago

      You can set up your own CA, sign certs and distribute the root to every one of your devices if you really wanted to.

      • solrize@lemmy.world
        link
        fedilink
        English
        arrow-up
        24
        ·
        4 months ago

        Yeah I know about that, I’ve done it. It’s just a PITA to do it even slightly carefully.

    • state_electrician@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      4
      ·
      4 months ago

      I found options like .local and now .internal way too long for my private stuff. So I managed to get a two-letter domain from some obscure TLD and with Cloudflare as DNS I can use Caddy to get Let’s Encrypt certs for hosts that resolve to 10.0.0.0/8 IPs. Caddy has plugins for other DNS providers, if you don’t want to go with Cloudflare.

      • kudos@lemmy.ml
        link
        fedilink
        English
        arrow-up
        3
        ·
        4 months ago

        Might be an idea to not use any public A records and just use it for cert issuance, and Stick with private resolvers for private use.

        • state_electrician@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          3
          ·
          4 months ago

          It’s a domain with hosts that all resolve to private IP addresses. I don’t care if someone manages to see hosts like vaultwarden, cloud, docs or photos through enumeration if they all resolve to 10.0.0.0/8 addresses. Setting up a private resolver and private PKI is just too much of a bother.

          • fine_sandy_bottom@lemmy.federate.cc
            link
            fedilink
            English
            arrow-up
            1
            ·
            4 months ago

            My set up is similar to this but I’m using wildcards.

            So all my containers are on 10.0.0.0/8, and public dns server resolves *.sub.domain.com to 10.0.0.2, which is a reverse proxy for the containers.

    • wolo@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      4 months ago

      Maybe browsers could be configured to automatically accept the first certificate they see for a given .internal domain, and then raise a warning if it ever changes, probably with a special banner to teach the user what an .internal name means the first time they see one

      • ayyy@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 months ago

        The main reason this will never happen is that the browser vendors make massive revenue and profit margins off of The Cloud and would really prefer that the core concept of a LAN just dies so you pay your rent to them.