Letsencrypt Validate Error

Hallo,

I try install Nextcloud with Docker after a Reverse Proxy. The Nexcloud Container runs probarly but wen my Let’s Encrypt Container try to validate my Domain name i got an validation Error. I try many thing but I could not solve this problem. May be some one has an idea or may be help me.
Thanks for supporting.

Here the Error message:

[Sun Dec 19 15:47:00 UTC 2021] Verifying: cloud.meinedomain.de.de
[Sun Dec 19 15:47:03 UTC 2021] cloud.meinedomain.de.de:Verify error:Invalid response from http://cloud.meinedomain.de.de/.well-known/acme-challenge/wA32DiXMF60dQgaST82qrR59yjJe8KXpppBXWJUj1jk [194.36.145.30]: 
[Sun Dec 19 15:47:03 UTC 2021] Please check log file for more details: /dev/null

Here my Docker YML File:

version: '3.7' 

services:

  nextcloud_datenbank:
    image: postgres:13
    container_name: nextcloud_db
    restart: always
    networks:
     ExtNet:
       ipv4_address: 172.18.4.1
    environment:
      - POSTGRES_USER=nextcloud_usr
      - POSTGRES_PASSWORD=myPassword
      - POSTGRES_DB=nextcloud
    volumes:
      - /daten/docker/nextcloud_db/postgres/13:/var/lib/postgresql/data

  nextcloud_redis:
    image: redis:alpine
    container_name: nextcloud_redis
    restart: always

  nextcloud_cron:
    image: nextcloud:fpm-alpine
    container_name: nextcloud_cron
    restart: always
    volumes:
      - /daten/docker/nextcloud_html:/var/www/html
    entrypoint: /cron.sh
    depends_on:
      - nextcloud_datenbank
      - nextcloud_redis

  nextcloud_server:
    image: nextcloud:fpm-alpine
    container_name: nextcloud_server
    networks:
     ExtNet:
       ipv4_address: 172.18.4.4
    environment:      
      - POSTGRES_DB=nextcloud
      - POSTGRES_USER=nextcloud_usr
      - POSTGRES_PASSWORD=myPassword
      - POSTGRES_HOST=db:5432
      - REDIS_HOST=nextcloud_redis
    restart: always    
    volumes:
      - /daten/docker/nextcloud/html:/var/www/html
      - /daten/docker/nextcloud/config:/var/www/html/config
      - /daten/docker/nextcloud/custom_apps:/var/www/html/custom_apps
      - /daten/docker/nextcloud/data:/var/www/html/data
      - /daten/docker/nextcloud/themes:/var/www/html/themes
      - /etc/localtime:/etc/localtime:ro
    depends_on:
      - nextcloud_datenbank
      - nextcloud_redis

  nextcloud_web:
    image: nginx:alpine    
    container_name: nextcloud_web
    networks:
     ExtNet:
       ipv4_address: 172.18.4.5
    environment:
      - VIRTUAL_HOST=cloud.meinedomain.de
      - LETSENCRYPT_HOST=cloud.meinedomain.de
      - LETSENCRYPT_EMAIL=letsencrypt@meinedomain.de     
    restart: always
    volumes:
      - /daten/docker/nextcloud_web/nginx.conf:/etc/nginx/nginx.conf
      - /daten/docker/nextcloud/html:/var/www/html:ro
    depends_on:
      - nextcloud_server
    
networks:
  ExtNet:
    external: true
    name: ssl-proxy-network

and here the nginx config file for the web container:

worker_processes auto;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    upstream php-handler {
        server nextcloud_server:9000;
    }

    server {
        listen 80;

        # HSTS settings
        # WARNING: Only add the preload option once you read about
        # the consequences in https://hstspreload.org/. This option
        # will add the domain to a hardcoded list that is shipped
        # in all major browsers and getting removed from this list
        # could take several months.
        #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;

        # set max upload size
        client_max_body_size 512M;
        fastcgi_buffers 64 4K;

        # Enable gzip but do not remove ETag headers
        gzip on;
        gzip_vary on;
        gzip_comp_level 4;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
        gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

        # Pagespeed is not supported by Nextcloud, so if your server is built
        # with the `ngx_pagespeed` module, uncomment this line to disable it.
        #pagespeed off;

        # HTTP response headers borrowed from Nextcloud `.htaccess`
        add_header Referrer-Policy                      "no-referrer"   always;
        add_header X-Content-Type-Options               "nosniff"       always;
        add_header X-Download-Options                   "noopen"        always;
        add_header X-Frame-Options                      "SAMEORIGIN"    always;
        add_header X-Permitted-Cross-Domain-Policies    "none"          always;
        add_header X-Robots-Tag                         "none"          always;
        add_header X-XSS-Protection                     "1; mode=block" always;

        # Remove X-Powered-By, which is an information leak
        fastcgi_hide_header X-Powered-By;

        # Path to the root of your installation
        root /var/www/html;

        # Specify how to handle directories -- specifying `/index.php$request_uri`
        # here as the fallback means that Nginx always exhibits the desired behaviour
        # when a client requests a path that corresponds to a directory that exists
        # on the server. In particular, if that directory contains an index.php file,
        # that file is correctly served; if it doesn't, then the request is passed to
        # the front-end controller. This consistent behaviour means that we don't need
        # to specify custom rules for certain paths (e.g. images and other assets,
        # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
        # `try_files $uri $uri/ /index.php$request_uri`
        # always provides the desired behaviour.
        index index.php index.html /index.php$request_uri;

        # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
        location = / {
            if ( $http_user_agent ~ ^DavClnt ) {
                return 302 /remote.php/webdav/$is_args$args;
            }
        }

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }

        # Make a regex exception for `/.well-known` so that clients can still
        # access it despite the existence of the regex rule
        # `location ~ /(\.|autotest|...)` which would otherwise handle requests
        # for `/.well-known`.
        location ^~ /.well-known {
            # The rules in this block are an adaptation of the rules
            # in `.htaccess` that concern `/.well-known`.

            location = /.well-known/carddav { return 301 /remote.php/dav/; }
            location = /.well-known/caldav  { return 301 /remote.php/dav/; }

            location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
            location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

            # Let Nextcloud's API for `/.well-known` URIs handle all other
            # requests by passing them to the front-end controller.
            return 301 /index.php$request_uri;
        }

        # Rules borrowed from `.htaccess` to hide certain paths from clients
        location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
        location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }

        # Ensure this block, which passes PHP files to the PHP process, is above the blocks
        # which handle static assets (as seen below). If this block is not declared first,
        # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
        # to the URI, resulting in a HTTP 500 error response.
        location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            #fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

        location ~ \.(?:css|js|svg|gif)$ {
            try_files $uri /index.php$request_uri;
            expires 6M;         # Cache-Control policy borrowed from `.htaccess`
            access_log off;     # Optional: Don't log access to assets
        }

        location ~ \.woff2?$ {
            try_files $uri /index.php$request_uri;
            expires 7d;         # Cache-Control policy borrowed from `.htaccess`
            access_log off;     # Optional: Don't log access to assets
        }

        # Rule borrowed from `.htaccess`
        location /remote {
            return 301 /remote.php$request_uri;
        }

        location / {
            try_files $uri $uri/ /index.php$request_uri;
        }
    }
}

i think .de.de could be a serious problem as a domain name. I doubt that you’re the owner of that one…

Ok you are right I did not see the error I will check it…thanks for the hint…Have you an idea where the second “.de” came from. I configure other Container with the same “VIRTUAL_HOST=cloud.meinedomain.de”. Is Nextcloud adding the “.de” …?

Thanks for answering…

Sorry it was my mistake I repIaced my domain to post it here. I checked it today and I got the same error (without the duplicated “.de”):

Creating/renewal cloud.meinedomain.de certificates... (cloud.meinedomain.de)
[Mon Dec 20 19:27:11 UTC 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Mon Dec 20 19:27:11 UTC 2021] Creating domain key
[Mon Dec 20 19:27:11 UTC 2021] The domain key is here: /etc/acme.sh/letsencrypt@my.mail.de/cloud.meinedomain.de/cloud.meinedomain.de.key
[Mon Dec 20 19:27:11 UTC 2021] Single domain='cloud.meinedomain.de'
[Mon Dec 20 19:27:11 UTC 2021] Getting domain auth token for each domain
[Mon Dec 20 19:27:13 UTC 2021] Getting webroot for domain='cloud.meinedomain.de'
[Mon Dec 20 19:27:13 UTC 2021] Verifying: cloud.meinedomain.de
[Mon Dec 20 19:27:16 UTC 2021] cloud.meinedomain.de:Verify error:Invalid response from http://cloud.meinedomain.de/.well-known/acme-challenge/1EP2gnT9sEmvE2Cty7k_v5kWkmTHYNhtFK6h0l7fVtk [194.36.145.30]: 
[Mon Dec 20 19:27:16 UTC 2021] Please check log file for more details: /dev/null

Is port 80 opened in the firewall and redirected to your Nextcloud instance?

Letsencrypt need both ports (80 and 443) to veryfy - at every renew, too.

I checked it and the Ports 80 and 443 are open. I have other Container (for example Gitea, Vaultwarden etc.) behind the Proxy and they will work porberly.
I add in the nextcloud_web service a virtual port 8080 and map this port to the port 80 like described on the Docker Hub Nextcloud Projekt:

But this doesn’t work. I get the same error:

[Tue Dec 21 18:35:36 UTC 2021] Getting webroot for domain='cloud.meinedomain.de'
[Tue Dec 21 18:35:37 UTC 2021] Verifying: cloud.meinedomain.de
[Tue Dec 21 18:35:40 UTC 2021] cloud.meinedomain.de:Verify error:Invalid response from http://cloud.meinedomain.de/.well-known/acme-challenge/gIOxjevinIajswQAgHrzHip_cmErO11JMXanfkCQ7Ho [194.36.145.30]: 
[Tue Dec 21 18:35:40 UTC 2021] Please check log file for more details: /dev/null

So the http port only can be reached by calling http://cloud.meinedomain.de:8080 from outside? - Letsencrypt needs: http://cloud.meinedomain.de:80

Ok I understand. I checked my proxy configuration again and I figure out I couldn’t start my other containers too. They runs in the same error. So I look at the proxy container project on docker hub and there was a link to an new project. The project what I use is deprecated. I will now chance my proxy to the new project and then I test it again.
Thanks for your support.