I am facing a weird issue. I do not know if it is Nginx related or DNS related but here is the problem :
I have a domain that is fine, let's say foobar.com , SSL does not face any issue. Both www. and root domain work with HTTPS.
I have a second domain, let's say foobaz.net, I need to redirect it to foobar.com in every situations (both www. and root domains).
It does actually redirect, but when I try to access https://foobaz.net/ I get a HTTPS error/warning before being redirected to https://foobar.com/ after adding it the the SSL exceptions of Chrome (https://foobar.com/ SSL certificate is OK once I get past https://foobaz.net/ SSL warning).
I do not know if it is Nginx related or DNS related, any clue of what is happening here ?
Thanks in advance.
Any https connection checks the ssl certificate before proceeding to do what it needs to do in the server(in your case, a redirection). You may have a certificate for foobar.com, which is perfectly fine, but if you don't have a valid foobaz.com certificate. That's why the error shows up, foobaz is not "secure".
A https connection is secure if all the points between you and the endpoint are secure, not only the endpoint. If foobaz is not certified, that is a non-secure middle point on your connection, and that's why the warning happens.
Get a SSL certificate for foobaz too, and the whole connection will be secure.
Related
there a way to redirect or downgrade a https request
lets say i have example.com
if some one calls it with http:// example.com all fine
if some one calls it with httpS:// example.com all fine
now if some one try to reach it httpS:// 100.200.100.200 (eg. over its ip address)
he will get a Your connection is not private as i dont have a certificate for 100.200.100.200 or just a self signed
is there a way to redirect or downgrade the connection to http only
to be able to show some message to the client whit out the need for him to
interact with the Your connection is n... message ?
or is it prohibited for security reasons
and a browser either gets what https side he requests or nothing at all
You can get a valid certificate for an IP but it's really not common (see Is it possible to have SSL certificate for IP address, not domain name? )
Anyway, nobody will visits your website by the IP, so no need to worry about it
The certificate for example.com tells you that you really are communicating with them (and, because you know you want to visits example.com, it's fine) but the certificate for 100.200.100.200 tells you that you really are communicating with 100.200.100.200, but you can't be sure it's the same person as example.com, you have to be sure you get the right IP. DNS is probably more reliable...
I got several https://*.rest-service.mydomain.com. As the number of services increases, I feel managing SSL cert is costly. I bought a wildcard cert for *.mydomain.com.
Newly added services are placed under mydomain.com with a new wildcard cert and it works well. However, as always, legacy is an issue.
I still have a lot of https traffic to https://*.rest-service.mydomain.com, and its old cert is going to expire.
In this situation, is there any good approach to redirect legacy https traffics to the new one?
Since the client still knows only legacy endpoint https://*.rest-service.mydomain.com, can I redirect the client to the new server https://*.mydomain.com and handle the request as well?
I use nginx as a web server and ELB for a load balancer.
... and its old cert is going to expire.
While you can redirect from ssl to ssl (see the other answer) you still need to have a valid certificate for the host you redirect from. This means the redirection will stop working (or at least cause certificate validation errors) once the old cert expired. To fix this you need to renew the certificate.
Apart from that you must be sure that the services can actually deal with redirection. While a browser handles redirection in a transparent way for the user that is not necessary the case for applications using a REST API. These might expect to get the response directly and not a redirection which they have to follow and resubmit the REST request.
Try this regexp-ed server:
server {
server_name ~^(?P<subdomain>.+)\.rest-service\.mydomain\.com$;
listen 443 ssl;
return 301 https://$subdomain.mydomain.com$request_uri;
}
This is the scenario:
There is a valid SSL certificate configured in Apache for www.example.ac.za.
There is a parked domain of www.example.co.za without a valid SSL certificate.
To avoid having to purchase two certificates the client would like the .co.za to redirect to .ac.za. I understand (and have found) that this can not be done in the .htaccess as the presentation of the SSL certificate is done first.
Can one turn SSL off for .co.za but have it remain on for .ac.za? Would this resolve the problem?
Additional Info
These domains are configure in Apache as VirtualHosts with their own .conf and ssl.conf files.
Redirects are done to make sure the root of these domains end up at https://www.example.ac.za
Would appreciate some insight pls :)
Can one turn SSL off for .co.za but have it remain on for .ac.za? Would this resolve the problem?
You can remove the SSL vhost for .co.za so if someone attempts to go to https://www.example.co.za they'd get a site not found. But if you want anything to appear when they go to the https website for .co.za, then there must be something listening to the SSL port (443) that expects requests for the .co.za domain. And like you understand, in order to do that, you need a valid certificate unless you're ok with the security exception.
The other thing you can do is buy a single cert for both domains. There's nothing else you can do in the server/vhost configs. Doesn't matter if it's htaccess or not, a redirect happens after a successful SSL handshake.
I have a Debian server which is running a number of client sites. Most of these are not running SSL so accessing by HTTP is fine.
I have one customer with an SSL certificate and accessing their site via HTTPS is fine too.
The problem comes if you try to access one of the other sites with HTTPS you get directed to the other site that has the SSL certificate.
For instance, lets say we have the following sites on the server:
alpha.net
bravo.net
charlie.net (SSL)
delta.net
So as you can see, charlie is the only one with SSL, and irrespective of if you go to http charlie.net or https charlie.net, it works fine.
http to all the other sites is fine, but if you were to go to https alpha.net, it will initially come up with an Invalid Certificate error and let you continue but whilst it has alpha.net in the address bar, its actually showing the charlie.net site in the browser.
I have researched SNI and how if any other sites have SSL I'll need to put them all on specific IP addresses (something else I need to try to work out how to do as I have no idea) but I am not sure why this is happening or how I resolve it.
Has anyone else encountered this before and how did you get around it?
Many thanks,
Rob
This does not have anything to do with SNI, as you currently only have one HTTPS server. What happens, as you've stated in your comment, is that the alpha.net domain resolves to your server's IP. Your Apache server is set up to listen for requests on port 443 on this IP, and to serve the contents of charlie.net to these requests. (And the certificate error means that the browser noticed the discrepancy between the certificate's alleged domain name and the domain name used for the request.)
Redirecting from HTTPS to HTTP is probably more trouble that it's worth, since you would need valid certificates for each domain, lest you present your users with another security warning. This would entail creating virtual hosts for alpha.net:443 and so on, on an SNI capable server (i.e., later versions of Apache 2.2+ with openssl), and adding a redirection like so:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
Probably the easiest course for your problem is to use a different IP for charlie.net. With this setup, there would be no way for alpha.net (and so on) to display the contents of another site.
If you have multiple IPs on your server, use a unique one for the SSL site, all non-SSL sites share another IP.
Since SSL doesn't care what is the domain you are visiting, it only cares if the current domain is approved from the list of domains(Common Name) it gets from the Ip address.
I have an apache server with multiple named hosts all working fine for port 80 http traffic.
(A VPS with one unique IP address)
I have one domain that has a SSL certificate and that domain is configured to handle both http and https traffic.
However if someone accidentally adds https to the beginning of a none SSL configured URL I get a typical certificate warning error (expected) and then if the user accepts the error (depending on the browser) it displays the SSL site I have configured instead of the original non-ssl domain.
I've read up a bit about SNI, but I don't have certificates for each of the other domains and would rather the server either not respond to the SSL request on anything else but one specific domain or redirect to the http version of the site.
Suggestions please as to how I approach this.
Kind regards, Spencer
For security reasons, what you're trying to achieve cannot work.
The browser (which implements the mechanisms to check the certificate) cannot know whether the user typed https:// instead of http:// accidentally or intentionally. Since it's ultimately up to the users to check that https:// is used when they think it's required, browsers should simply perform the actions requested by the users.
A redirection from https:// to http:// should always start with a valid https:// connection. SNI won't help you much there if you can't have valid certificates for the initial connection.
Otherwise, it would be fair for browsers to assume there may be a MITM attack in progress. Typing in https:// explicitly (or using HSTS) is the only reliably mechanism against MITM tools like SSLstrip, which would otherwise be capable of downgrading (or preventing an upgrade from http:// to https://).