The script is designed to put some fake self-signed certificates at those places. You could run that specific part from the script separately:
Although you should of course also specify $domains and $rsa_key_size` (or replace the variables yourself) first.
Yes, this part seems to run fine. Here's the output of the init sript in full when I try to run it:
./init-letsencrypt.sh
Existing data found for collabora.alamko.de. Continue and replace existing certificate? (y/N) y
### Creating dummy certificate for collabora.alamko.de ...
Creating collabora_certbot_run ... done
Generating a RSA private key
..............++++
.................................................................................................................................................................................................................................++++
writing new private key to '/etc/letsencrypt/live/collabora.alamko.de/privkey.pem'
-----
### Starting nginx ...
Recreating collabora_nginx_1 ... done
### Deleting dummy certificate for collabora.alamko.de ...
Creating collabora_certbot_run ... done
### Requesting Let's Encrypt certificate for collabora.alamko.de ...
Creating collabora_certbot_run ... done
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for collabora.alamko.de
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: collabora.alamko.de
Type: connection
Detail: Fetching http://collabora.alamko.de/.well-known/acme-challenge/K8Z7iSo6w37diqNpqDIBRVLci-zVhTU54Wdf4AEPrN0: Connection refused
Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
### Reloading nginx ...
2021/06/03 19:50:13 [emerg] 38#38: cannot load certificate "/etc/letsencrypt/live/collabora.alamko.de/fullchain.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/collabora.alamko.de/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/collabora.alamko.de/fullchain.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/collabora.alamko.de/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
root@ubuntu-4gb-hel1-1:~/Projects/collabora#
Chances exist your nginx won't run even with the fake self signed certs due to some other reason. However, you won't be able to debug that by running the entire script, as it'll delete the fake certs also, which would make nginx dysfunctional again if certbot doesn't work. The fact LE still reports a "connection refused" leads me to believe nginx has some other issue.
You should run the separate fake cert part and then run nginx -T again:
path="/etc/letsencrypt/live/collabora.alamko.de"
mkdir -p "./data/certbot/conf/live/collabora.alamko.de"
docker-compose run --rm --entrypoint "\
openssl req -x509 -nodes -newkey rsa:4096 -days 1\
-keyout '$path/privkey.pem' \
-out '$path/fullchain.pem' \
-subj '/CN=localhost'" certbot
I copied your code block to a .sh script and ran it:
./lecommunity.sh
Creating collabora_certbot_run ... done
Generating a RSA private key
...................++++
........................................................................................++++
writing new private key to '/etc/letsencrypt/live/collabora.alamko.de/privkey.pem'
However, when the script finishes there's no running nginx docker container for me to exec into and check nginx -T. The script just runs with the above output?
That's because that part of the script doesn't do anything with the nginx container? It uses the certbot container to just write some fake certs to the place the actual certbot certificates would end up.
You should be able to do your nginx magic to get docker to do something with nginx -T. I don't use docker (luckily..), so no idea how you'd do that.
Edit: Probably something like docker-compose up --force-recreate -d nginx ? Got that from the script too, wasn't that hard to find........
OK, thanks again. I was able to run the container with your suggestion. After running it I exec into it and ran nginx -T. Below is the output. Let me know if this gives any new info or if there's any other info I can provide?
nginx -T
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# configuration file /etc/nginx/nginx.conf:
user nginx;
worker_processes 1;
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;
include /etc/nginx/conf.d/*.conf;
}
# configuration file /etc/nginx/mime.types:
types {
text/html html htm shtml;
text/css css;
text/xml xml;
image/gif gif;
image/jpeg jpeg jpg;
application/javascript js;
application/atom+xml atom;
application/rss+xml rss;
text/mathml mml;
text/plain txt;
text/vnd.sun.j2me.app-descriptor jad;
text/vnd.wap.wml wml;
text/x-component htc;
image/png png;
image/svg+xml svg svgz;
image/tiff tif tiff;
image/vnd.wap.wbmp wbmp;
image/webp webp;
image/x-icon ico;
image/x-jng jng;
image/x-ms-bmp bmp;
font/woff woff;
font/woff2 woff2;
application/java-archive jar war ear;
application/json json;
application/mac-binhex40 hqx;
application/msword doc;
application/pdf pdf;
application/postscript ps eps ai;
application/rtf rtf;
application/vnd.apple.mpegurl m3u8;
application/vnd.google-earth.kml+xml kml;
application/vnd.google-earth.kmz kmz;
application/vnd.ms-excel xls;
application/vnd.ms-fontobject eot;
application/vnd.ms-powerpoint ppt;
application/vnd.oasis.opendocument.graphics odg;
application/vnd.oasis.opendocument.presentation odp;
application/vnd.oasis.opendocument.spreadsheet ods;
application/vnd.oasis.opendocument.text odt;
application/vnd.openxmlformats-officedocument.presentationml.presentation
pptx;
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
xlsx;
application/vnd.openxmlformats-officedocument.wordprocessingml.document
docx;
application/vnd.wap.wmlc wmlc;
application/x-7z-compressed 7z;
application/x-cocoa cco;
application/x-java-archive-diff jardiff;
application/x-java-jnlp-file jnlp;
application/x-makeself run;
application/x-perl pl pm;
application/x-pilot prc pdb;
application/x-rar-compressed rar;
application/x-redhat-package-manager rpm;
application/x-sea sea;
application/x-shockwave-flash swf;
application/x-stuffit sit;
application/x-tcl tcl tk;
application/x-x509-ca-cert der pem crt;
application/x-xpinstall xpi;
application/xhtml+xml xhtml;
application/xspf+xml xspf;
application/zip zip;
application/octet-stream bin exe dll;
application/octet-stream deb;
application/octet-stream dmg;
application/octet-stream iso img;
application/octet-stream msi msp msm;
audio/midi mid midi kar;
audio/mpeg mp3;
audio/ogg ogg;
audio/x-m4a m4a;
audio/x-realaudio ra;
video/3gpp 3gpp 3gp;
video/mp2t ts;
video/mp4 mp4;
video/mpeg mpeg mpg;
video/quicktime mov;
video/webm webm;
video/x-flv flv;
video/x-m4v m4v;
video/x-mng mng;
video/x-ms-asf asx asf;
video/x-ms-wmv wmv;
video/x-msvideo avi;
}
# configuration file /etc/nginx/conf.d/app.conf:
ssl_certificate /etc/letsencrypt/live/collabora.alamko.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/collabora.alamko.de/privkey.pem;
server {
listen 80;
server_name www.collabora.alamko.de collabora.alamko.de;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
return 301 https://collabora.alamko.de$request_uri;
}
server {
listen 443 ssl;
server_name www.collabora.alamko.de;
return 301 $scheme://collabora.alamko.de$request_uri;
}
server {
listen 443 ssl;
server_name collabora.alamko.de;
location / {
proxy_pass http://collabora.alamko.de:9980;
access_log off;
proxy_set_header Host $host;
}
# static files
location ^~ /loleaflet {
proxy_pass http://collabora.alamko.de:9980;
proxy_set_header Host $http_host;
}
# WOPI discovery URL
location ^~ /hosting/discovery {
proxy_pass http://collabora.alamko.de:9980;
proxy_set_header Host $http_host;
}
# Capabilities
location ^~ /hosting/capabilities {
proxy_pass http://collabora.alamko.de:9980;
proxy_set_header Host $http_host;
}
# main websocket
location ~ ^/lool/(.*)/ws$ {
proxy_pass http://collabora.alamko.de:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
# download, presentation and image upload
location ~ ^/lool {
proxy_pass http://collabora.alamko.de:9980;
proxy_set_header Host $http_host;
}
# Admin Console websocket
location ^~ /lool/adminws {
proxy_pass http://collabora.alamko.de:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
}
# configuration file /etc/nginx/conf.d/default.conf:
server {
listen 80;
listen [::]:80;
server_name localhost;
#charset koi8-r;
#access_log /var/log/nginx/host.access.log main;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
OK, now that your nginx is actually running, you can debug the "connection refused" problem. Because if it's actually running right now, from the world wide web it still seems to be down:
osiris@erazer ~ $ curl -LIv collabora.alamko.de
* Trying 2a01:4f9:c011:b5a::1:80...
* connect to 2a01:4f9:c011:b5a::1 port 80 failed: Connection refused
* Trying 135.181.152.187:80...
* connect to 135.181.152.187 port 80 failed: Connection refused
* Failed to connect to collabora.alamko.de port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to collabora.alamko.de port 80: Connection refused
osiris@erazer ~ $
Please make sure the world wide web can access your nginx docker container on port 80 and also on port 443 (as there's a redirect from 80 to 443 in place).
Right. This is what I was saying when I opened the post. Those redirects shouldn't be there! They existed from when I ran the same docker nginx before - that's what I used for redirects. Now, even when I stop the container the redirects remain in place which I find baffling.
I have no redirects set up, except those in the conf file when I run nginx
The redirects are not the issue right now.. Please read carefully: your entire webserver is not accessible from the world wide web. It does NOT redirect at all, as I can't even connect to port 80.
The part where I mentioned the redirect in my previous post is just to make sure you also make sure port 443 is properly open and not just port 80. Nothing more.
OK, let me check with my hosting provider in the UI...
if you do intend to use it in the running config, please show us what is in it.
Hi, the only file I want to be used in there is app.conf, none of the others. I have since deleted oldapp.conf.
You really need a fully functional HTTP config before trying to enable HTTPS.
Could you expand on this? Is this within the realm of the nginx service I've been working on and quoting throughout the post replies, or do you mean something else entirely?
I think @rg305 means that your nginx should at least provide something on HTTP port 80 before you can even think of getting a certificate.
I'm still seeing connection refused errors.. Is nginx really running at all?
OK, yeah that makes sense. I'm at a total loss of what to do now!
Yes, it's running. I'm currently back to running this nginx:
nginx:
image: nginx:1.19
volumes:
- ./data/nginx/templates:/etc/nginx/templates
- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot
- ./reload.sh:/docker-entrypoint.d/reload.sh
ports:
- "80:80"
- "443:443"
env_file: .env
Then:
docker-compose up -d nginx
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
81da6cee9527 nginx:1.19 "/docker-entrypoint.…" 4 seconds ago Up 2 seconds 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp collabora_nginx_1
The ports on the container map to that of host on 443 and 80.
I don't know where to go next from here 
Is the host running your nginx actually 135.181.152.187 and 2a01:4f9:c011:b5a::1?
Is there a firewall?
How do I check this?
To add to this long thread, here's some terminal output which I think verifies that the ports are indeed open and that there's no firewall:
Ports:
ss -ltnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 0.0.0.0:80 0.0.0.0:* users:(("docker-proxy",pid=2984265,fd=4))
LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=1149367,fd=13))
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=621,fd=3))
LISTEN 0 4096 0.0.0.0:443 0.0.0.0:* users:(("docker-proxy",pid=2984252,fd=4))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=621,fd=4))
And the firewall:
ufw status verbose
Status: inactive
I've contacted my providers support team to ask why my server is refusing connections.
Try testing the web server locally:
curl -Ik 135.181.152.187