SSL-сертификат работает для домена, но не для порта Specifi c - PullRequest
Новая
       16

SSL-сертификат работает для домена, но не для порта Specifi c

0 голосов
/ 29 февраля 2020

У меня есть домен sub.example.com, который настроен и полностью функционирует на сервере Ubuntu. Я использовал Certbot для настройки домена с HTTPS, однако у меня также есть API, настроенные для доступа к указанному c порту этого домена, скажем 2500. Когда я получаю доступ к example.com, я вижу блокировку, которая говорит о безопасности сайта однако всякий раз, когда я go до example.com:2500/api/someAPI, API возвращает соответствующий результат, но без защиты сайта. Поскольку основной сайт безопасен, а местоположение доступа к API - нет, я не могу соответственно выполнять вызовы API, в результате чего net::ERR_SSL_PROTOCOL_ERROR.

Stack:

  1. VPS: Amazon EC2
  2. Поставщик SSL-сертификатов: Let's Encrypt (через Certbot)
  3. Сервер: Node.js (Express)
  4. WebApp: React
  5. Web Сервер: nginx

Мне удалось заставить его работать с использованием тех же точных технологий на другом VPS (DigitalOcean) и домене некоторое время go, но я не думаю, что когда-либо запускал в эту проблему.

nginx .conf: 

user www-data;
worker_processes 4;
pid /run/nginx.pid;

events {
        worker_connections 768;
        # multi_accept on;
}

http {
    ##
    # Basic Settings
    ##

    sendfile off;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;
    gzip_disable "msie6";

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # nginx-naxsi config
   # nginx-naxsi config
    ##
    # Uncomment it if you installed nginx-naxsi
    ##

    #include /etc/nginx/naxsi_core.rules;

    ##
    # nginx-passenger config
    ##
    # Uncomment it if you installed nginx-passenger
    ##

    #passenger_root /usr;
    #passenger_ruby /usr/bin/ruby;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Ответы [ 2 ]

0 голосов
/ 02 марта 2020

Мне удалось решить мою проблему. Оказывается, это не имеет ничего общего с конфигурацией nginx. Скорее, в моем файле node.js, который определяет и предоставляет API, мне нужно было включить HTTPS доступ. Для этого я добавил в свой код следующие строки: 

const https = require('https');

const httpsOptions = {
        cert: fs.readFileSync("/etc/letsencrypt/live/<domain>/fullchain.pem"),
        key: fs.readFileSync("/etc/letsencrypt/live/<domain>/privkey.pem")
}

https.createServer(httpsOptions, app).listen(port);

, где <domain> заменено доменным именем, на котором размещен API.

0 голосов
/ 29 февраля 2020

По умолчанию никакой другой порт, кроме порта 443, не использует безопасное соединение. Однако, если вы укажете сделать это (например, используя https://example.com: 2500 ), он должен безопасно подключиться. Если вы хотите, чтобы это делалось автоматически, вам необходимо настроить его в настройках приложения веб-сервера. Если вы знаете, какое приложение используется для размещения сервера (например, apache), и если у вас есть доступ для редактирования файлов конфигурации, вы сможете настроить его.

Редактировать: Извините, я не сделал Первоначально вижу, что вы пометили вопрос как nginx. Я не делал этого специально перед использованием nginx, но нашел этот учебник , который объясняет процесс. Внутри /etc/nginx/sites-available/example.com вы сможете изменить "listen 443 ssl"; "слушать 443, 2500 ссл;" для прослушивания на нескольких портах. Кроме того, вы также добавили бы return 301 https://$host$request_uri;, чтобы перенаправить соединения в защищенное соединение https (см. https://serversforhackers.com/c/redirect-http-to-https-nginx).

Надеюсь, это поможет!

...