JavascriptのERR_INSECURE_RESPONSE処理のヒント
Webアプリケーションから多くのajax呼び出しがありますが、すべてはhttpsリクエスト（ITチームの義務）であり、はい、クロスドメインを許可するヘッダーを開いています。しかし問題は、すべてのアプリで内部的に使用される独自のカスタム証明書があるため、基本的にajaxを呼び出すとエラーが発生することです：
リソースの読み込みに失敗しました：net :: ERR_INSECURE_RESPONSE
ブラウザでURLを開き、証明書を受け入れた場合、ajax呼び出しは正常に機能します。だから私の質問は、JavaScriptを介してこれを処理する方法はありますか？または、信頼できる証明書を追加するとこの問題は解決しますか？また、信頼できる証明書を追加した後でも、ajaxで何か問題に直面しますか？
注：これらすべてをchrome browserでテストしています
はい。証明書をユーザーの信頼できる証明書のリストに追加すると、問題が解決します。サーバーがサーバーCORSに正しく設定されている限り（および、証明書を受け入れた後の成功に基づいているようです）、証明書が唯一の問題です。
HTTPSには2つのセキュリティ上の利点があります。
- あなたとあなたが話している相手との間の通信チャネルが安全であることを知っています（たとえば、アリスがボブと話したとき、彼女は誰も聞くことができないことを知っています）
- あなたが話している人は本当に彼らが主張している人です（例えば、アリスが
bob.comと話しているとき、彼女はそれが本当にbob.comとして知っているサーバであると知っています）詐欺師）
最初の利点は自動です。暗号化プロトコルによって保証されており、除去することはできません（通常非常に迅速に修正されるセキュリティホールに対する非常に複雑な攻撃を除きます）。
2番目の利点は、厳密には技術的な利点ではありません。trustの問題です。サーバーは、証明書を使用して公開キー（最初のセキュリティコンポーネントを付与する）を独自のIDにリンクします。これらの公開鍵証明書は、認証局（CA）と呼ばれるユーザー信頼機関によって署名されます。
bob.comに接続しようとすると、サイトは安全な通信を実行するための公開鍵を提供します。あなたは懐疑的で、「確かに、この公開鍵は安全にあなたと話すことを可能にしますが、あなたが本当にbob.com？その後、サーバーはCA署名証明書を提供します。
私たち、VeriSign認証局は、私たちの調査で徹底的であると広く信頼されており、次の公開鍵が本当に
bob.comに属していることを証明しています。公開鍵：
ZGdlZGhydGhyaHJ0eWp5cmo...検証可能な署名、
ベリサイン
公開鍵が本当にドメイン名に属していることを確実に検証した場合にのみ、署名された証明書を発行するために（オペレーティングシステムとブラウザによって）広く信頼されている多くの主要な認証局があります。お使いのOSはすでにこれらの署名を信頼しているため、確認なしで使用できます。
自己署名証明書を使用する場合、信頼できるCAは、証明書が実際にドメイン名に属していることを確認していません。誰でも次のような文書を作成できます。
おい、男、これは間違いなく
bob.comの公開鍵です：公開鍵：
WGdoZmpodHlqa2p1aXl1eWk...このメモを書いた人たち、私たちを信頼してください。これが鍵であることは間違いありません。このメモを書いたのは、
bob.comを実行している人です。私たちは約束します。署名済み、
このメモを書いた人たち
これには信頼できる署名がありません。ユーザーは、公開キーが本当にbob.comに属しているという証明書の証明を受け入れるかどうかを決定する必要があります。
この決定を意味のあるものにすることは難しいプロセスです。証明書を調べて、公開キーの既存の信頼できる記録をどこかで見つける必要があります（またはサイト管理者またはヘルプデスクの担当者に連絡してください）。実際には、証明書はsomewhereからのものである必要があります。これは、主要な認証局の信頼できる署名からのものではないためです。
JavaScriptがこの信頼の判断を自動的に行うことを許可しても意味がありません。全体のポイントは、証明書が信頼できるかどうかをserが決定してから、システムの証明書ストアに適切な変更を加える必要があるということです。
このcouldはAjaxリクエストに対して仮想的に行われますが、見栄えはよくありません。ユーザーがスクリプトがアクセスしようとしているドメインの自己署名証明書を信頼するかどうかを尋ねるブラウザーUI画面を表示する必要があります。ブラウジングエクスペリエンスを非常に混乱させるだけでなく、これは危険なほど混乱させる可能性があります。example.comを使用している場合、突然（知らないスクリプトのアクションのため） bob.comの証明書。example.comの信頼に基づいて純粋に受け入れるかもしれません。
証明書をシステムの信頼できる証明書リストに追加するか、システムですでに信頼されているCAによって署名されます。
すべてのAJAX呼び出しが同じドメインで行われ、同じドメインのものでない場合、JSONPを使用してAJAXエラーは発生しません。
JSONPについて知りたい場合は、次のリンクが役立ちます。 http://www.sitepoint.com/jsonp-examples/