ELB для внутреннего сервера с использованием HTTPS с самозаверяющим сертификатом - PullRequest
Новая
       34

ELB для внутреннего сервера с использованием HTTPS с самозаверяющим сертификатом

0 голосов
/ 05 марта 2019

Я хочу настроить ELB, который использует HTTPS для связи с внутренними серверами.Я пытаюсь настроить проверку концепции с использованием одного внутреннего сервера, но не могу заставить ELB взаимодействовать с сервером.Я почти уверен, что это проблема с сертификатом, поскольку любая установка без SSL работает отлично.

Как я могу это настроить?Я попробовал различные предложения из нескольких ответов и сообщений в блоге, но не повезло.

Что я делаю сейчас, так это настройку самоподписанного сертификата с помощью следующих команд (от AWS ELB -> Backend Server overHTTPS с самоподписанным сертификатом ): 

$ openssl genrsa \
  -out /path/to/ssl.key 2048
$ openssl req \
  -sha256 \
  -new \
  -key /path/to/ssl.key \
  -out /path/to/ssl.csr
$ openssl x509 \
  -req \
  -days 365 \
  -in /path/to/ssl.csr \
  -signkey /path/to/ssl.key \
  -out /path/to/ssl.crt

Я пробовал несколько доменных имен при подписании, и я могу свернуться, используя их: 

curl https://[Public DNS, or private DNS or IP used to create the SSL crt]/status --cacert /path/to/ssl.crt

Есть ли домен/ IP / DNS запись, которую я должен использовать здесь?Я чувствую себя довольно хорошо, что curl работает по крайней мере.

В настоящее время моя конфигурация nginx (в файле с поддержкой сайта) выглядит следующим образом: 

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    ssl_certificate     /path/to/ssl.crt;
    ssl_certificate_key /path/to/ssl.key;

    server_name <dummy value of "_" or name used to make SSL certs>;
    client_max_body_size 20M;
    access_log  /var/log/nginx/access.log;
    error_log  /var/log/nginx/error.log;

    location / {
        proxy_pass         http://127.0.0.1:8000/;
        proxy_redirect     off;

        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

Это работает с приведенной выше командой curl.

Я пробовал классические и прикладные балансировщики нагрузки.Что касается классики, я попытался добавить содержимое ssl.crt - я не вижу подобной опции с балансировщиками нагрузки приложения, хотя я хотел бы использовать их, если это возможно, потому что они действительно могут легко пересылать HTTP-> HTTPS.В любом случае, ни классический, ни балансировщик нагрузки приложений не обмениваются данными с сервером.

Есть предложения, чего не хватает?Или как определить, чего не хватает?

1 Ответ

0 голосов
/ 21 марта 2019

Это было близко, всего несколько маленьких шагов пропущено.Я получил это, работая с ALB ELB.

Сначала я использовал скрипт, аналогичный описанному здесь: https://myopswork.com/how-to-do-end-to-end-encryption-of-data-in-transit-b-w-aws-alb-and-ec2-3b7fd917cddd

#!/bin/bash

DIR=$(dirname $0)

domain=$(uname -n)
echo "Generating SSL for $domain"
commonname="$domain"
country="US"
state="California"
locality="LA"
organization="My Inc."
organizationalunit="Org"
email="my@email.com"

# Optional
password=dummypassword

echo "Generating key request for $domain"

mkdir -p /etc/ssl/private
chmod 700 /etc/ssl/private
mkdir -p /etc/ssl/certs

# Generate a key
openssl genrsa -des3 -passout pass:$password -out /etc/ssl/private/$domain.key 2048 -noout

# Remove passphrase from the key. Comment the line out to keep the passphrase
echo "Removing passphrase from key"
openssl rsa -in /etc/ssl/private/$domain.key -passin pass:$password -out /etc/ssl/private/$domain.key

# Create the request
echo "Creating CSR"
openssl req -new -key /etc/ssl/private/$domain.key -out /etc/ssl/private/$domain.csr -passin pass:$password \
    -subj "/C=$country/ST=$state/L=$locality/O=$organization/OU=$organizationalunit/CN=$commonname/emailAddress=$email"

# Create the cert
openssl x509 -req -days 365 -in /etc/ssl/private/$domain.csr -signkey /etc/ssl/private/$domain.key -out /etc/ssl/certs/$domain.crt

# Setup nginx config
sed "s/{{hostname}}/${domain}/" < $DIR/template.conf > /etc/nginx/sites-available/site.conf
ln -sf /etc/nginx/sites-available/site.conf /etc/nginx/sites-enabled/site.conf

Шаблон выглядел примерно так: 

server {
    # listen 80 #uncomment to also listen on port 80 - useful for debugging
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name {{hostname}};

    ssl_certificate /etc/ssl/certs/{{hostname}}.crt;
    ssl_certificate_key /etc/ssl/private/{{hostname}}.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";

    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
    add_header X-Frame-Options sameorigin;
    add_header X-Content-Type-Options nosniff;

    location / {
        ...
    }
}

Домен выглядел примерно так: ip-172-10-11-12.

Для отладки всего я запустил что-то вроде , следующее - это из памяти, поэтому он может отключить детали.Я начал с того, что убедился, что могу локально свернуть сервер, нажав nginx: 

curl https://ip-172-10-11-12/healthcheck --cacert /etc/ssl/certs/ip-172-10-11-12.crt

Затем я получил адрес ELB и убедился, что могу свернуться против этого.Я должен был пойти на машине, которая могла получить доступ к машине ELB.Обратите внимание, что из-за правил безопасности, ELB не был привязан, но был свернут.Я считаю, что я проверил это 2 способами.Сначала я попробовал: 

curl https://elb-address/healthcheck --insecure

Затем я добавил ip-172-10-11-12 в файл / etc / hosts и попытался: 

curl https://ip-172-10-11-12/healthcheck --cacert /cert/file/copied/onto/machine

Как только я заработал это, ALB ELB начал работать.Мне пришлось проверить правила брандмауэра, группы безопасности AWS и т. Д., Прежде чем этот последний вызов сработал.Но когда это сработало, ELB начал видеть сервер.

У меня также было 1 заключительное понимание при отладке этого: если ELB доступен из общедоступного Интернета, ELB должен иметь только общедоступные подсети, аобщедоступные подсети должны находиться в той же зоне доступности, что и целевые машины

...