• KairuByte@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    59
    arrow-down
    3
    ·
    edit-2
    1 year ago

    Why would anyone ever use self signed certs? Buy a cheap ass domain, and use LetsEncrypt to get a free cert.

    • Sal@lemmy.world
      link
      fedilink
      English
      arrow-up
      30
      arrow-down
      1
      ·
      1 year ago

      If it is for internal only, self signed is a lot easier.

      • KSP Atlas@sopuli.xyz
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Also probably no sysadmin uses it, but the Gemini protocol requires the use of a self signed cert

      • KairuByte@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        4
        arrow-down
        7
        ·
        1 year ago

        Hard disagree. As long as you have any machine with internet access it’s trivial, even more so if you can use DNS challenge.

        • SomeKindaName@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          edit-2
          1 year ago

          You’re absolutely correct. For self hosting at home I use cloudflare for DNS challenges.

          Caddy is also amazing at making things even simpler.

        • JWBananas@startrek.website
          link
          fedilink
          English
          arrow-up
          19
          arrow-down
          1
          ·
          1 year ago

          Are you conflating self-signed and untrusted?

          Self-signed is fine if you have a trusted root deployed across your environment.

          • nickwitha_k (he/him)@lemmy.sdf.org
            link
            fedilink
            arrow-up
            6
            arrow-down
            2
            ·
            1 year ago

            Correct. If using actual pki with a trusted root and private CA, you’re just fine.

            I took the statement to mean ad-hoc self-signed certs, signed by the server that they are deployed on. That works for EiT but defeats any MitM protection, etc.

    • krellor@kbin.social
      link
      fedilink
      arrow-up
      11
      ·
      edit-2
      1 year ago

      I use self signed certs for thinclient authentication. Generate self signed cert, load into AWS workspaces, sign device certs with root, and only machines that have the cert installed and pass the username password prompt will get through the AWS service broker. I can’t see how using a CA signed cert helps me in any meaningful way. If I lose trust in the cert, I revoke it myself from the service.

      • nickwitha_k (he/him)@lemmy.sdf.org
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Use of a CA (private CA would be my thought in this case) gives you greater ability to manage certs without needing to manually revoke and the ability to verify authenticity. You’re already doing most of the work to run a private CA, TBH. Just, instead of signing from the machine, you add your private CA’s intermediate cert to the trusted CAs on your hosts, and generate CSRs on your new hosts for your CA to sign.

        Signing from the machine that uses a cert gives it greater authority and increases the “blast radius” if it gets compromised.

        • krellor@kbin.social
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          I do have a private ca service running on an internal ec2 instance, but all the AWS workspaces broker checks is if the device cert being passed by the thinclient was signed by one of the two signing certs you’ve loaded into the service, so the private ca itself still doesn’t manage revocation in this case.

          I do appreciate the suggestion. My main goal in sharing this use case was to show folks that there are many places certificate are used that let’s encrypt isn’t geared up to solve. Other examples are things like signing Microsoft API requests, etc.

          Anyway, have a great day!

    • Shadow@lemmy.ca
      link
      fedilink
      arrow-up
      6
      ·
      1 year ago

      Mtls across a large number of machines. I run my own CA and intermediates on hashicorp vault.

      For end user services, yes LE.

      • KairuByte@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        5
        ·
        1 year ago

        At the point of running your own CA with infrastructure in place to support it, I wouldn’t really call that “self signing.”

        I get that it technically is, since you’re not going through an external CA, but really it’s like calling a companies Datacenter “self hosted” because it’s on their own hardware. Technically the truth, but not what is generally meant. 😜

    • Fal@yiffit.net
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      10
      ·
      1 year ago

      Self signed certs are more secure. You don’t have to trust the whole CA chain

        • Fal@yiffit.net
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          3
          ·
          1 year ago

          but they fix a lot more problems than they cause

          I didn’t say anything that disagrees with this. CAs are nice and convenient. They do this by expanding the chain of trust to a lot more people, hence making them less secure.

          Sure if you can’t securely manage your cert, that’s a problem. But that doesn’t mean let’s less secure

    • slazer2au@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      How are they not secure? You are still doing TLS to the service, maybe they have weak keys but it is still a form of secure connection.

      • nickwitha_k (he/him)@lemmy.sdf.org
        link
        fedilink
        arrow-up
        3
        arrow-down
        3
        ·
        1 year ago

        Certs do more than encryption in transit. They are also used for protection against MitM and authentication. Self-signing removes the ability to verify a cert’s authenticity.

        • Daqu@feddit.de
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          1 year ago

          That’s bullshit. You are the one who issued the cert. You can add it to your list of trusted certificates. You just have to check that this is the right certificate.

          Your man in the middle scare comes from users who ignore cert warnings and continue without checking anything.

          • nickwitha_k (he/him)@lemmy.sdf.org
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            1 year ago

            That’s bullshit.

            Nope. That’s the basics of PKI and scalable, secure, low-trust environments.

            You are the one who issued the cert. You can add it to your list of trusted certificates. You just have to check that this is the right certificate.

            You can indeed do these things. But, are you and your users going to verify every cert for every request and response? That’s a lot of unnecessary cognitive load and tedium, both of which are known to compromise judgement. Are you going to automate it? Ok then how are you going to verify the authenticity of a given cert?

            Your man in the middle scare comes from users who ignore cert warnings and continue without checking anything.

            Humans are not rational actors. Does everyone read the entire EULA? Not even close.

            The problem with your statement, and why it is fallacious, is that you are not accounting for humans besides yourself. I’d even argue that you should also take your human nature into account because we all make mistakes.

            Robust security postures do not require everyone to act perfectly but accept and plan for the fact that we’re fallible. That is why chains and webs of trust were created, so that humans and automated services can take an approach of deference towards a less mutable “expert” on whether a claim of authenticity is trustworthy - giving them the capability and responsibility of deciding this for themselves introduces unnecessary targets for exploits.

            • Daqu@feddit.de
              link
              fedilink
              arrow-up
              1
              arrow-down
              1
              ·
              1 year ago

              Your man in the middle argument is invalid, no matter how much you write. Just trust youur self signed certs and you users see no difference. That’s even more secure than blindly trusting the idiots from verisign.

              Don’t act so smug.

              • nickwitha_k (he/him)@lemmy.sdf.org
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                Your man in the middle argument is invalid, no matter how much you write.

                It really isn’t and it’s a significant part of why PKI exists in the first place. I’ve been doing this stuff professionally for over a decade and am very familiar with ISO27001, SOC2, and CIS standards, as well as generally just finding that a healthy dose of paranoia in computing keeps things more secure. Understanding how and why PKI works and is architected as it is is something that I recommend that everyone involved in technology explore.

                Just trust youur self signed certs and you users see no difference.

                This is problematic if a service needs to be redeployed, the cert expires, or becomes compromised, leaking its keys. In the former two scenarios, the new cert needs to be added on all of your end users’ machines. If you have just a few users, sure, that’s easy enough but, tedious and unnecessary. If it is a case of the latter, you now need to revoke the cert on all systems that have trusted it and deploy a new one. Again, tedious and prone to human error. Plus, you have to hope that you detect this quickly, otherwise a malicious host can harvest a lot of potentially-sensitive information, a situation easily prevented with a trusted CA.

                That’s even more secure than blindly trusting the idiots from verisign.

                I’m not suggesting that a public CA is the best choice for everyone or every situation. For internal use, a well-managed private CA or LE is probably a better choice, purely from a cost perspective.

                I’d also like to understand why you are so hostile towards Verisign and feel better qualified in cert management. Were you or someone close to you caught up in their 2010 breach?

                Don’t act so smug.

                Not sure where this hostility is coming from. I am primarily explaining how these statements are not in line with intended use of security technologies and best practices. If you don’t like currently accepted security best practices, that’s absolutely your prerogative.

        • Fal@yiffit.net
          link
          fedilink
          English
          arrow-up
          4
          ·
          1 year ago

          Basically with self signed certs, you control the ENTIRE trust chain. When you use existing CAs, any bad actor in any of those CAs can generate certs that you would end up trusting. So it’s less secure because you have to trust a lot more people.

          • nickwitha_k (he/him)@lemmy.sdf.org
            link
            fedilink
            arrow-up
            6
            arrow-down
            1
            ·
            1 year ago

            And if you’re not using a trusted CA, you are unable to protect against MitM and other forgery attacks, as well as needing to rely upon a mechanism like TOFU in order to avoid auth fatigue and other human error, which is not great.

            • Fal@yiffit.net
              link
              fedilink
              English
              arrow-up
              7
              ·
              1 year ago

              you are unable to protect against MitM and other forgery attacks

              Uhh, using a self signed cert doesn’t mean you just accept any old cert… Not every cert is designed for serving content to a browser. You do SSL mutual auth between services using self signed certs

              • nickwitha_k (he/him)@lemmy.sdf.org
                link
                fedilink
                arrow-up
                1
                arrow-down
                2
                ·
                1 year ago

                You do SSL mutual auth between services using self signed certs

                If you do, you remove the ability to prove that a service is what it claims to be as this requires accepting its provided cert - that is, authenticate it. You have to trust somewhere, even in a “zero trust” environment. Using self-signed certs for services to communicate means that you have to either have manual involvement every time a service comes up or accept the authenticity of a self-signed cert automatically. Either would be a compromise in security over use of a private CA, not an improvement.

                Again, that works if your only concern is data across the pipes being encrypted during transmission but, it removes nearly all of the other additional security provided by PKI and increases your threat surface. It can be acceptable in some cases, like dev envs or as temporary measures but, with the constant increase in malicious traffic and activity, we’ve got to aim for better.

                • Fal@yiffit.net
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  1 year ago

                  Oh. I’m absolutely including a private CA as part of self signed cert. That’s probably my misuse of the term