I’m concerned that your location directive might be mapping http://colony47.de/.well-known/acme-challenge/ to /var/www/letsencrypt instead of to /var/www/letsencrypt/.well-known/acme-challenge. The latter is what Certbot will expect when given -w /var/www/letsencrypt.

Nginx itself is configured as reverse proxy, getting everything on port 80 and redirects it to what is called, so my blog, nextcloud and letsencrypt. Encryption works fine, so letsencrypt seems to work, so does the other sites. Http gets redirected to https.

A standard debugging suggestion in this case is to put a text file in /var/www/letsencrypt/.well-known/acme-challenge/hello.txt and see if you see its contents when visiting http://colony47.de/.well-known/acme-challenge/hello.txt in a web browser or with curl. If you don’t, then you have a mismatch between what you’re telling Certbot to do with -w and what the CA is validating, which is caused by an incorrect web server configuration or an inappropriate choice of -w value. (I suspect that’s the problem here.)

fastcgi_intercept_errors on;
# Raise timeout values.
# This is especially important when the ownCloud setup runs into timeouts (504 gateway errors)
fastcgi_read_timeout 300;
fastcgi_send_timeout 300;
fastcgi_connect_timeout 300;
# Pass PHP variables directly to PHP.
# This is usually done in the php.ini. For more flexibility, these variables are configured in the nginx config.
# All the PHP parameters have to be set in one fastcgi_param. When using more 'fastcgi_param PHP_VALUE' directives, the last one will override all the others.
fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/dev/urandom