• Throw a Foxtrot@lemmynsfw.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    How do you get certs for internal applications?

    I use caddy and it does everything for me, but my limited understanding is that the dns entry for which the certs are requested must point to the ip address at which caddy is listening. So if I have a DNS entry like internal.domain.com which resolves to 10.0.0.123 and caddy is listening on that address I can get a http connection, but not an https connection, because letsencrypt can’t verify that 10.0.0.123 is actually under my control.

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

      There is an alternate verification method using an API key to your DNS provider, if it’s a supported one. That method doesn’t need any IP to be assigned (doesn’t care if there are A/AAAA records or where they point because it can verify the domain directly).

      deSEC.io is a good example of a good, reputable and free DNS provider that additionally allows you to manage API keys. The catch is that they require you to enable DNSSEC (their mission is similar to Let’s Encrypt, but for DNS).

    • Lem453@lemmy.ca
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      10 months ago

      You are completely correct…for normal certs. Internal domains require a wild card cert with DNS challenge.

      This video explains how to set it up with traefik

      https://youtu.be/liV3c9m_OX8

      I’d bet caddy can do something similar.

      Basically you have:

      1. Seafile.domain.com -> has it’s own cert
      2. *.local.domain.com -> has its own cert but the * can be anything and the same cert can be used for anything in place of the star as many times as you want and therefore doesn’t need to be internet accessible to verify. That way vaultwarden.local.domain.com remains local only.