I have a webserver running Nginx. I have successfully managed to get SSL working with a Let's Encrypt Certificate, but whenever I connect to HTTPS, the webserver serves me the default index page for Nginx (this). I have been unable to find where this is coming from.
This is the server block I have in the config for the SSL:
##
# SSL Settings
##
ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers on;
server {
listen 139.59.163.228:443 ssl;
server_name sulphate.me www.sulphate.me;
keepalive_timeout 75 75;
ssl_certificate /etc/ssl/certs/sites/sulphate.me.crt;
ssl_certificate_key /etc/ssl/private/sites/sulphate.me.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
}
I want to be able to redirect it to where HTTP is served from (/var/www/html/), and also find out where this is coming from, since I haven't touched any location blocks.
Thanks in advance!
Related
I have a test server with docker compose + nginx + certbot (get certificates from let's encript).
Nginx config:
server {
listen [::]:80;
listen 80;
server_name testdomain.com www.testdomain.com;
location ~ /.well-known/acme-challenge {
allow all;
root /var/www/certbot;
}
server_tokens off;
# redirect http to https www
return 301 https://www.testdomain.com$request_uri;
}
#other server configs
certbot says in logs:
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: testdomain.com
Type: connection
Detail: Fetching http://testdomain.com/.well-known/acme-challenge/vXDwOBgMA9DEq2IvxqUxxxxxxxxxx: Connection refused
Domain: www.testdomain.com
Type: connection
Detail: Fetching http://www.testdomain.com/.well-known/acme-challenge/shRZla5V7iFXB6D__xxxxx: Connection refused
Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
I've put a temporary file to the /.well-known/acme-challenge/(http) but it can't be downloaded (if I try to open mydomain.com/index.html - works fine, but redirects to https version).
I think that problem is in the fact, my config tryes to redirect certbot requests to https, too. Do you have any idea how to get /.well-known/acme-challenge/ out of https rules?
I've found solution:
server {
listen [::]:80;
listen 80;
server_name testdomain.com www.testdomain.com;
location ^~ /.well-known/acme-challenge {
allow all;
root /var/www/certbot;
}
location / {
# redirect http to https www
return 301 https://www.testdomain.com$request_uri;
}
server_tokens off;
}
Now everithing is redirecting to https excluding content of this folder /.well-known/acme-challenge
I am trying to setup nginx mail proxy Gmail smtp server. Nginx server runs on docker.
During tests, I use openssl s_client -connect mail.localhost.com:12465 -starttls smtp (ports are different from config for port availability reasons).
Openssl connects successfully and I manage to get EHLO and run AUTH LOGIN. Still, I receive error 502 5.5.1 Unrecognized command. u6sm12628547ejn.14 - gsmtp. Same message appears when less secure apps security is on in account.
Running command above directly to smpt.gmail.com works great, and error is displayed correctly if less secure apps security is not allowed.
Current nginx.conf is below.
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 9101;
server_name localhost;
location /smtpauthssl {
if ($http_auth_user ~* "(?<=#)(\S+$)" ) {
set $domain $1;
}
set $smtp_port '587';
add_header Auth-Status "OK";
add_header Auth-Port $smtp_port;
add_header Auth-Server "108.177.119.108";
return 200;
}
location = / {
return 403;
}
}
}
mail {
server_name mail.mydomain.com;
auth_http localhost:9101/smtpauthssl;
proxy_pass_error_message on;
proxy_smtp_auth on;
xclient on;
ssl_certificate /etc/ssl/certs/certificate.pem;
ssl_certificate_key /etc/ssl/certs/key.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
server {
listen 587 ssl;
protocol smtp;
smtp_auth login plain cram-md5;
}
}
My assumption is that something with logon is not passed to Gmail SMTP, but not sure what.
One more thing, what does Auth-Server header should contain, FQDN or IP address?
Yesterday I have changed my domain name hat was foobar.tk and it was running over https. For now, on my new domain foobar.eu I does not have ssl.
I have succeed with redireting using CNAME records while I am not using https, but somehow I cannot redirect https://www.example.tk to http://www.example.eu Chrome says that connection was resset. Firefox says that content cannot be validated,...
For redirection I am using these lines:
server {
listen 443; (note: i have tried with *:443, *:443 ssl, 443 ssl)
server_name www.example.tk; (i have tried with orwithout www.)
return 301 http://www.example.eu$request_uri; (i have tried to redir to $host also where then cname will handle the issue)
}
What works:
http://www.example.tk -> http://www.example.eu using CNAME (and all other subdomains)
What is not working:
https://www.example.tk -> http://www.example.eu
I still can certificates backed-up, so if it can help in some way please tell me.
Thank you
When setting up SSL on Nginx you should use ssl_certificate and ssl_certificate_key directives.
server {
listen 443 ssl;
server_name www.example.tk;
ssl_certificate /path/to/certificate; #.crt, .cert, .cer, or .pem file
ssl_certificate_key /path/to/private/key;
return 301 http://www.example.eu$request_uri;
}
These two files you can get from your Certificate Authority.
Also you should add ssl parameter to listen directive.
My site will run exclusively at https://www.example.net
I have a server block for port 80 which returns a 301 to https://www.example.net, which works as expected.
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name www.example.net example.net;
return 301 https://www.example.net$request_uri;
}
In terms of doing the same on port 443, I read somewhere that certificate negotiation happens before all else, and so this 443 redirect block needs to have all of the certificate details. My question is, how much of that stuff needs to be repeated in this block? Currently I have the following:
server {
listen 443 ssl;
listen [::]:443 ssl;
# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /etc/ssl/certs/x.example.net.pem;
ssl_certificate_key /etc/ssl/private/example.net.key;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /etc/ssl/certs/dhparam.pem;
# intermediate configuration. tweak to your needs.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /etc/ssl/certs/x.example.net.pem;
resolver 8.8.8.8 8.8.4.4;
server_name example.net;
return 301 https://www.example.net$request_uri;
}
Should I be setting Strict-Transport-Security headers? OSCP stapling? ssl_ciphers? Just for a redirect?
Many thanks!
Edited to add: that my certificate is valid on both www and non-www, and so this is not an effort to avoid an ugly certificate mismatch warning.
The following should be in an http block in nginx.conf so it applies to all SSL server configs and avoids this bug:
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /etc/ssl/certs/dhparam.pem;
# intermediate configuration. tweak to your needs.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
The rest should remain.
I have an Nginx server set up on an Ubuntu VPS with multiple hosts (1 IP). Previously, 1 host had certificates set up and NO redirecting (http allowed) and 1 host had certificates and forced HTTPS via 301. Now that I am attempting to force all of my hosts on SSL and force HTTPS, I am seeing that Nginx is dropping handshakes when I have more than 1 vhost with 301 directives. In particular, the error I am seeing is:
[error] 12370#0: *30 no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: (removed), server: 0.0.0.0:443
The issue definitely seems to be with my 301's, because if I exclude them I do not have an issue. What's the best way I can force HTTPS and non-www in my server blocks?
All of my vhosts are in /etc/nginx/conf.d, along with ssl.conf (listed below). I can provide nginx.conf if requested, but I didn't see anything that would seem useful in there.
example1.conf
server {
server_name www.example1.com example1.com;
return 301 https://example1.com$request_uri;
}
server {
listen 443;
server_name www.example1.com
return 301 https://example1.com$request_uri;
}
server {
listen 443 ssl;
server_name example1.com;
ssl_certificate /etc/letsencrypt/live/example1.com/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/example1.com/privkey.pem;
root /var/www/example1.com;
location / {
try_files $uri $uri/ $uri.html =404;
}
access_log /var/log/nginx/example1.com.access.log;
error_log /var/log/nginx/example1.com.error.log;
}
example2.conf
same as example1.conf (except with example2.com instead of example1.com)
ssl.conf
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
# Perfect Forward Security
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS +RC4 RC4";
# HSTS
add_header Strict-Transport-Security max-age=31536000;
Pointing out other obvious errors is also appreciated.
Solved (at least for now) by removing
server {
listen 443;
server_name www.example1.com
return 301 https://example1.com$request_uri;
}
It seems that since there's no cert specified, this block would get hit for all HTTPS requests and then the connection would get dropped.