Help - Reverse SSL Proxy Configuration - Docker Letsencrypt - Nextcloud

  • Hi,


    I'm quite a newbie on the things I'm trying to do.


    I've setup my NextCloud server on LibreElec. It is working fine. I used docker addon (GitHub - linuxserver/docker-nextcloud) and installed it on port 444.


    Then I installed docker nginx + letsencrypt addon (GitHub - linuxserver/docker-letsencrypt) on port 443 with duckdns validation. But this part isn't working.

    When I call my external ip on port 443, I've got a connection refused.

    When I call it on 444, it works even if currently I've got a redirection to my DNS on 443 so it redirects and then get a connection refused. That mean the nextcloud part is OK but not the nginx and letsencrypt part.


    I tried to find a solution on many websites but without finding it.


    Do someone knows what I missed ? I've got no command line and have to use docker cause I'm using libreelec and don't wanna go on some other installations for long to explain reasons.


    Thanks for those who will read me and try to figure out what my problem is.



    Here is my Nginx Letsencrypt addon parameters :

    Code
    port=443
    url=mydomain.duckdns.org
    subdomains=www,
    validation method=duckdns
    duckdns token=mytoken


    My nextcloud data/www/nextcloud/config/config.php :

    my letsencrypt/config/nginx/proxy-confs/nextcloud.subfolder.conf (unchanged, just copied from sample) :

    my letsencrypt/config/nginx/site-confs/default (unchanged) :


    My router ports forwarding :

    Code
        Name    Start Port    End Port    Protocol    Local IP Address
        HTTP    80    80    TCP    192.168.0.20
        HTTPS    443    444    Both    192.168.0.20
  • Check the letsencrypt logs and it will tell you what's going on

    Code
    docker logs docker.linuxserver.letsencrypt
  • Check the letsencrypt logs and it will tell you what's going on

    Code
    docker logs docker.linuxserver.letsencrypt

    Hi.

    Thanks for the tip. There was this message :

    Quote
    nginx: [emerg] "proxy_max_temp_file_size" directive invalid value in /config/nginx/proxy-confs/nextcloud.subdomain.conf:28

    I corrected it by replacing 2048M by 1024M (after a quick internet search).

    Then I got this message :

    Quote

    nginx: [emerg] BIO_new_file("/config/nginx/dhparams.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/config/nginx/dhparams.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)

    I deleted dhparams.pem to regenerate it :

    Code
    rm letsencrypt/config/nginx/dhparam.pem

    Now it is regenerating but it can take a long time according to the logs. I will tell you if this worked when it will be done.

    Quote

    Creating DH parameters for additional security. This may take a very long time. There will be another message once this process is completed

    Generating DH parameters, 2048 bit long safe prime, generator 2

    This is going to take a long time

    EDIT :

    after that, there still was an error :

    I added the following line into the http block of nginx.conf (after finding this solution online) :

    Quote

    lua_load_resty_core off;

    and now this works !!

    Thanks to your help on finding the docker's log, I have now being able to secure my site.

    I leave it here so people with the same problem can find the solution.

    Edited once, last by Kirjavail ().

  • Great to hear.


    Yeah, the dhparams part can take a long time (up to 2 hours on an arm box) or it could be 10 seconds, that's cryptography for you.


    The lua error is harmless and it's an upstream issue (alpine linux repo)

  • Creating DH parameters for additional security. This may take a very long time. There will be another message once this process is completed Generating DH parameters, 2048 bit long safe prime, generator 2 This is going to take a long time

    Yeah, the dhparams part can take a long time (up to 2 hours on an arm box) or it could be 10 seconds, that's cryptography for you


    For those using an arm device If you don't want to wait always can generate the dhparams.pem in other machine with:

    $ openssl dhparam -out dhparams.pem 2048


    and then, in this case, copy the resulting file to:

    /storage/.kodi/userdata/addon_data/docker.linuxserver.letsencrypt/config/nginx/dhparam.pem


    Any modern x64 PC will complete this operation in less than a minute instead of hours.

    Once you copy the file there, each time the container is started it's init scripts will check if is already there and skip this step unless you change the default DHLEVEL Only then needs to be regenerated.