How do you use other docker apps to use letsencrypt's certs?

    • OMV 5.x (beta)
    • How do you use other docker apps to use letsencrypt's certs?

      I am using Rpi 4, OMV5, docker and portainer.

      So the other day I managed to isntall a cert via letsencrypt's duckdns so I can go to https://<mydomain>.duckdns.org with no problems. Now I want to use emby to use https://<mydomain>.duckdns.org:8920 but somehow I could not get the emby app to utilize letsencrypt's certifcate. I also created subdomains like sonarr.<mydomain>.duckdns.org radarr.<mydomain>.duckdns.org and jackett.<mydomain>.duckdns.org but not sure how I can take advantage of the letsencrypt certificate. Any advice would be helpful. TIA.
    • Similar to your question: you sign up and select five sub domains and only use one for Nextcloud. abc.duckdns.org points to Nextcloud and def.duckdns.org, ghi.duckdns.org, jkl.duckdns.org, and mno.duckdns.org all say



      Welcome to our server

      The website is currently being setup under this address.
      For help and support, please contact: me@example.com
      I hope you find your solution. Me, I just wonder about the potential.
      OMV 5 (current) - NanoPi M4: Nextcloud, Plex, & Heimdall - Acer Aspire T180: backup - Odroid XU4: Pi-Hole (DietPi) - Odroid HC2, Raspberry Pi 3B+, and HP dx2400: testing.
    • @'pug_sterpug_ster'

      With letsencrypt you can create a certificate which has all the domains you need, then you can point each service you have to a single letsencrypt key and cert, and it should work. Make sure you put the key and cert in a location where each service can access them, as they might be running as different users. The key will want to have 400 permissions so your services will probably be started as root, and then drop their permissions and run under a different user for the requests they will receive.

      Because you don't say what you mean by utilise, I can't tell what the issue is, but it will certainly be easier to maintain a single cert rather than have each one reissued, even though this happens automatically, it will mean that if you ever have any problems, you will be less likely to hit rate limits with letsencrypt. The only downside is that if someone inspects your cert they can see the other hosts listed there, but then that's just security by obscurity, and you'll not want to rely on hiding hostnames to prevent access to your servers.

      Perhaps you could go into detail about the error you got or what you already tried.
    • I had the same problems and resolved it by using a reverse proxy for emby. The advantage of this is you don't have to worry about port forwarding.

      I link to emby by emby.mydomian.org

      This needs you to run certbot again to create a second letsencrypt certificate for the new domain. I assume you are using nginx as web server? You'll no doubt find an example of how to do this in the emby documentation. I use Apache as my web server, I can post the necessary conf file if interested.

      Having said all this I do this on a Ubuntu 18.04 server device not OMV but the principal is the same i am sure.

      If you use for example mydomain.org/jackett it uses the existing certificate but

      jackett.mydomain.org needs a seperate certificate.

      John
    • pug_ster wrote:

      So the other day I managed to isntall a cert via letsencrypt's duckdns
      How did you install it? If you used the letsencrypt docker by linuxserver.io you can make use of the inbuild reverse proxy to access your different services (e.g. emby, etc.).
      If you use this this method its not neccessary to create additional subdomains in duckdns. Only one subdomain, which you seem to already have is enough.
      Then you have to modify your letsencrypt container and add the additional services in the env-variable SUBDOMAINS so that the cert is valid for them (e.g. emby,nextcloud,raadarr).
      In the /config/nginx/proxy-confs/ folder are sample config files for most of the services which you just have to activate by deleting the .sample at the end of the wanted file (e.g. emby.subdomain.conf). These files then also contain information if some further configuration of the services is needed.

      Also check out this blog entry by linuxserver to better understand letsencrypt and the inbuild reverse proxy: blog.linuxserver.io/2019/04/25…rypt-nginx-starter-guide/
    • Thanks. I made those subdomains for radarr and sonarr but I don't think I ever used it. After poking around, maybe I should be using <mysubdomain>.duckdns.org/emby as a way to go so I don't have to fuss around with other certificates. What kind of docker do I use so I can use inverse proxy to go to the subdomains? Also, I realized that radarr, sonarr don't require you to login, so I would like some kind of authenication methods to those subportals when using inverse proxy. Thanks.
    • Okay, I think I am getting the hang of this. I have 2 questions. Let's say that I have my mysubdomain.duckdns.org and domains radarr.mysubdomain.duckdns.org registered. I can see in let's encrypt's cert saying that subject alternative name in my letsencrypt cert has this subdomain exist. I just simply have to rename the file radarr.subdomain.conf.sample to radarr.subdomain.conf and restart the letsencrypt docker and it should work, right?

      2nd question, is going back to the first question. I would like to secure my domain radarr.mysubdomain.duckdns.org site with a username and password. I read everywhere about creating an account with the .htpasswd file, but I don't know the command to create an account and the location of where this .htpasswd file to put in. How do I do that? Thanks.
    • pug_ster wrote:

      radarr.subdomain.conf.sample to radarr.subdomain.conf and restart the letsencrypt docker and it should work, right?
      It should. If your container is named radarr and the prerequisites of the .conf file are met: # make sure that your dns has a cname set for sonarr and that your sonarr container is not using a base url


      pug_ster wrote:

      2nd question, is going back to the first question. I would like to secure my domain radarr.mysubdomain.duckdns.org site with a username and password. I read everywhere about creating an account with the .htpasswd file, but I don't know the command to create an account and the location of where this .htpasswd file to put in. How do I do that? Thanks.
      As I stated above the answer is in the readme of the letsencrypt docker. github.com/linuxserver/docker-…y-and-password-protection
    • Just had some time. First of all, many thanks to everyone for helping. I was able to put a password and put in reverse proxy subfolder and it worked great for mysubdomain.duckdns.org /radarr/ and mysubdomain.duckdns.org /sonarr/.

      However, for some reason when I tried it for other websites like mysubdomain.duckdns.org /portainer/ and mysubdomain.duckdns.org /transmission/ it does not work, it give me "502 bad gateway" error. Both dockers uses the default ports 9000 and 9091 respectively and both subfolder.conf has those ports listed. Both containers' conf file says "portainer does not require a base url setting" Is there a reason why this is happening?
    • I only have experience with Apache not nginx - and not all web apps work the same way with reverse proxies.

      For Portainer see - portainer.readthedocs.io/en/1.10.2/faq.html - it's fussy about reverse proxies. For example trying to use the CLI for a Docker container from Portainer works from 192.168.xx.x but not from the reverse proxy address.

      For Transmission maybe use the remote GUI instead of the web address? Whcih may give the same result but worth trying.
    • I realized the letencrypt, radarr, sonarr is using the same network so maybe that's why it works. For the portainer.subfolder.conf, I changed the proxy_pass http://$upstream_portainer:9000 to http://<myinternalip>:9000 and it works fine now. But for transmission, I did the same and it gave me a different message.


      409: Conflict

      Your request had an invalid session-id header.
      To fix this, follow these steps:
      1. When reading a response, get its X-Transmission-Session-Id header and remember it
      2. Add the updated header to your outgoing requests
      3. When you get this 409 error message, resend your request with the updated header
      This requirement has been added to help prevent CSRF attacks.
      X-Transmission-Session-Id: 7BZE6tRGs7claK7lNJ1veapsqGRT4AV3ifWX4aVHMlZlibju
    • Morlan wrote:

      Also check out this blog entry by linuxserver to better understand letsencrypt and the inbuild reverse proxy: blog.linuxserver.io/2019/04/25…rypt-nginx-starter-guide/
      So, if I understand correct, I do not have to run docker logs letsencrypt -f every time when I add subdomain if I use

      Source Code

      1. - SUBDOMAINS=wildcard
      2. - VALIDATION=duckdns
      3. - DUCKDNSTOKEN=97654867496t0877648659765854
      in my yml letsencrypt file?