Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I created a GitLab instance on my server, let's call it git.domain1.tld. When I connect to https://git.domain1.tld it works fine. However, when I connect to https://domain2.tld, it shows the same content as https://git.domain1.tld when in fact I have no behavior defined for HTTPS on domain2.tld.

I'm not sure what to call this behavior so I've had trouble searching the Internet for solutions.


/etc/nginx/sites-available/domain2.tld:

server {
    listen 80 default_server;
    server_name domain2.tld www.domain2.tld;

    root /srv/domain2.tld/www/;
    index index.php index.html index.htm;

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
                include fastcgi_params;
        }
}

/etc/nginx/sites-available/gitlab:

# GITLAB
# Maintainer: @yin8086
# App Version: 4.1

# Modified from nginx http version
# Modified from http://blog.phusion.nl/2012/04/21/tutorial-setting-up-gitlab-on-debian-6/

# You need from run openssl to generate the ssl certificate.
# $ sudo openssl req -new -x509 -nodes -days 3560 -out gitlab.crt -keyout gitlab.key
# $ sudo chmod o-r gitlab.key

upstream gitlab {
  server unix:/home/git/gitlab/tmp/sockets/gitlab.socket;
}

# This is a normal HTTP host which redirects all traffic to the HTTPS host.
server {
    listen       80;
    server_name git.domain1.tld;
    server_tokens off;
    root /nowhere;
    rewrite ^ https://git.domain1.tld$request_uri permanent;
}

server {
    listen 443;
    server_name git.domain1.tld;
    server_tokens off;
    root /home/git/gitlab/public;

    ssl on;
    ssl_certificate /etc/nginx/conf/git-unified.crt;
    ssl_certificate_key /etc/nginx/conf/git.key;
    ssl_protocols  SSLv3 TLSv1;
    ssl_ciphers AES:HIGH:!ADH:!MD5;
    ssl_prefer_server_ciphers   on;

    # individual nginx logs for this gitlab vhost
    access_log  /var/log/nginx/gitlab_access.log;
    error_log   /var/log/nginx/gitlab_error.log;

    location / {
        # serve static files from defined root folder;.
        # @gitlab is a named location for the upstream fallback, see below
        try_files $uri $uri/index.html $uri.html @gitlab;
    }

    # if a file, which is not found in the root folder is requested,
    # then the proxy pass the request to the upsteam (gitlab unicorn)
    location @gitlab {
        proxy_read_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
        proxy_connect_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
        proxy_redirect     off;

        proxy_set_header   X-Forwarded-Proto https;
        proxy_set_header   X-Forwarded-Ssl   on;
        proxy_set_header   Host              $http_host;
        proxy_set_header   X-Real-IP         $remote_addr;

        proxy_pass http://gitlab;
    }
}
share|improve this question

2 Answers 2

Without SNI or a UCC certificate, this is how SSL works. One IP to one SSL certificate.

The reason for this is that the domain name being requested is part of the encrypted package, so nginx/Apache/etc. don't know which website to serve until after decryption... which is done by the default virtualhost for that domain.

share|improve this answer
    
I updated my answer with some of the configuration files for nginx. Maybe that will help. –  Alexsander Akers May 11 '13 at 0:15
    
Again, this is how SSL works. Any HTTPS traffic to the IP will be served the git.domain1.tld virtualhost's content. –  ceejayoz May 11 '13 at 1:28
    
Is it possible to turn off HTTPS for those other domains then? –  Alexsander Akers May 11 '13 at 1:30
    
And even still, I feel like the server_name should take care of that, no? –  Alexsander Akers May 11 '13 at 1:31
1  
No. You can get a second IP and put the SSL site on the second IP and the rest of the sites on the first IP. server_name doesn't take care of this because server_name can't be used when accessed over SSL - the server's name is encrypted in the request, so the web server can't decide what to do. –  ceejayoz May 11 '13 at 1:32

I was able to fix this issue with the following setup:


/etc/nginx/sites-available/default

server {
    listen [::]:80 default ipv6only=on;
    listen [::]:443 default ipv6only=on;
    ...
}

/etc/nginx/sites-available/domain2.tld

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name domain2.tld www.domain2.tld;
    server_tokens off;
    root /srv/pandamonia.us/www/;

    ssl_certificate /etc/nginx/conf/www-unified.crt;
    ssl_certificate_key /etc/nginx/conf/www.key;
    ssl_protocols  SSLv3 TLSv1;
    ssl_ciphers AES:HIGH:!ADH:!MD5;
    ssl_prefer_server_ciphers   on;

    ...
}

/etc/nginx/sites-available/gitlab

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name git.domain1.tld;
    server_tokens off;
    root /home/git/gitlab/public;

    if ($scheme != "https") {
        rewrite ^ https://git.domain1.tld$request_uri permanent;
    }

    ssl_certificate /etc/nginx/conf/git-unified.crt;
    ssl_certificate_key /etc/nginx/conf/git.key;
    ssl_protocols  SSLv3 TLSv1;
    ssl_ciphers AES:HIGH:!ADH:!MD5;
    ssl_prefer_server_ciphers   on;

    ...
}
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.