ServiceNow インスタンスからの送信 SSL および TLS 接続SSLは何に使用されますか? SSL プロトコルと TLS プロトコルにより、2 つの当事者が互いを識別して認証し、機密性とデータ整合性を持って通信できます。TLS プロトコルは Netscape SSL 3.0 プロトコルから発展しましたが、TLS と SSL は相互運用しません。 SSL プロトコルと TLS プロトコルは、インターネット経由の通信セキュリティを提供し、クライアント/サーバー アプリケーションが機密性の高い信頼性の高い方法で通信できるようにします。プロトコルには、レコード プロトコルとハンドシェイク プロトコルの 2 つの層があり、これらは TCP/IP などのトランスポート プロトコルの上に階層化されています。どちらも非対称暗号化と対称暗号化技術を使用しています。 SSL または TLS 接続は、SSL または TLS クライアントになるアプリケーションによって開始されます。接続を受信するアプリケーションが SSL または TLS サーバーになります。すべての新しいセッションは、SSL または TLS プロトコルで定義されているハンドシェイクで始まります。 SSLとTLSの用途には、HTTPS、FTPS、SOAP、REST、SMTP、IMAPS、およびその他の多くのサービスがトランスポート層セキュリティに依存しています。経験則では、安全な接続が必要な場合は、おそらく証明書が必要です。 SSLとTLSの違い SSL は TLS の前身です。SSLはさまざまなバージョンでリリースされ、バージョン1はありませんでした。SSLv2 と SSLv3 があります。TLS は SSL の新しいバージョンとして 1999 年に導入され、SSL 3.0 に基づいていました。 SSL 2.0 と 3.0 はどちらも IETF によって廃止されました (それぞれ 2011 年と 2015 年)。証明書は SSL/TLS プロトコルに依存しません TLS フロー 以下は、クライアント(接続しているアプリケーション)とサーバー(接続を受信するアプリケーション)が実行する手順です クライアントは、クライアントのランダム値とサポートされている暗号スイートとともに、「Client hello」メッセージをサーバーに送信します。サーバーは、サーバーのランダム値とともに「Server hello」メッセージをクライアントに送信することで応答します。サーバーは認証のために証明書をクライアントに送信し、クライアントに証明書を要求できます。サーバーは「Server hello done」メッセージを送信します。サーバーがクライアントに証明書を要求した場合、クライアントはそれを送信します。クライアントはランダムなPre-Master Secretを作成し、サーバーの証明書の公開鍵で暗号化して、暗号化されたPre-Master Secretをサーバーに送信します。サーバーはプリマスターシークレットを受信します。サーバーとクライアントはそれぞれ、プリマスターシークレットに基づいてマスターシークレットとセッションキーを生成します。クライアントは、「暗号仕様の変更」通知をサーバーに送信して、クライアントがメッセージのハッシュと暗号化に新しいセッションキーの使用を開始することを示します。クライアントも「クライアント終了」メッセージを送信します。サーバーは「暗号仕様の変更」を受信し、セッションキーを使用してレコードレイヤーのセキュリティステータスを対称暗号化に切り替えます。サーバーがクライアントに「サーバー終了」メッセージを送信します。これで、クライアントとサーバーは、確立したセキュリティで保護されたチャネルを介してアプリケーション データを交換できます。クライアントからサーバーへ、およびサーバーからクライアントへ送信されるすべてのメッセージは、セッション キーを使用して暗号化されます。 TLS フロー 以下の簡素化されたフロー TLS の一部 技術的には、TLS は次の 2 つの部分で構成されています。 TLS ハンドシェイク レイヤーは、使用する暗号 (暗号化アルゴリズムのタイプ)、認証 (ドメイン名と組織に固有の証明書を使用)、および鍵交換 (証明書の公開鍵と秘密鍵のペアに基づく) を管理します。 ハンドシェイクプロセスは、双方の安全なネットワーク接続を確立するために 1 回だけ実行されます。TLS レコードレイヤー は、ユーザーアプリケーションからデータを取得し、暗号化し、適切なサイズ (暗号で決定される) にフラグメント化して、ネットワークトランスポートレイヤーに送信します。 データを収集しています ケース TLS を使用したエンドポイントへの接続は、クライアント側の多くの要素に依存します。たとえば、ブラウザを使用している場合、ブラウザは接続と証明書の交換を担当します。クライアントが Web プロキシを使用している場合、これは接続の確立方法にも影響します。ケースがある場合は、問題を絞り込んで切り分けることが重要です。テストに使用できるツールやものは次のとおりです。 OpenSSL : これは、LinuxおよびMACのコマンドラインツールです。これにより、エンドポイントに接続してSSL接続をネゴシエートできます。このコマンドを使用すると、接続中に多くの証明書とSSLネゴシエーション情報を出力できます。接続をテストするために使用できるコマンドを以下に示します。 openssl s_client -connect hi.service-now.com:443 このコマンドは、hi.service-now.com への SSL 接続の作成を試みます。hi.service-now.com によって提示された接続の詳細と証明書、および以下に示すその他の情報が出力されます。 コマンドラインからのこの接続はソフトウェアとは無関係であるため、これを試すことが重要です。このコマンドでエラーが発生した場合は、出力に出力されます。これは、ケースの作業メモとして常に追加する必要があります。 openssl s_client -connect hi.service-now.com:443 |openssl x509 -noout -text これは前のコマンドと似ていますが、代わりに、SAN(サブジェクト代替名)情報、OCSP情報、その他の署名情報など、サーバーから受信した証明書に関する詳細情報を提供します 正常な接続に影響を与えるもの 接続の成功に影響を与える要因は多数あります。これらのいくつかのみを以下にリストします。 OCSP OCSP は オンライン証明書ステータスプロトコル を表します。その背後にある理論は、企業が証明書を作成し、署名を取得するというものです。セキュリティ上の理由から、サーバー上の証明書を更新したいが、古い証明書を使用しているユーザーに、古い証明書が利用できなくなったことを知らせたい場合。OCSP を使用します。OCSP は、クライアントによって実行される追加のチェックです (正常なクライアントの場合)。OCSP では、Entrust などの認証局 (CA) が証明書失効リスト (CRL) を所有しています。これは、無効になったため使用すべきではない証明書のリストです。クライアント (ServiceNow など) がサーバーに接続すると、SSL ハンドシェイク中にエンドポイントから CRL の所有者が通知されます。これを確認するには、次を実行できます。 openssl s_client -connect hi.service-now.com:443 |openssl x509 -noout -text 結果には、次のようなセクションが表示されます。 Authority Information Access: OCSP - URI:http://ocsp.entrust.net CA Issuers - URI:http://aia.entrust.net/l1k-chain256.cer 上記のように、Entrust は証明書失効リスト (CRL) を所有しており、確認する必要があります。クライアント、この場合は ServiceNowです上記の指定 URL に取り消し要求を送信します。OCSP 応答を取得します。OCSP 応答は、証明書の失効ステータスに関する要求を受信したときに OCSP レスポンダーが返すものです。要求/応答プロトコルは、RFC 2560 で指定されています。応答自体はレスポンダーによって署名され、彼らは独立した生活を送ることができます。これは、「特定の OCSP 応答は、単一の証明書について話す特殊な CRL と見なすことができる」ことを意味します。注意 ロンドンでは、証明書失効チェック を導入し、証明書の検証プロセスを、証明書チェーン内の第 1 レベルと第 2 レベルの証明書の評価から、証明書チェーン内のすべての証明書の評価に変更しました。このため、高セキュリティプラグインを利用するために API 呼び出しを行っている顧客は、インスタンスの信頼ストアに完全な証明書チェーンが定義されていない可能性があるため、403 エラーが発生するリスクがあります。これらのチェックを無効にするには、プロパティ com.glide.communications.httpclient.debug_verify_hostname を「false」に設定します 証明書チェーン ブラウザや ServiceNow などのすべてのクライアントには、証明書バンドルが含まれます。CA バンドルは、ルート証明書と中間証明書を含むファイルです。エンドエンティティ証明書と CA バンドルが証明書チェーンを構成します。このバンドルは、認証局が証明書を変更するか、有効期限が切れない限り、変更されません。接続先の顧客サーバーに、Entrustなどの一般的な信頼できるCAによって署名された証明書チェーンがある場合。これらは既に CA バンドルにあるため、証明書チェーン全体を検証できます。証明書チェーンを検証できなければなりません。上記の最初の OpenSSL コマンドを使用して、チェーンに含まれる証明書を確認できます。必要な場合は、インスタンスに追加する必要があります。