Subdomain failed during installation

Help
1

Hi I am trying to install a certificate on to the newly installed standalone jitsi video server, but the challenge failed during the domain look up, however, the server is behind 2 layer of NAT router, the first router is the gateway 192.168.2.1 while the second layer router is 192.168.2.20(router IP) reserved to 192.168.2.1 network, however, the second network is 192.168.3.1 (router dhcp) to the actual server (192.168.3.20) who now holding the certificate, however, the site does showed it is secured.
The site is conference.vmeet.ca
When typed into URL, the output is not secured.
Please help.

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 domain is:conference.vmeet.ca

I ran this command:

It produced this output:

My web server is (include version):Nginx

The operating system my web server runs on is (include version):
Ubuntu 18.04 LTS
My hosting provider, if applicable, is:
Self Host
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):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
Certbot

1 Like
2

Is your firewall set to allow ports 80 and 443?

curl -Iki http://conference.vmeet.ca/
curl: (7) Failed to connect to conference.vmeet.ca port 80: Connection refused

curl -Iki https://conference.vmeet.ca/
curl: (7) Failed to connect to conference.vmeet.ca port 443: Connection refused
1 Like
3

Hi my second NAT router is DMZ so it is wide open, however, I set the Ubuntu UFW allow Niginx Full and also 443 and SSH 22
root@conference:/home/michael# ufw status
Status: active

To Action From

Nginx Full ALLOW Anywhere
443/tcp ALLOW Anywhere
4443/tcp ALLOW Anywhere
10000/udp ALLOW Anywhere
80/tcp ALLOW Anywhere
22/tcp ALLOW Anywhere
80/udp ALLOW Anywhere
443/udp ALLOW Anywhere
Nginx Full (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
4443/tcp (v6) ALLOW Anywhere (v6)
10000/udp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80/udp (v6) ALLOW Anywhere (v6)
443/udp (v6) ALLOW Anywhere (v6)

1 Like
4

How did you get the certificate?
Where is the certificate?
How is it being used by the conferencing system?
Why do you have a "server" set to use DHCP?

1 Like
5

I used jitsi-meet installation to get the letsencrypt, I believe it is in the letsencrypt folder, the jitsi app is already to config to use the certificate to validate real domain.
The router (NAT) is not a server but will able to do dhcp, however the server which holds the current certificate is static ip address assigned.
Can you let me know where I can check the certificate located?

1 Like
6

If you have openssl, you might be able to use that to connect to the IP:port to show the cert(s).
Do you have OpenSSL?
Do you know how to use in it that way?

1 Like
7

Not sure if Openssl is installed but will check in Ubuntu 18.04
Will let you know in few minutes, I cant find the file in the directory

8

OK, it is not installed for sure and I have a brief looked at the instruction as how to install the openssl, even I can do it and have it installed, I doubt myself that will be able to have it work, I also have further questions about Letsencrypt, I currently have another conference certificate using the same ports (80, 443,) but the server is not on only the NAT router in the same IP address but in a different (192.168.2.xxx) sub-net, and this .2.xxx NAT router of that (80, 443 ports used) also is the gateway 192.168.2.1 of the secondary NAT router (192.168.2.25) of 192.168.3.xxx network, do we have conflict here because of another server has claimed the ports

1 Like
9

OpenSSL can be installed on any (other) system that can access your conference server.

I don’t even know which port(s) your conference server uses.
But if both conference servers use the same ports then they would have to use different IPs.
If they are to be accessed via the same IP, then they will need to use different ports.
OR
If the conference software can be used behind a proxy, then you might be able to give the proxy those ports and have it deal with both of them. Allowing them both to “share” the same IPs and port(s).

1 Like
10

I am curious if Nginx can be used as reverse proxy for this and if yes, how letsencrypt can be installed on Nginx for reverse proxy function instead of certificate per incident (per app per cert),
My thinking is that LetsEnrypt Cert per Nginx will save lost time of configuration since Nginx acted as web server which will function as validation of real domain name.
If this function already available, how and where I can get the documentation to guide me or other users, please help…

2 Likes
11

To address your suggestion, Can I set the configuration of Nginx sites available sub-domain conf file listen to other port instead of port 80 for the jitsi-meet and force the redirection to port 4444 instead port 443, also if possible that can obtain one certificate for Nginx web server instead per site validation because Nginx is doing all the front end validation, is the *wildcard do the same and how to know more if this even possible, thanks for your help in advance.

1 Like
12

NGINX is a very good (reverse) proxy choice.
And I would use it for all inbound connections.
It can be set to redirect to other ports, but that should not be necessary and may cause connectivity issues (for those that can’t reach non-standard ports).
And you can’t redirect the LE authentication requests to a non-standard port (only 443 will be followed).
Getting a wildcard cert may be beneficial and may ease the complexities with adding/removing any additional systems/services. But wildcard certs require DNS authentication; which means that both the ACME client and the DNS service provider must support DNS changes via API.

I would direct all inbound port 80 and 443 to the NGINX proxy.
Let the proxy handle all the cert maintenance.
Redirect all non-authentication requests to HTTPS(443).
Handle any web sites that can be handled directly by the proxy locally (if any).
And proxy the remaining (or all) inbound HTTPS request to their respective back-end systems (using SNI for end-point determination).

2 Likes
13

Hi Thanks I have taken the easier route by placing the server to the first NAT router layer, so requests from Internet just send to the first layer paths.
But I have now a new issues with web sites that I installed certificate (certbot -i nginx -d vmeet.ca -d www.vmeet.ca -d vmeet.biz -d www.vmeet.biz) and the certbot tells me that the certificate installation is successfully however, there are no lock on the browser when I typed http://www.vmeet.ca or http://www.vmeet.biz , can you please help.

1 Like
14

Is that problem seen only from within the same LAN(s) or also from the Internet?

1 Like
15

Hi, it is from the web on the internet
I rebooted the server and use mobile phone to check both the conference and the web pages only conference do the secured and the one without www will have the lock image, what is interesting here is that when I typed https://www.domain.ca, it will redirected me to the secured page, and it will not if I just typed http://www.domain.ca, it will just show the unsecured page

1 Like
16

The means there is no redirection to HTTPS on the HTTP page.

1 Like
17

how to fix that can I post the cofig here for you to look at?
Here is the file :
server {
listen 80;
listen [::]:80;

    root /var/www/vmeet.biz/html;
    index index.html index.htm;

    server_name vmeet.biz  www.vmeet.biz;

    location / {
            try_files $uri $uri/ =404;
    }

listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/www.vmeet.ca/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/www.vmeet.ca/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

}

1 Like
18

Try adding:

if ($scheme=='http') {
  return 301 https://$host$request_uri;
}
1 Like
19

where should the code placed after 404;? or ?

20

After “server_name” line is OK.

1 Like