LINUX.ORG.RU

Nginx В режиме реверс прокси отдаёт не тот сертификат

 


0

2

Уважаемые форумчане!

Прошу помощи в настройке реверс прокси. Имеется вот такая структура сети: internet - mikrotik - nginx - sites1, sites2, sites 3, etc

80 и 443 порт на микротике проброшены на машину с nginx nginx в зависимости от днс имени перебрасывает дальше на нужный сайт/сервис.

С 80 портом всё отлично, а вот с 443 какая-то беда.

Почему-то одному сайту отдаётся сертификат другого.

Вот конфиги:

site 1

server {
        listen 80;
        server_name site1;
        return 301 https://$host$request_uri;
        }

server {
        listen 443 ssl;
        server_name site1;
        ssl_certificate /etc/letsencrypt/live/site1/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/site1/privkey.pem;
        location ~ /.well-known {
            allow all;
        }

        location / {
            proxy_pass https://10.7.2.78:443;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_read_timeout      120;
            proxy_connect_timeout   120;
        }
}

site2

server {
    server_name             site2;
    listen                  443 ssl;
    ssl                     on;
    ssl_certificate         /etc/nginx/ssl-staffcop/server.crt;
    ssl_certificate_key     /etc/nginx/ssl-staffcop/server.key;
    ssl_client_certificate  /etc/nginx/ssl-staffcop/client.crt;
    ssl_verify_depth        2;
    ssl_verify_client       optional;
    client_max_body_size 1G;

    access_log /var/log/staffcop/https.access.log;
    error_log /var/log/staffcop/https.error.log;

    keepalive_timeout       70;

    location /CA.crt {
        alias /etc/nginx/ssl-staffcop/server.crt;
    }

    location /ROOT.crt {
        alias /etc/nginx/ssl-staffcop/ROOT.crt;
    }

    location /favicon.ico {
        alias /usr/share/staffcop/static/favicon.ico;
    }

    location /static/ {
     alias /usr/share/staffcop/static/;
    }

    location ~* /agent-.*\.msi {
        alias /usr/share/staffcop/static/agent.msi;
    }

    location /media/ {
        alias /var/lib/staffcop/upload/;
        error_page 403 404 @error_image;
    }

    location /files/ {
        auth_basic           "File storage";
        auth_basic_user_file  /usr/share/staffcop/htpasswd;
    }

    location @error_image {
       rewrite .*_.png /thumb/$1;
       rewrite .* /static/img/default.ico;
    }

    location /media/admin/ {
        alias /usr/share/staffcop/django/contrib/admin/static/admin/;
    }

    location / {

        uwsgi_param QUERY_STRING        $query_string;
        uwsgi_param REQUEST_METHOD      $request_method;
        uwsgi_param CONTENT_TYPE        $content_type;
        uwsgi_param CONTENT_LENGTH      $content_length;

        uwsgi_param REQUEST_URI         $request_uri;
        uwsgi_param PATH_INFO           $document_uri;
        uwsgi_param DOCUMENT_ROOT       $document_root;
        uwsgi_param SERVER_PROTOCOL     $server_protocol;
        uwsgi_param UWSGI_SCHEME        $scheme;

        uwsgi_param REMOTE_ADDR     $remote_addr;
        uwsgi_param REMOTE_PORT     $remote_port;
        uwsgi_param SERVER_PORT     $server_port;
        uwsgi_param SERVER_NAME     $server_name;

        uwsgi_param HTTPS           $https if_not_empty;

        uwsgi_param   VERIFIED  $ssl_client_verify;
        uwsgi_param   DN            $ssl_client_s_dn;

        send_timeout 3600;
        uwsgi_read_timeout 3600;
        uwsgi_buffering off;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Sec-WebSocket-Key $http_sec_websocket_key;
        uwsgi_pass 10.7.2.49:3000;
    }

    location /staffcop {
           uwsgi_param QUERY_STRING        $query_string;
            uwsgi_param REQUEST_METHOD      $request_method;
            uwsgi_param CONTENT_TYPE        $content_type;
            uwsgi_param CONTENT_LENGTH      $content_length;

            uwsgi_param REQUEST_URI         $request_uri;
            uwsgi_param PATH_INFO           $document_uri;
            uwsgi_param DOCUMENT_ROOT       $document_root;
            uwsgi_param SERVER_PROTOCOL     $server_protocol;
            uwsgi_param UWSGI_SCHEME        $scheme;

            uwsgi_param REMOTE_ADDR     $remote_addr;
            uwsgi_param REMOTE_PORT     $remote_port;
            uwsgi_param SERVER_PORT     $server_port;
            uwsgi_param SERVER_NAME     $server_name;

            uwsgi_param HTTPS           $https if_not_empty;
            uwsgi_param   VERIFIED  $ssl_client_verify;
            uwsgi_param   DN            $ssl_client_s_dn;

            send_timeout 3600;
            uwsgi_read_timeout 3600;
            uwsgi_buffering off;

            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Sec-WebSocket-Key $http_sec_websocket_key;
            uwsgi_pass 10.7.2.49:3001;

    }

}

staffcop (site2) программа корп мониторинга. так вот по логам агента установленного на клиенте видно что nginx почему-то отдаёт сертификат от site1 Хотя параметр server_name установлен в обоих конфигах.

Прошу помочь в настройке.

На одном ip:port может висеть ровно один сертификат

Потому, что сначала устанавливается SSL/TLS соединение, а уже потом внутри защищённого соединения клиент шлёт запрос, из которого nginx определяет необходимый сайт

ЕМНИП, существует какое-то расширение TLS, которое позволит иметь несколько разных сертификатов на одном порту, но работать оно будет исключительно с TLS и не со всеми клиентами. Подробности не помню, гуглить лень ;)

router ★★★★★ ()
Ответ на: комментарий от router

Как же у меня сайты с разными сертификатами на одном ip и порту висят и ничего не путается ?

bdfy ★★★★ ()
Ответ на: комментарий от router

SNI, и не поддерживают его только IE6 и несколько столь-же актуальных клиентов. Хотя нельзя исключать что тут как-раз такой клиент. Можно проверить какой сертификат отдаётся при запросе curl-ом (curl -v https://domain.com/ > /dev/null), если curl-у отдаётся правильный сертификат, а той софтене неверный, значит трабла с SNI скорее всего. Тогда нужно выносить этот сервис на отдельный ip:port или обучать клиента SNI

MrClon ★★★★★ ()
Ответ на: комментарий от bdfy

Ты — счастливый человек работающий в среде где IE6 это страшилка которой аксакалы пугают джуниоров, и где нет софта двадцатилетней выдержки. Впрочем как и я. Хорошо быть нами. А вот роутером быть, похоже, плохо (:

MrClon ★★★★★ ()
Ответ на: комментарий от router

На одном ip:port может висеть ровно один сертификат

4.2

Даже если не говорить о SNI, то сертификатов может висеть сколько угодно и на сколько угодно сайтов. Единственное что надо учесть - для сайтов на одном IP - одинаковый приватный ключ.

BaBL ★★★★★ ()

Вангую что это из-за общей секции server, которая слушает 80 порт. Попробуй добавить аналагичную для site2.

Deleted ()

для сайтов на одном IP - одинаковый приватный ключ.

Это ССЗБ какое-то, тем более если это разные сайты и не твои.
Алсо, начиная с nginx 1.11 можно сразу и ecdsa и rsa сертификаты на одном сайте для клиентов отдавать.
По сабжу grep'ай по всем конфигам по названию сертификата, который отдается за место нужного. Наверняка где-то описался просто или сделал лишнюю секцию с server, когда копировал с другого сайта. Я по этой причине стал каждый ключ/сертификат по названию servername наименовать, потому-что когда их стало больше 50, просто легко на автомате название другого сертификата вписать. N 80й порт лучше вообще не указывать, он по дефолту будет, особенно если используешь reuseport.

anonymous_sama ★★★★★ ()
Последнее исправление: anonymous_sama (всего исправлений: 1)
Ответ на: комментарий от MrClon

Действительно, оказалось что агент не поддерживает SNI. Обратимся к производителю, ну или выносить на отдельный порт.

djfroggy ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.