ERR_INSECURE_RESPONSE советы по раздаче в Javascript

У нас есть много вызовов ajax из нашего веб-приложения, и все дело в https-запросе (наши мандаты IT-команды), да, мы открыли заголовки, чтобы разрешить перекрестный домен. Но проблема в том, что у нас есть собственный собственный сертификат, используемый внутри для всех наших приложений, поэтому в основном я получаю ошибку, когда мы вызываем ajax:

Не удалось загрузить ресурс: net:: ERR_INSECURE_RESPONSE

Если я открываю URL-адрес в браузере и принимаю сертификаты, вызовы ajax работают нормально. Итак, мой вопрос: есть ли способ справиться с этим через Javascript? Или добавление доверенного сертификата разрешит эту проблему? Также даже после добавления доверенного сертификата снова я столкнулся с любой проблемой в ajax?

Примечание. Мы тестируем все это в браузере Chrome

Ответ 1

Да, добавление сертификата в список доверенных сертификатов пользователей поможет решить вашу проблему. Пока ваш сервер настроен на сервер CORS правильно (и кажется, что он основан на вашем успехе после принятия сертификата), сертификат является вашей единственной проблемой.

HTTPS предоставляет два преимущества безопасности:

Вы знаете, что канал связи защищен между вами и тем, с кем вы разговариваете (например, когда Алиса разговаривает с Бобом, она знает, что никто не может слушать)
Вы знаете, с кем вы разговариваете, это действительно тот, кого они утверждают (например, когда Алиса разговаривает с bob.com, она знает, что это действительно сервер, который она знает как bob.com, а не самозванец).

Первое преимущество - автоматическое. Он гарантирован криптографическим протоколом и не может быть удален (за исключением очень сложных атак на дыры безопасности, которые обычно фиксируются очень быстро).

Второе преимущество - это не только техническая выгода: это вопрос доверия. Серверы используют сертификаты для связывания своего открытого ключа (который предоставляет первый компонент безопасности) с их собственной идентификацией. Эти сертификаты с открытым ключом подписываются доверенными организациями, называемыми органами сертификации (ЦС).

Когда вы пытаетесь подключиться к bob.com, сайт предоставляет вам открытый ключ для обеспечения безопасной связи. Вы скептически настроены и говорите: "Конечно, этот открытый ключ позволит мне безопасно общаться с вами, но как я знаю, что вы действительно bob.com?" Затем сервер дает вам сертификат с сертификатом CA, который гласит:

Мы, авторитет сертификатов VeriSign, которым в полной мере доверяют наши исследования, настоящим подтверждаем, что следующий открытый ключ действительно действительно относится к bob.com:

Открытый ключ: ZGdlZGhydGhyaHJ0eWp5cmo...

Подтвержденная подпись,

VeriSign

Существует множество основных органов сертификации, которым доверяют (операционными системами и браузерами) выдавать подписанный сертификат тогда и только тогда, когда они надежно подтвердили, что открытый ключ действительно принадлежит доменному имени. Поскольку ваша ОС уже доверяет этим сигнатурам, мы можем использовать их без каких-либо подтверждений.

Когда вы используете самозаверяющий сертификат, доверенный ЦС не подтвердил, что ваш сертификат действительно принадлежит вашему доменному имени. Любой может создать документ, в котором говорится:

Эй, мужик, это на 100% определенно открытый ключ для bob.com:

Открытый ключ: WGdoZmpodHlqa2p1aXl1eWk...

Просто доверься нам, ребятам, написавшим эту заметку, хорошо? Мы ОПРЕДЕЛЕННО уверены, что ключ. Ребята, которые записали эту заметку, ребята, которые запускают bob.com. Мы обещаем.

Подпись,

Ребята, написавшие эту заметку

У этого нет надежной подписи. Пользователь должен решить, хотят ли они принять аттестацию сертификата, что открытый ключ действительно принадлежит bob.com.

Сделать это решение осмысленно сложным процессом - вам нужно проверить сертификат и найти ранее существовавшую доверенную запись открытого ключа где-нибудь (или обратиться к администратору сайта или представителю службы поддержки). По сути, вам нужно, чтобы ваше доверие к сертификату происходило откуда-то, потому что оно не поступает из доверенной подписи основного центра сертификации.

Предоставление JavaScript для автоматического определения этого доверия не имеет смысла. Все дело в том, что пользователь должен решить, заслуживает ли сертификат достоверность и затем внести соответствующие изменения в хранилище системных сертификатов.

Это можно гипотетически сделать для Ajax-запросов, но это было бы некрасиво. Вам нужно будет показать пользователю экран браузера-пользователя, спрашивающий, хочет ли пользователь доверять самозаверяющему сертификату для любого домена, к которому пытается обратиться script. Кроме того, что это очень опасно для просмотра, это может быть опасно запутанным: если я нахожусь на example.com и внезапно (из-за действий script, о которых я не знал), меня просят доверять сертификат для bob.com, я могу принять его исключительно на основании моего доверия example.com.

Либо добавьте сертификат в список надежных сертификатов ваших систем, либо получите его подписью с помощью центра сертификации, которому уже доверяют ваши системы.

Ответ 2

Добавление доверенного сертификата должно быть достаточным, если все вызовы AJAX выполняются в том же домене, если они не одного домена, используя JSONP для получения данных с помощью AJAX, вы не получите ошибку.

Если вы хотите узнать о JSONP, вот полезная ссылка: http://www.sitepoint.com/jsonp-examples/