3

Yes, this is something of a duplicate to this question, however, according to the ngnx document "Configuring HTTPS servers" (the section "Single HTTPS Server"), this limitation no longer exists, and the answer to that question is no longer valid.

From the link above:

Prior to 0.7.14 SSL could not be enabled selectively for individual listening sockets, as shown above. SSL could only be enabled for the entire server using the ssl directive, making it impossible to set up a single HTTP/HTTPS server. The ssl parameter of the listen directive was added to solve this issue. The use of the ssl directive in modern versions is thus discouraged.

However, with the server block set up as prescribed in that doc:

server {
        listen *:80;
        listen 443 ssl;

        server_name  example.com *.example.com;
[...]

... nginx will still serve content from example.com when a request for https://example.net is made.

I understand that the SSL is served before the HTTP request, but there has to be some way to prevent the server from responding to SSL requests that do not have a valid SSL certificate associated with them.

Any insight on this is greatly appreciated.

rm-vanda
  • 257
  • 8
  • 18

3 Answers3

4

there has to be some way to prevent the server from responding to SSL requests that do not have a valid SSL associated with them

Well, kinda. Since you have multiple sites running on the same IP, a user attempting an SSL connection to that IP for any of the sites will always establish its SSL connection (and potentially get a certificate error if they're pointing to a hostname that isn't covered by the cert).

All you can do to prevent this is to not have SSL listening on that IP (running your SSL stuff on different addresses).

If you're ok with them getting an SSL connection with that potential error, then you have options after; instead of getting the content from the SSL-enabled server, you could have a default of them either getting a 403 error or a redirect to the http listener for the hostname they sent the request to - would one of those options make sense for your system?

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • The server actually has four IPs, so it would be totally practical to have the site with the SSL on its own IP. So, I imagine I would change the `listen: 443 ssl;` to `listen: xxx.xxx.xxx.xxx:443;` -?- I currently have a prepended PHP script that says something to the effect of `if $_SERVER['HTTPS'] && $host != 'sslDomain.com' { header("Location: $request_uri"); }` – rm-vanda Jun 18 '14 at 17:17
  • 1
    @rm-vanda Ok! Then what you can do is to change the `listen` for both the 80 and 443 hosts for the SSL enabled domain to be explicitly listening on an IP that the non-SSL domains aren't using. – Shane Madden Jun 18 '14 at 17:18
  • I edited my previous comment -- And great -! I'll try that solution as soon as I get back from lunch, but perhaps you will tell me what effect that will have if someone requests `https://someNonSSLDomain.com` -? I'd really like to avoid the browser-warning about SSLs not matching up altogether -- – rm-vanda Jun 18 '14 at 17:21
  • 1
    @rm-vanda Once you change the SSL site to listen on a different IP, there will be nothing to connect to on port 443 of the address the non-SSL domain resolves to. The user will get an error about being unable to connect to the server. – Shane Madden Jun 18 '14 at 17:25
  • Unfortunately, this doesn't seem to be the case --- Changing the `listen` directive to `listen xxx.xxx.xxx.xxx:443 ssl` had no effect on the behavior -- requesting https://otherDomains.com still resulted in the browser warning, serving the certificate of `theSSL-edDomain.com` =/ – rm-vanda Jun 18 '14 at 20:02
  • 1
    @rm-vanda Is anything else configured to listen on 443? Can you check the output of `lsof -i -P -n | grep 443` for what's listening on what address? – Shane Madden Jun 18 '14 at 20:16
  • Well, I ran `grep -R ssl` on the vhosts directory, and the only thing that showed up was the ISPConfig vhost that listens on its own port... – rm-vanda Jun 18 '14 at 20:19
  • Five Nginx processes show up with that command, each listening on `*:443` --- I reloaded the nginx conf, though, so -- what would cause that? – rm-vanda Jun 18 '14 at 20:21
  • 1
    @rm-vanda Try doing a full restart of the service, it might not update its listening addresses with just the reload. – Shane Madden Jun 18 '14 at 20:22
  • OK, `reload` didnt do it, but `restart` did --- OK, problem solved -!! Thank you very much - ! That was about to be a very serious issue --- – rm-vanda Jun 18 '14 at 20:22
  • @rm-vanda Great, glad to help! – Shane Madden Jun 18 '14 at 20:23
  • I'll do my best to pay it forward - ! – rm-vanda Jun 18 '14 at 20:25
1

if there is no ssl for that domain you will get browser ssl error, and closed connection...
Error code: ERR_SPDY_PROTOCOL_ERROR

    server {
        listen 80;
        return 444;
    }

    server {
        listen 443;
        ssl_certificate     /etc/ssl/my.crt;
        ssl_certificate_key /etc/ssl/my.key;
        return 444;
    }

## no SSL domain
server {
        listen 80;
        server_name  domain.com *.domain.com;
}

## SSL domain
    server {
            listen 80;
            listen 443 spdy ssl;
            server_name  SSLdomain.com *.SSLdomain.com;

    }
ADM
  • 1,373
  • 12
  • 16
-2

Let's redirect all another domain to one folder, in this folder create index file with meta robot is noindex

server {
    listen   443;
    server_name yourdomainusessl.com;
    ssl on; 
    ssl_certificate      /etc/nginx/conf.d/ssl/....crt;
    ssl_certificate_key  /etc/nginx/conf.d/ssl/....key;
    ssl_trusted_certificate  /etc/nginx/conf.d/ssl/....crt; 
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;
    if ($host = 'yourdomainusessl.com' ) {
         return 301 https://www.yourdomainusessl.com$request_uri;
    }
    if ($host !~* 'yourdomainusessl.com' ) {
         return 301 http://somewhereyouwant.com;
    }
}
Lão Còi
  • 141
  • 1
  • 4