Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domains are:
I ran this command:
sudo certbot certonly --nginx
It produced this output:
Congratulations… (all good).
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you’re using Certbot):
I ran into the weirdest error I have ever seen. My ISP provides me only one Dynamic DNS entry. So I use dns-o-matic to spam more than one. I build two Raspberry servers, one is a Nextcloud and the other one is a Rocket.chat, both have near the same settings, DietPi - Debian Buster, Nginx and certbot.
Nextcloud was first and it runs all good, but after setting up Rocket.chat with another dynDNS certbot decides to point everything to the last one. If I use samsycloud.ddns.net I got redirected to jaeger.v6.rocks, all are pointing to the last cert.
I think it has something to do with the same IP share. So I tried to use a selfsigned for the nextcloud. But this isnt working. Connecting local to nextcloud is possible but I need a working ssl solution for the cloud to use it from everywhere.
Any ideas what could be my opportunities in this scenario?
Btw. normaly nextcloud runs from samsycloud.ddns.net/nextcloud, isnt it possible to point one cert for both, just one to xyz.ddns and the same to xyz.ddns/nextcloud, is this the “wildcard”-scenario? IDK how.
Thx for reading.