Nginx serves different website (on the same sever) when using HTTPS - ssl

I have several websites hosted on the same sever. To simplify I have just 2 (http-only.com and https.com) and using nginx to handle requests.
One has SSL enabled. And another doesn't. I noticed links like this in Google Search Console http-only.com/https_server_path and when accessing an http-only.com server with https protocol I get requests served by an https.com server instead.
https.com:
server {
listen 443 ssl;
server_name https.com;
ssl on;
}
only-http.com:
server {
listen 80;
server_name only-http.com;
}
I think I should define something like a default ssl server to handle ssl for http.com, but don't know how to do it properly. I guess nginx should redirect https request to an http url if corresponding server doesn't handle https. Or maybe there is a better solution?

Related

SSL for pointed domains

I have an app that is "multi-domain", Other domain just have to point to the IP address to run on my app on the web-server.
Using letsencrypt, I have also generated SSL for those pointed domain using "HTTP" challenges.
Now, my problem is - how do I tell my webserver to read that generated SSL files for the pointed domain.
They are not hosted on my server with config settings. They are just pointed with the IP address to my App and My app renders the content based on a domain name.
I am using VestaCP to manage server, domain, and email
Pointed domains have no config file on my server. They work on the web-application level.
How do I set https for that pointed domain? On a note, I already have valid SSL files - just not sure, where to post or point them, since there is no config.
Can they be kept using "htaccess" or at a web-application level?
E.g, My app runs at "http://example.com" and shows content for example.com, and for the second domain that is pointed to my server "http://anotherExample.com" - my app shows the content for "anotherExample.com" and so on and so forth. "example.com" is hosted on my server with Nginx and apache config, so SSL is set. But anotherExample.com is not hosted on server level but only at the app level - now, where do I set SSL for it? I have already successfully generated SSL using letsencrypt with HTTP challenge.
Update: I run a platform like Blogspot.com Multi-Domain blogs - How to serve SSL for pointed domain?
Thanks
I don't think what you want is directly possible. From your question, I think you are creating multiple A records which points to your application IP address, from which your application decides what data to serve.
So what you have to do is to get SSL certificate for each and every domain you want to serve. Then configure the web server to send the corresponding certificate. This can be done easily with most web servers. Eg: On nginx
server {
listen *:443 ssl;
server_name domain1.com;
ssl_certificate /path/to/domain1.crt;
ssl_certificate_key /path/to/domain1.key;
...
}
server {
listen *:443 ssl;
server_name domain2.com;
ssl_certificate /path/to/domain2.crt;
ssl_certificate_key /path/to/domain2.key;
...
}
Incase you are serving on different subdomains like domain1.example.com and domain2.example.com, then you could get a wildcard certificate which will do the trick.

Nginx reverse proxy to https location causes ssl_error_rx_record_too_long

ttI am adding an nginx reverse proxy in front of my existing nextcloudpi server in order to be able to route traffic to different servers in my network depending to the domain that is used. Currently the nextcloudpi server is the only one running, so all traffic is directly routed to it.
The server is only accessible via https and letsencrypt handles the certifactes on the nextcloudpi server.
In order to route traffic from my reverse proxy to the nextcloudpi server via https, I have set up the default.conf file to look like this:
server {
listen 443;
listen [::]:443;
server_name <my-public-url>;
location / {
proxy_pass https://<hostname-of-my-nextcloudpi-server>;
}
}
Unfortunately that doesn't work. Firefox returns SSL_ERROR_RX_RECORD_TOO_LONG and Chrome ERR_SSL_PROTOCOL_ERROR
I have also not seen anywhere where traffic is proxied to a https location. I am aware that in my internal network I can and should just route to the target location on port 80 but since the server is already set up to use https I want to keep it that way.
Thanks for your help

nginx 301 redirect not working for 443 ssl, why..?

I'm trying to redirect from an old domain to a new one.
The old domain used to have an SSL cert, but it doesn't any more.
So I need to 301 redirect these:
http://olddomain.co.uk
http://www.olddomain.co.uk
https://olddomain.co.uk
https://www.olddomain.co.uk
All to: https://www.newdomain.co.uk
This is my config:
server {
listen 80;
listen 443 ssl;
server_name olddomain.co.uk www.olddomain.co.uk;
return 301 https://www.newdomain.co.uk;
}
I'm using http://www.redirect-checker.org to test.
Both of the http URL's redirect fine, however the https URL's are not found at all, as if this server directive doesn't catch the https URL's.
Is that because I need an SSL cert even though I'm not serving anything..?
Is an SSL cert still needed, just to redirect..?
If not, why would this not work..?
EDIT
To be clear, I don't see cert errors, Chrome says "This site can't be reached", it does't say anything about a cert. redirect-checker.org says "no URLs found".
EDIT 2
I've found another .conf file, which is working (all 4 url's, inc 2 https, redirecting, without a cert installed). This is copy-pasted:
server {
listen 80;
listen 443 ssl;
server_name thepreventduty.com www.thepreventduty.com;
return 301 $scheme://www.thepreventduty.co.uk$request_uri;
}
These all redirect:
http://thepreventduty.com
http://www.thepreventduty.com
https://thepreventduty.com
https://www.thepreventduty.com
To https://www.thepreventduty.co.uk, and I don't have an ssl cert for thepreventduty.com.
You can see if works here: http://www.redirect-checker.org/
When I add another .conf for another domain (I'm using include websites/*.conf; in nginx.conf), exact same server directive, just the domain names changed - it doesn't work!
Why..?
HTTPS connection means HTTP connections in SSL-session.
For establishing SSL-session you need certificate and key.
From official site of nginx:
To configure an HTTPS server, the ssl parameter must be enabled on listening sockets in the server block, and the locations of the server certificate and private key files should be specified
So, you need specify locations of certificate and key.
In case of incorrect SSL you will get cert error before redirect.
I recommend you use acme.sh for getting valid certificate and key.
At first, you need temporary disable redirects and specify root directory of old domain.
Then follow instruction:
https://github.com/Neilpang/acme.sh
Once it is done, enable redirect back.

How to make nginx passthrough on 443 and redirect 80 to 443?

I have a winstone server (Jenkins) listening on 8443.
Jenkins has a valid cert, and Jenkins is doing the cert termination successfully:
JENKINS_ARGS="--httpPort=-1 --httpsKeyStore=/secure/jenkins.keystore --httpsKeyStorePassword=MY_PASSWORD --httpsPort=8443"
The only problem is that users now have to go:
https://example.com:8443
I don't want that port number in the URL.
I want:
https://example.com:8443 -> https://example.com
https://example.com -> https://example.com
http://example.com -> https://example.com
So I figure I'll run nginx on the same instance that is running Jenkins.
So my question is:
Do I have to reconfigure jenkins to NOT do cert termination so that nginx does it only?
Can nginx redirect 80 and 443 to localhost:8443 without a cert (Since Jenkins is doing cert termination)?
Do BOTH nginx AND Jenkins need to do cert termination?
Sorry for those similar questions.
I'm pretty sure an AWS ELB cannot replace what nginx is doing here, but I thought I'd throw it out there, in case an ELB can solve this for me too.
1) No, you can have Nginx Stream the connection directly to the Jenkins using the Stream Module.
Do note this was added in 1.9.0 but is not part of the default build so you might have to build it yourself.
It works a lot like an http server block but you have to set it up outside of the http block.
stream {
upstream jenkins_server {
server jenkins:443;
}
server {
listen 443;
proxy_pass jenkins_server;
}
}
2) You do not need a cert on nginx but you should have a http server block for port 80 that does a 301 to the 443 stream talked about in answer part 1.
server {
listen 80;
server_name your_server_name_here;
return 301 https://$host$request_uri;
}
3) No, you don't as you can use the nginx stream to passthru the ssl from the client to the Jenkins server.

Difference HTTP Redirect vs Reverse Proxy in NGINX

I'm having some difficulty in understanding the difference between reverse proxy (i.e. using proxy_pass directive with a given upstream server) and a 301 permanent redirect. How are they similar/different?
Reverse Proxy
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com:8080;
}
server {
location / {
proxy_pass http://backend;
}
}
HHTP Redirect
Apache Example: http://www.inmotionhosting.com/support/website/htaccess/redirect-without-changing-url
NGINX example:
server {
listen 80;
server_name domain1.com;
return 301 $scheme://domain2.com$request_uri;
}
Hence, it seems that both approaches have no difference from an end-user perspective. I want to ensure efficient bandwidth usage, while utilizing SSL. Currently, the app server uses its own self-signed SSL certificate with Nginx. What is the recommended approach for redirecting users from a website hosted by a standard web hosting company (hostgator, godaddy, etc.) to a separate server app server?
With a redirect the server tells the client to look elsewhere for the resource. The client will be aware of this new location. The new location must be reachable from the client.
A reverse proxy instead forwards the request of the client to some other location itself and sends the response from this location back to the client. This means that the client is not aware of the new location and that the new location does not need to be directly reachable by the client.