I ran this command: docker-compose run --rm certbot certonly --webroot --webroot-path /var/www/certbot/ --dry-run -d vps.edcstiftung.eu
It produced this output:
Creating letsencrypt_certbot_run ... done
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Simulating a certificate request for vps.edcstiftung.eu
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: vps.edcstiftung.eu
Type: unauthorized
Detail: 91.92.66.166: Invalid response from http://vps.edcstiftung.eu/.well-known/acme-challenge/tm14ydrZ1DDHsxWzM04j6LOj3hSDxEON54DOVMGPWEg: 404
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.
ERROR: 1
My web server is (include version): nginx/1.24.0
The operating system my web server runs on is (include version): Ubuntu 24.04
My hosting provider, if applicable, is: VPSBG
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.9.0
The domain edcstiftung.eu already has an SSL certificate, but it only covers the top domain itself and not subdomains. It's free and, as a foundation, we cannot really afford the "wildcard" version that also covers subdomains.
Sure they can. The certificates actually cover the name you requested. You then configure your service to use them.
Specifically, your "Express" service that listens on that port needs to be configured.
Your domain at the default HTTPS port also needs improved configuration. It causes a loop. Check your redirects. (sorry for the image - my copy/paste from my sandbox isn't working right now)
To be honest with you, I am not really sure what is causing this, but I think it is the following of various tutorials that led to it. I must have forgotten to undo something after switch between tutorials.
I have a feeling this could be linked to the /etc/nginx/conf.d/app.conf file. I know this isn't the nginx community, but would you know what to correct if the error did come from here:
server {
server_name vps.edcstiftung.eu;
server_tokens off;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://vps.edcstiftung.eu$request_uri;
}
listen 443 ssl; # managed by Certbot
listen [::]:443 ssl ipv6only=on; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/vps.edcstiftung.eu/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/vps.edcstiftung.eu/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = vps.edcstiftung.eu) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name vps.edcstiftung.eu;
return 404; # managed by Certbot
}
Your nginx, for example, was configured to use the certificate using those configuration lines naming the certificate and the listen statement enabling SSL.
I could see from response headers to request to your port 3001 that a system called express was responding. I don't know how to configure that. Maybe someone else here does or visit a forum for that
Well, actually I starting using nginx because it was supposed to be the key to implementing https for the webservices (and password-protect them). So the intention was to have nginx take care of it all; is this not possible?
Probably. You haven't described anything about your use of port 3001 so hard to say for sure. My guess is you have a server block listening on that port and proxying to another service. Is that what you did? If so, please show the server block(s) for port 3001.
If not that, please explain in more detail what is listening on port 3001.
I'll add that there is a learning curve when deciding to become your own server administrator. You would do well to learn more about nginx and the other services you use. Just copying / pasting can create problems if you are not knowledgeable about what you need. This already happened to you with the location block causing the redirect loop.
That's true. Time is a little tight, so there is a bit of learn-as-we-go, but things get clearer as we work on it. I had actually posted a link to a tutorial that helped resolve the issue, but it got flagged as spam so it seems like I cannot share it.
I saw the link and reviewed it. It was extremely complicated for what you have described as your needs so far. I hope the forum admins keep that post hidden
Doing a proxy is fairly straight-forward. You might review the nginx docs such as
I am surprised. I skipped the first steps as these had already been implemented, but the bottom part of the tutorial took just a few minutes and worked like a charm. Anyway, thanks for the link -- I'll read some more about it all.
While certainly one can use nginx for that, you might also want to explore Caddy, which similarly is designed to be in front of services and handle https for them. Though if you have nginx working for what you need now, I certainly understand that there wouldn't be much reason to change things up again.
