Configure nginx to run Jitsi on Debian 10 - nginx

I am running an out of the box Debian GNU/Linux 10 (buster) with nginx and this nginx config file:
/etc/nginx/sites-available/example.abc.de
server {
server_name example.abc.de;
root /var/www/example.abc.de/;
index index.html;
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.abc.de/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.abc.de/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 = example.abc.de) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name example.abc.de;
listen 80;
listen [::]:80;
return 404; # managed by Certbot
}
Now I follow step by step the install tutorial at:
https://jitsi.org/downloads/ubuntu-debian-installations-instructions/
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -
sh -c "echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list"
apt-get -y update
apt-get -y install jitsi-meet
After than I open https://example.abc.de in my web browser and all I see is the content of the /var/www/example.abc.de/index.html file. And that makes sense because the nginx configuration file hasn't changed.
No documentation I can find on https://jitsi.org gives me any additional information. They all say apt-get -y install jitsi-meet and fire up the URL in your browser afterwards.
What is the documentation missing? What do I have to configure to make it happen that I can open the URL in the browser to the the Jitsi system?

Short answer: The current Debian packages don't work with Debian 10.
I posted the same question on a Jitsi board:
https://community.jitsi.org/t/installation-tutorial-doesnt-work-on-a-vanilla-debian-10/25898
The answer was that the current Debian package needs Java 8 but Debian 10 ships with Java 11. For those who are willing to spend the time they can downgrade to Java 8.
Side note: I might say that it is quite disappointing that the Jitsi community publishes a Debian package and puts it in there own install how-to which does not work with the current stable version von Debian.

Related

NGINX access-rights using string-interpolated file location

I found something curious about the nginx configuration.
Whenever I put a string-literal as certificate/key-file location everything works fine. But since I need a bit more dynamic logic I tried maps. But apparently when you include a variable into the file-string, nginx doesn't use its root privileges meaning it cannot open the certificate?
example (this works perfectly):
server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
server_name _;
ssl_certificate /etc/letsencrypt/live/mydomain.com/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem;
# rest of the configuration stuff
}
example (this doesn't somehow):
map $host $cert_name {
mydomain.com mydomain.com;
www.mydomain.com mydomain.com;
default mydomain.com;
}
server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
server_name _;
ssl_certificate /etc/letsencrypt/live/$cert_name/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/$cert_name/privkey.pem;
# rest of the configuration stuff
}
This wil yield in the following error message:
cannot load certificate "/etc/letsencrypt/live/mydomain.com/cert.pem": BIO_new_file() failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/letsencrypt/live/mydomain.com/cert.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib) while SSL handshaking, client: #client-ip#, server: 0.0.0.0:443
additional info:
OS: Ubuntu 20.04
nginx: nginx/1.18.0 (Ubuntu) built with OpenSSL 1.1.1f 31 Mar 2020 TLS SNI support enabled
nginx started as root user?: yes
letsencrypt folder permissions: default
Would this be a security feature? or a bug?
In any case, is there a work around for this?
For if anyone stumbles on this problem.
I found the answer in the letsencrypt documentation.
Basically the /etc/letsencrypt/live and /etc/letsencrypt/archive directories are created with permission 0700 for legacy reasons. When using the latest version of cerbot it is safe to set the permissions to 0755. The command they provided is:
chmod 0755 /etc/letsencrypt/{live,archive}
This allows non-root users to access all public certificates, while the private-keys are still only accessible by the root user/super-users. As it turns out, this is exactually what nginx does which means everything should work after changing the permissions.

NginX https error (500 Internal Server Error) on CentOS

I'm using 'Oracle Cloud'.
I created a VM(Computer instance) on Oracle Cloud with CentOS 8. And I installed NginX, and it works well when I test it with 'http://mydeal.servername.com'.
To make NginX service with HTTPS, I also installed certbot(Let's Encrypt) and created certificate, using the following command.
sudo certbot --standalone -d mydeal.servername.com certonly
Result files were like below.
Cert : /etc/letsencrypt/live/mydeal.servername.com/fullchain.pem;
Key : /etc/letsencrypt/live/mydeal.servername.com/privkey.pem;
I added http and https to firewall service list like below.
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
And I created test index.html like below.
sudo -i
mkdir /var/www
mkdir /var/www/mydeal
echo "MyDeal at Oracle Cloud" > /var/www/mydeal/index.html
And I created https settings, including http redirection, in /etc/nginx/conf.d/my.conf file.
server {
listen 80;
server_name my.servername.com;
location / {
root /var/www/mydeal;
index index.html;
try_files $uri /index.html;
}
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name mydeal.servername.com;
ssl_certificate /etc/letsencrypt/live/mydeal.servername.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mydeal.servername.com/privkey.pem;
location / {
root /var/www/mydeal;
index index.html;
try_files $uri /index.html;
}
}
Finally, when I start nginx server with the following command, it works well.
sudo -i
sudo nginx
But, when I start nginx server with the following command, it gives error "500 Internal Server Error" on the browser screen.
sudo systemctl enable nginx
sudo systemctl start nginx
I can not find any differences b/w 2 start procedures.
How I can debug this problem?

Nginx configuration to Allow curl to Lotstash HTTP Plugin

I have Logstash 8.0.1 with the HTTP plugin running behind an Nginx Reverse Proxy. In addition, I have already used Let's Encrypt Certbot to provide a certificate. I want to be able to do something like the following to push data to Logstash via curl command:
curl --user elastic:<username> -XPUT https://elastic.example.com:8080/_doc/dat/5 -d 'hello'
I have nginx configured in the following way:
http {
server {
server_name elastic.example.com;
location / {
proxy_pass https://10.6.101.20:8080;
}
listen 8080 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/elastic.example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/elastic.example.com/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
}
}
I get a "port 8080 failed: Connection refused"
I suspect the problem can be found in the "location /" line, but I don't know how to fix it. (Adding a similar block for :9200 to support Elasticsearch queries works great.)
I figured it out... I was running nginx within a Docker container and forgot to publish port 8080. Ugh. The good news, is that it works!

ERR_SSL_PROTOCOL_ERROR with Nginx & certbot

I am trying to install a webserver on Raspberry.
I installed nginx and certbot and generated SSL certificate using:
sudo certbot certonly --webroot -w /home/pi/webapp01 -d godestalbin.com -d www.godestalbin.com
My Nginx config is now:
server {
listen 443 ssl;
server_name godestalbin.ga www.godestalbin.ga;
ssl_certificate /etc/letsencrypt/live/godestalbin.ga/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/godestalbin.ga/privkey.pem;
location / {
root /home/pi/webapp01;
}
}
server {
listen 80;
server_name godestalbin.ga;
return 301 https://$host$request_uri;
}
However, I cannot display my website in Chrome which display
Ce site ne peut pas fournir de connexion sécuriséewww.godestalbin.ga a envoyé une réponse incorrecte.
This site cannot provide a secure connection
www.godestalbin.ga gave an incorrect answer
Essayez d'exécuter les diagnostics réseau de Windows.
Try to execute Windows diagnostics
ERR_SSL_PROTOCOL_ERROR
If I display locally on the raspberry my site, I can see the page (I guess because Chromium is less strict about secutiry). It also says the certificate is invalid (I guess because localhost does not match godestalbin.ga of the certificate). I am able to display the details of the certificate (see screen copy).
I also take a look at the analysis given by : https://check-your-website.server-daten.de/?q=godestalbin.ga
https://godestalbin.ga/
88.127.87.207
Http-Status: -4
SendFailure - The underlying connection was closed: An unexpected error occurred on a send.
You generated certbot SSL with domain : www.godestalbin.com
sudo certbot certonly --webroot -w /home/pi/webapp01 -d godestalbin.com -d www.godestalbin.com
But you configured nginx with server_name godestalbin.ga www.godestalbin.ga;
Please correct them as same domain only.

Gitlab ssl in subdomain validation failed

I want to install gitlab in my nginx server.
I follow this instruction for the install.
gitlab-ctl reconfigure give me :
There was an error running gitlab-ctl reconfigure:
letsencrypt_certificate[gitlab.domain.dev] (letsencrypt::http_authorization line 5) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 25) had an error: RuntimeError: ruby_block[create certificate for gitlab.domain.dev] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [gitlab.domain.dev] Validation failed, unable to request certificate
I use :
Debian 8
Nginx
My firewall allow 443 & 80 (i have one site in http and one in https)
I have access to sudo (or root)
apt install ca-certificates curl openssh-server postfix
I try :
Create subdomaine gitlab.domain.dev in my dns
Create SSL cert. for this domain with certbot
At this step the subdomain is ok
Install gitlab whit EXTERNAL_URL="https://gitlab.domain.dev" apt-get install gitlab-ee
At this step gitlab.domain.dev return nothing
I test to edit the config file (nano /etc/gitlab/gitlab.rb) like this :
nginx['ssl_certificate'] = "/etc/letsencrypt/live/gitlab.domain.dev/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/gitlab.domain.dev/privkey.pem"
and run gitlab-ctl reconfigure
and catch the error
i try this too
I don't understand why i said to tell gitlab to use my ssl certificates already created and how to make my subdomain give gitlab.
My nginx subdomain conf file :
# the nginx server instance
server {
server_name gitlab.domain.dev;
root /var/www/gitlab.domain.dev;
index index.html index.htm index.nginx-debian.html;
access_log /var/log/nginx/gitlab.domain.dev.log;
location / {
try_files $uri $uri/ =404;
}
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/gitlab.domain.dev/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/gitlab.domain.dev/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 = gitlab.domain.dev) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name gitlab.domain.dev;
return 404; # managed by Certbot
}
update 1
I try :
convert .pem file to .key and .crt whit :
openssl x509 -outform der -in your-cert.pem -out your-cert.crt
openssl pkey -in privkey.pem -out foo.key
change value of gitlab config file nano /etc/gitlab/gitlab.rb to :
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.domain.dev.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.domain.dev.key"
reconfigure :
There was an error running gitlab-ctl reconfigure:
letsencrypt_certificate[gitlab.domain.dev] (letsencrypt::http_authorization line 5) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 25) had an error: RuntimeError: ruby_block[create certificate for gitlab.domain.dev] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [gitlab.domain.dev] Validation failed, unable to request certificate
The setting letsencrypt['enable'] = false used to have a default value set to false but later versions of GitLab changed the setting to true as a default. The change could break your server script leading to ssl errors such as the one in question.
For my case, I had self signed certificates stored in a specific folder and the default set to true interfered with fetching of self assigned certs. The problem got solved once i changed the setting to false
Info from official GitLab Docs:
"Caution: GitLab 12.1 or later will attempt to renew any Let’s Encrypt certificate. If you plan to use your own Let’s Encrypt certificate you must set letsencrypt['enable'] = false in /etc/gitlab/gitlab.rb to disable integration. Otherwise the certificate could be overwritten due to the renewal."

Resources