Ошибка sni-support-required-for-valid-ssl с экземпляром AWS EC2 при реализации ssl с openresty

Я создал веб-приложение app.mywebapp.com. Я планирую внедрить white label для своих пользователей.

Веб-сайт примера пользователя: userwebsite.com. Я хочу указать их поддомен на свое приложение.

Пример: dashboard.userwebsite.com должен указывать на app.mywebapp.com

Я добавил запись CNAME в настройки DNS моих пользователей

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

Мое веб-приложение работает на одном экземпляре AWS EC2 с SSL, обрабатываемым балансировщиком нагрузки.

Я создал еще один экземпляр EC2 с балансировщиком нагрузки для обработки SSL-запросов с моих пользовательских веб-сайтов.

Когда я набираю общедоступный DNS экземпляра EC2 в браузере, я получаю сообщение об небезопасной ошибке SSL.

"sni-support-required-for-valid-ssl" certificate is not trusted

Вот файл nginx.conf для обработки SSL через openresty

    user  www-data;
    events {
      worker_connections 1024;
    }

    http {
      lua_shared_dict auto_ssl 1m;
      lua_shared_dict auto_ssl_settings 64k;
      resolver 8.8.8.8 ipv6=off;

      init_by_lua_block {
        auto_ssl = (require "resty.auto-ssl").new()
        auto_ssl:set("allow_domain", function(domain)
          return true
        end)
        auto_ssl:init()
      }

      init_worker_by_lua_block {
        auto_ssl:init_worker()
      }

      server {
        listen 443 ssl;
        ssl_certificate_by_lua_block {
          auto_ssl:ssl_certificate()
        }
        ssl_certificate /etc/ssl/resty-auto-ssl-fallback.crt;
        ssl_certificate_key /etc/ssl/resty-auto-ssl-fallback.key;

    proxy_ssl_server_name on;

    location / {
            proxy_set_header Host app.mywebapp.com;
            proxy_set_header Referer $host$uri;
            proxy_buffer_size          128k;
            proxy_buffers              4 256k;
              proxy_busy_buffers_size    256k;

            proxy_set_header User-Agent $http_user_agent;
            proxy_set_header X-Real-IP $remote_addr;

            proxy_set_header Accept-Encoding "";
            proxy_set_header Accept-Language $http_accept_language;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto  https;
            proxy_read_timeout 5m;

            proxy_pass https://app.mywebapp.com;
        }
      }

      server {
        listen 80;
        location /.well-known/acme-challenge/ {
          content_by_lua_block {
            auto_ssl:challenge_server()
          }
        }

    location /{
    return 301 https://$host$request_uri;
    }

      }

      server {
        listen 127.0.0.1:8999;
        client_body_buffer_size 128k;
        client_max_body_size 128k;

        location / {
          content_by_lua_block {
            auto_ssl:hook_server()
          }
        }
      }
    }

person Anirudh    schedule 07.12.2019    source источник
comment
Что за открытость   -  person Arun K    schedule 07.12.2019
comment
openresty.org/en   -  person Anirudh    schedule 11.12.2019
comment
У меня была эта проблема, и tail -F /usr/local/openresty/nginx/logs/error.log в терминале, когда нажимал кнопку «Обновить», помог мне увидеть, что пошло не так   -  person user1069816    schedule 05.07.2021


Ответы (1)


Это происходит потому, что по какой-то причине вашему серверу не удалось получить новые сертификаты. Я не могу полностью отладить вашу настройку, но могу заверить вас, что документация по адресу https://github.com/GUI/lua-resty-auto-ssl работает, но может быть нелегко отладить.

Protip; следи за своими журналами

Ваш вопрос неполный, но в большинстве случаев при использовании OpenResty вам следует следить за своими файлами журналов ошибок, чтобы узнать, что он вам скажет. Но в большинстве случаев это будут распространенные ошибки:

Слишком много запросов

GUI/lua-resty-auto-ssl будет очень, очень быстро повторять попытку. Это означает, что если вы развернете неправильную конфигурацию, вы, скорее всего, достигнете ограничений Let's Encript. Если вы выполняете тяжелую отладку, действительно рекомендуем вам использовать другой субдомен, чтобы не перегружать ваш основной домен.

Разрешения каталога

Если открытость не может писать, она потерпит неудачу. Но в некоторых случаях OpenResty / Nginx все еще может работать, но Deydrated не сработает.

Проблемы с переадресацией и отсутствием GUI / lua-resty-auto-ssl в нужном месте

Это сложно отладить, но, объясняя это очень просто, проделайте шаг за шагом при реализации перенаправления (например, принудительного HTTP на HTTPS), потому что вы можете получить новый сертификат, а затем не продлевать его.

Под "точным местом" подразумевается, что

  • если Let's encrypt попытается подключиться к порту 80, вам понадобится GUI/lua-resty-auto-ssl сниппет
  • если Let's encrypt будет пробовать домен example.com, вам понадобится GUI/lua-resty-auto-ssl сниппет

Заключительные комментарии:

По возможности попробуйте минимальное количество примеров из GUI/lua-resty-auto-ssl, затем каждое внесенное вами изменение, повторите попытку, пошагово и просмотрите свои файлы журналов. Если вы сделаете это, это может занять у вас на 30-60 минут больше, но сэкономит дни на отладку, особенно если вы используете его впервые.

person Emerson Rocha    schedule 14.12.2019