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!
Related
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.
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.
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."
I'm trying to deploy a Django project to a AWS Lightsail server.
I followed mostly this tutorial. I added some SSL protocols for additional security.
This projects runs perfectly on my Ubuntu 18.04 VirtualBox with exact same setup and exact same components, same SSL protocols. However on the Lightsail it doesn't respond to the browser request. It will redirect me to https but then will die... I wasn't able to identify any errors in any of the logs. Which leaves me guessing
/etc/systemd/system/webrock.socket:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/webrock.sock
[Install]
WantedBy=sockets.target
/etc/systemd/system/webrock.service:
[Unit]
Description=gunicorn daemon
Requires=webrock.socket
After=network.target
[Service]
User=ubuntu
Group=www-data
WorkingDirectory=/home/ubuntu/django/webrock
ExecStart=/home/ubuntu/django/webrock/venv/bin/gunicorn \
--access-logfile - \
--workers 3 \
--bind unix:/run/webrock.sock \
core.wsgi:application
[Install]
WantedBy=multi-user.target
/etc/nginx/sites-available/webrock:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2 ipv6only=on;
include snippets/signed.conf; # path to certs
include snippets/params.conf; # cert related params
index index.html index.htm index.nginx-debian.html;
server_name mydomain.com www.mydomain.com; #changed this line by replacing domain name with dummy
location = /favicon.ico {access_log off; log_not_found off;}
location /static/ {
root /home/ubuntu/django/webrock;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/webrock.sock;
try_files $uri $uri/ =404;
}
}
server {
listen 80;
listen [::]:80;
server_name mydomain.com www.mydomain.com; #changed this line by replacing domain name with dummy
return 302 https://$server_name$request_uri;
}
I left the nginx default file alone. Now every time I visit the page by punching in the server IP, I see the nginx default page. When I use the domain name I get redirected to HTTPS, but then... nothing. I assume that there is some disruption between gunicorn and nginx, but I'm not experienced enough to troubleshoot there or solve to solve it.
As I mentioned above, exact the same setup runs flawless on the similar system in my VirtualBox.
I'm very thankful for suggestions and hints.
Update:
I disabled the redirect portion in nginx and made it listen to port 80. It worked. Now I'm trying to figure out how to introduce HTTP2 and port 443 back to the setup. BTW my ufw looks like this:
After two days banging my head against this issue here is the solution.
So Amazon Lightsail has an additional firewall in front of the UFW on the actual server.
You can access Lightsail firewall by clicking on...
Menue of your instance > Manage > Networking
You will see a summarized networking for your instance like IP addresses, Firewall, Loadbalancer. In that firewall you need to add an additional port (In my case HTTPS).
Why would they put an additional firewall in front of UFW beats me.
I've start certbot process with:
sudo certbot --nginx -d example.com -d www.example.com
but I forgot to add 'www.example.com' in 'servernam' nginx virtualsite for example.com
server {
(...)
server_name example.com www.example.com;
(...)
}
then i've got the certificate but not the auto complet process to config my nginx with ssl
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for examle.com
tls-sni-01 challenge for www.example.com
Cleaning up challenges
Cannot find a VirtualHost matching domain www.example.com. In order for Certbot to correctly perform the challenge please add a corresponding server_name directive to your nginx configuration: https://nginx.org/en/docs/http/server_names.html
IMPORTANT NOTES:
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
It's like I wrote just:
cerbot --certonly --standalone -d example.com
because I have just the certificate, now the config on nginx it's ok, i can lauch again the process and overwrite all the old values ? is there a problem with Let's Encrypt Certificate Authority , call again a new certificate for the same domain? what is the solution? delete all again, or complete the rest of process ( nginx config) by hand ?
It's possible with cerbot to launch again the ssl for domains already created. In my case when domains fails, and it's the first time you use certbot. Nginx config is changed but not totally , so when you try second time that will be complet and update nginx config. Certbot just update the config for the domain, and comment the old lines that it think are duplicated and inserting the new ones , addigng #manage by Certbod, so when you need to renovate your certificate Cerbot can change smartly the lines.
Example my nginx config ,with the first try, and second:
if ($scheme != "https") {
return 301 https://$host$request_uri;
} # managed by Certbot
# Redirect non-https traffic to https
# if ($scheme != "https") {
# return 301 https://$host$request_uri;
# } # managed by Certbot