Two Servers - two certs, but one points to all

Help
1

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:
jaeger.v6.rocks
samsycloud.ddns.net

I ran this command:
sudo certbot certonly --nginx

It produced this output:
Congratulations… (all good).
My web server is (include version):
2x nginx/1.14.2
The operating system my web server runs on is (include version):
Debian Buster

My hosting provider, if applicable, is:
selfhosted

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):
0.31.0

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.

1 Like
2

Could you explain a little more about your network setup?

You have two Raspberry Pi devices, one nginx installation on each.

When you get receive a request on your IP address, how does your router decide which Raspberry Pi receives the traffic?

It seems to me that it would have to be one server or the other, or a third server which sits in front of the other two and routes between them.

You can create one certificate for both with e.g.:

sudo certbot certonly --nginx -d jaeger.v6.rocks -d samsycloud.ddns.net

… but I’m not sure it would make any sense to, at least not from what I can understand of your question.

2 Likes
3

Yes. One points to local ip 192.xx.xx.33 and the other one is on 192.xx.xx.34. Both have their own nginx installation. I thought this is common sense. But the way you ask, let me believe one nginx installation is okay and I could setup both on one of them?

Yes, I forgot to name the third raspy who only has a Pi-Hole setup. It has a DHCP with it but it is not in use. DHCP and the dynDNS are managed by my router. But the router points the Pi-Hole as the DNSv4 resolver (192.xx.xx.20). DNSv6 not.

hm, I wanna try. Never thought about this.

Why all my settings near working perfectly, without this issue here, doesnt make sense to me, so lets try anyway.

Thx for the quick reply.

1 Like
4

I’ll try to rephrase my question: when somebody connects to 88.68.133.77 on port 80, which Raspberry Pi does that end up connecting to?

You have presumably setup port forwarding on your router - which IP did you forward port 80 to?

1 Like
5

All of them. Thats my problem, I think.

Both, the 33 and the 34.

I see where this is going. :laughing:

But what is the best solution to handle both?

1 Like
6

Well, I guess you see the issue with that. Port-forwarding traffic to both doesn’t quite work.

If I were you I would either:

  • Try fit everything on one Pi, or
  • Give one Pi the role of the reverse proxy for your network, which receives all of the traffic from your router, and then routes it to the correct internal 192.168. host. It also simplifies SSL quite a bit, because only the one server actually has to create and use certificates. There’s quite a few guides out there you can try follow: https://duckduckgo.com/?q=nginx+reverse+proxy+raspberry+pi
1 Like
7

Holy sh… I double checked my last comment and the Rocket.chat Pi, hasnt especially PortForwarding to 80, it has “automatic portforwarding”, and I assumed it must be 80, too. I set them manually and it was impossible to point 80 or 433 because they are in use.

One reverse proxy to rule them all? sounds good, I give it a try. Thx for helping me out, I mark this as solved.

1 Like
8

Now everything is working. Thx alot for pointing my issue. To be clear, with all that tutorials out there managing all with a Nginx install. I would not the only one hitting this mess.

What I have done:

  • made a copy of the sites-enabled conf from the rocket.chat pi
  • removed Nginx + certbot from the rocket.chat pi.
  • mixed the two conf files together on the nextcloud pi.
  • only port-forwarding on the nextcloud pi
  • installed certbot
  • generate keys for both.
  • profit.
1 Like
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.