Geekly Articles each Day

HTTPからHTTPSへの移行の完全ガイド

現在、HTTPSはすべてのWebサイトに必要です 。ユーザーは個人データを転送するときにアドレスバーでロックを探します。 ChromeおよびFirefoxは、HTTPSを使用しないページ上のフォームを使用して、安全でないWebサイトとして明示的にフラグを立てます。 これは、検索結果の位置に 影響し、プライバシー全般に深刻な影響を及ぼします。 さらに、無料の証明書を取得するためのいくつかのオプションが用意されているため、HTTPSへの切り替えは必要なことです。


HTTPSのインストールは、準備ができていないユーザーにとっては少し恐ろしいものです。さまざまな関係者が関与する多くの手順、および暗号化とサーバー構成の特定の知識が必要であり、一般に複雑に思えます。

このガイドでは、個々のコンポーネントと手順を説明し、インストールの各手順を明確に述べます。 特に、ホスティング事業者自体がHTTPS証明書を提供している場合は、すべてがスムーズに行われます。コントロールパネルを離れることなく、すべてをすばやく簡単に実行できる可能性が高くなります。

これには、cPanel共有ホスティング所有者、LinuxおよびUnixのApache HTTPおよびnginxサーバー管理者、およびWindowsのInternet Information Serverの詳細な手順が含まれます。

基本から始めましょう。

HTTP、HTTPS、HTTP / 2、SSL、TLS：どこで？


多くの頭字語は、クライアントとサーバー間の通信プロセスを説明するために使用されます。 技術的な本質に不慣れな人は、しばしばそれらを混同します。

ハイパーテキスト転送プロトコル（HTTP）は、クライアントとサーバーが接続を確立するためにサポートする必要がある主要な通信プロトコルです。 要求と応答、セッション、キャッシング、認証などの概念について説明します。1989年にCERNのTim Berners-Lee byと彼のグループによって始められたプロトコルとHypertext Markup Language（HTML）の作業。 プロトコルの最初の公式バージョン（HTTP 1.0）は1996年にリリースされ、すぐに1997年にHTTP 1.1のバージョンが登場しました。これは今日広く使用されています。

このプロトコルは、ブラウザーとサーバーの間でクリアテキストで情報を送信するため、通過するネットワーク上でこの情報を見ることができます。 これはセキュリティ上の問題であるため、 HTTP Secure（HTTPS）が発明されました。これにより、クライアントとサーバーは暗号化された通信チャネルを確立し、このチャネルでクリアテキストでメッセージを送信して、リスニングから効果的に保護します。

SSLとTLSという用語は、TLS 1.0がSSL 3.0の代わりになるため、しばしば交換可能に使用されます。 SSL自体はNetscapeによって開発され、TLSはIETF標準です。 この記事の執筆時点では、すべてのSSLバージョン（1.0、2.0、3.0）は、さまざまなセキュリティ問題のために使用することはお勧めできません。最新のブラウザーではこれについて警告が表示されます。 TLS標準から、バージョン1.0、1.1、および1.2が使用され、バージョン1.3は現在ドラフト段階にあります。

1996年から1997年の間に、最新のインターネット（SSLおよびTLSを使用または使用しないHTTP 1.1）の現在の安定バージョンを入手しました。 以前は、HTTPは重要ではないトラフィック（ニュースの読み取りなど）に使用され、HTTPSは重要なトラフィック（認証やeコマースなど）に使用されていました。ただし、プライバシーの価値が高まると、Google ChromeなどのブラウザーはHTTP機密」と将来的にそれらの新しい警告が表示されます。

増加するサイトでサポートされるHTTPプロトコルの次の更新-HTTP / 2-遅延を減らし、パフォーマンスとセキュリティを向上させるために、新しい機能（圧縮、多重化、さまざまなトラフィックの優先度）を実装します。

HTTPバージョン1.1では、セキュア接続はオプションです（HTTPおよび/またはHTTPSを互いに独立して使用できます）が、HTTP / 2では実際に必須です-標準ではTLSなしのHTTP / 2が許可されていますが、ほとんどの開発者ブラウザはTLSを通してHTTP / 2サポートのみを実装すると述べました。

HTTPSを提供するものは何ですか？


そもそもHTTPSについて考える必要があるのはなぜですか？ これは、3つの主な理由で導入されました。


暗号化ベース


機密性、整合性、および認証はHTTPSの固有の機能ではありません。これらは暗号化の重要な概念です。 それらをより詳しく見てみましょう。

守秘義務


機密性はプライバシーです。つまり、情報を無許可の人による読み取りから保護します。 通常、このプロセスでは、情報をプレーンテキストと呼ばれる読み取り可能な形式（オーディオとビデオを含む）から暗号テキストと呼ばれる暗号化された読み取り不可能な形式に変換します。 このプロセスは暗号化と呼ばれます 。 読み取り不可能な暗号文を読み取り可能な平文に戻す逆のプロセスは、 復号化と呼ばれます。 情報の暗号化と復号化には多くの方法があります- 暗号化関数 （またはアルゴリズム ）。

2つの当事者が通信するには、2つの問題に同意する必要があります。

  1. 通信で使用するアルゴリズム（暗号化関数）。
  2. 選択したメソッドで使用されるパラメーター、パスワード、またはルール（ シークレット ）。

主に2つの暗号化方法があります。


対称暗号化方式は、送信者が暗号化に使用するものと受信者が同じ方法および同じキーで復号化するために使用する同じ秘密を両方の当事者が保持しているという事実に依存しています（下の図を参照）。 これらの方法の問題は、物理的に互いに会わずに秘密鍵を当事者がどのように合意（つまり交換）するかです。何らかの安全な通信チャネルを確立する必要があります。


対称暗号化（ ラージバージョンを参照 ）

非対称法はこの種の問題を解決します-それらは公開鍵と秘密鍵の概念に基づいています。 クリアテキストは単一のキーで暗号化され、キーのペアを使用して解読できます。

それでは、どのように機能しますか？ 互いに安全に通信したい2つの側面があるとします-アリスとボブ（各教科書では、架空の人物の名前は常に使用されます。セキュリティガイドなどでは、この伝統を尊重します）。 それぞれに固有のキーペアがあります。1つはシークレット、もう1つはパブリックです。 秘密鍵は、それぞれの所有者のみが知っています。 公開鍵はすべてに公開されています。

アリスがボブにメッセージを送信したい場合、彼女は彼の公開鍵を取得し、平文を暗号化し、彼に暗号文を送信しなければなりません。 その後、彼は秘密鍵を使用して復号化します。

ボブがアリスにメッセージを送信したい場合、彼は彼女の公開鍵を取得し、平文を暗号化し、彼女に暗号文を送信しなければなりません。 次に、彼女は秘密鍵を使用して復号化します。


非対称暗号化（ ラージバージョンを参照 ）

対称暗号化はいつ使用し、非対称暗号化はいつ使用しますか？

非対称暗号化は 、クライアントとサーバー間で秘密を交換するために使用されます。 現実には、通常、双方向の非対称通信は必要ありません。暗号化されたメッセージを受信できるように、パーティの1つ（簡単にするためにサーバーと呼びます ）がキーのセットを所有していれば十分です。 実際には、これはクライアントからサーバーへの一方向の情報のみを保護します。これは、公開キーで暗号化された情報は、ペアになっている秘密キーを使用してのみ解読できるためです。つまり、サーバーのみが解読できます。 もう一方の方向は保護されていません-サーバーの秘密鍵で暗号化された情報は、公開鍵で解読できます。公開鍵は誰でも利用できます。 反対側（簡単にするためにクライアントとも呼ばれます ）は、ランダムに生成されたセッションシークレットをサーバーの公開キーで暗号化して通信を開始し、暗号文をサーバーに送り返します。サーバーは、秘密キーを使用して暗号化を解除し、秘密を保持します。

次に、対称暗号化は送信中に実データを保護するために使用されます。これは、非対称暗号化よりもはるかに高速だからです。 秘密を交換すると、情報を暗号化および復号化できるのは2者（クライアントとサーバー）だけです。

これが、ハンドシェイクの最初の非対称部分がキー交換とも呼ばれる理由であり、実際の暗号化通信が暗号化方法として知られるアルゴリズムを使用する理由です。

誠実さ


HTTPSが解決するもう1つの問題は、 データの整合性です。1）すべての情報が完全に配信されるという保証。 2）送信中に誰も情報を変更しないという保証。 情報をシームレスに送信するために、 メッセージダイジェストアルゴリズムが使用されます。 交換される各メッセージのメッセージ認証コード（MAC）の計算は、 暗号化ハッシュプロセスです。 たとえば、MAC（ タグと呼ばれることもあります）を取得するには、以下の実際的な不可能性（不可能性という用語が使用されることもある）を保証する方法が使用されます。


認証


信頼性はどうですか？ 公開鍵インフラストラクチャの実際のアプリケーションの問題は、どちらの側も実際に第2の側が誰であるかを見つける方法がないことです。これらは物理的に互いに分離されています。 その信頼性を第2の当事者に証明するために、 相互信頼のある第3の当事者、つまり認証局（CA）が関与します。 このCAは、ドメイン名example.com （一意の識別子 ）が公開キーXXX関連付けられていることを確認する証明書を発行しexample.com 。 場合によっては（EVおよびOV証明書を使用-以下を参照）、CAは特定の会社がこのドメインを制御していることも確認します。 この情報は認証局Xによって保証（つまり認証）され、この保証は日付Y（つまり、証明書はこの日付から有効になります）よりも早く有効であり、日付Zよりも遅く（つまり、この日付で証明書が期限切れになります） 。 この情報はすべて、HTTPS証明書と呼ばれる1つのドキュメントに含まれています 。 簡単に理解できる類推を与えるために-これは国の政府（つまり、誰もが信頼する第三者）によって発行されたIDまたはパスポートのようなものです-そして、政府を信頼するすべての人は、所有者と所有者自身の証明書（パスポート）も信頼します もちろん、パスポートは偽物ではないと想定されていますが、証明書の改ざんはこの記事の範囲外です。

認証局は、証明書の署名を信頼する組織です。 Firefoxブラウザだけでなく、Windows、macOS、iOS、Androidなどのオペレーティングシステムには、信頼できる証明書のリストがあります。

ブラウザが信頼している証明機関を確認できます。


その後、すべての証明書が検証され、信頼されます。 検証は、オペレーティングシステムまたはブラウザのいずれかによって実行されます。信頼は直接確立されるか、信頼できる信頼された関係者を通じて確立されます。 信頼転送メカニズムは信頼チェーンとして知られています ：


信頼のチェーン（ ラージバージョンを参照 ）

追加の認証局を追加できます。これは、自己署名証明書を使用するときに役立ちます（これについては後で説明します）。

ほとんどの一般的な状況では、クライアントはサーバーのID（たとえば、顧客向けのeコマースサイト）を確認する必要があるため、このWebサイトのみに証明書が必要です。 電子政府システムなどのその他の状況では、クライアントとサーバーの両方が身元を証明する必要があります。 これは、両方の当事者が認証のために証明書を提示する必要があることを意味します。 このようなシステムもこの記事の範囲を超えています。

HTTPS証明書の種類


HTTPS証明書にはいくつかの種類があります。 これらは、次の基準に従って分類できます。

1.認証


  1. 検証済みドメイン（DV）
    最も一般的なタイプのDV証明書は、ドメインが特定の公開キーと一致することを確認します。 ブラウザはサーバーへの安全な接続を確立し、閉じた南京錠アイコンを表示します。 アイコンをクリックすると、「このWebサイトは所有者に関する情報を提供しませんでした」というメッセージが表示されます。 ドメインの所有権以外に、この証明書を取得するための追加要件はありません。DV証明書は、このドメインに正しい公開キーが提供されることを保証するだけです。 ブラウザには法人の名前は表示されません。 DV証明書は、多くの場合、安価（年間10ドル）または無料です-以下のLet's EncryptおよびCloudflareセクションを参照してください。
  2. 拡張確認（EV）
    EV証明書は、Webサイトを所有する法人を確認します。 これは最も信頼できるタイプの証明書です。 認証局がドメインを制御する法人を確認した後に発行されます。 法人はいくつかの条件の下で検証されます：

    • ドメイン管理（DV証明書）;
    • 会社が登録され、有効であることを確認するための州のレジストリ;
    • DunnやBradstreet、Salesforceのconnect.data.com、Yellow Pagesなどの独立したビジネスディレクトリ。
    • テスト通話;
    • 証明書内のすべてのドメイン名の検証（EV証明書ではワイルドカードは明示的に禁止されています）。

    ロックアイコンのように、EV HTTPS証明書には、URLの前に、検証済みの法人の名前（通常は登録会社）が表示されます。 iOS Safariなどの一部のデバイスは、URLを完全に無視して、検証済みのエンティティのみを表示します。 アイコンをクリックすると、氏名や法定住所など、組織に関する詳細が表示されます。 これらの証明書の費用は、年間150ドルから300ドルです。
  3. 検証済み組織（OV）
    EVと同様に、OV証明書は、Webサイトを所有する法人を確認します。 ただし、EVとは異なり、HTTPS OV証明書は、ユーザーインターフェイスに検証済みの法人の名前を表示しません。 その結果、OV証明書は検証の要件が高いためあまり一般的ではありませんが、ユーザーに見える利点は提供しません。 費用は年間40ドルから100ドルです。

2.対象ドメインの数


昔、HTTPS証明書のCNフィールドには通常、単一のドメインが含まれていました。 後に、サブジェクトの別名（SAN）が追加され、1つの証明書が追加のドメインをカバーするようになりました。 現在、すべてのHTTPS証明書は同じ方法で作成されます。単一ドメインの証明書であっても、この単一ドメインのSANフィールド（およびこのドメインのwwwバージョンの2番目のSANフィールド）が存在します。 ただし、多くの売り手は、歴史的な理由により、1つ以上のドメインのHTTPS証明書を販売しています。

  1. 単一ドメイン
    これは、 example.comおよびwww.example.comドメイン名に有効な証明書の最も一般的なタイプです。
  2. 複数のドメイン（UCC / SAN）
    この種類の証明書は、ユニファイドコミュニケーション証明書（UCC）またはサブジェクトの別名（SAN）とも呼ばれ、ドメインのリストをカバーできます（特定の制限まで）。 単一のドメインに限定されません-さまざまなドメインとサブドメインを指定できます。 コストには通常、特定の数（3〜5）のドメインが含まれ、追加料金で（特定の制限まで）追加できます。 姉妹サイトでのみ使用することをお勧めします。クライアントは、任意のWebサイトで証明書を確認するときに、メインドメインとすべての追加ドメインを確認するためです。
  3. サブドメイン（ワイルドカード）
    このタイプの証明書は、メインドメインと、無制限の数のサブドメイン（ *.example.com ）をカバーします-たとえば、 example.com 、 www.example.com 、 mail.example.com 、 ftp.example.comなど。メインドメインのサブドメインのみを対象としていること。

表には、さまざまな証明書が示されています。

証明書の種類検証済みドメイン（DV）検証済み組織（OV）拡張確認（EV）
HttpsHttps
確認済みの著作権者		Https
確認済みの著作権者
所有者情報はブラウザに表示されます
単一ドメインexample.com, www.example.com
複数のドメインexample.com 、 www.example.com 、 mail.example.com 、 example.net 、 example.orgなど
特定の制限（通常は100）までの定義済みリスト
サブドメイン*.example.com
任意のサブドメインに適しています。		使用不可-すべての名前を証明書に明示的に含め、証明機関によって検証する必要があります

構成


要約すると、4つのHTTPSコンポーネントには暗号化が必要です。

  1. 初期キー交換
    非対称アルゴリズムが使用されます（秘密鍵と公開鍵）。
  2. ID証明書 （証明機関によって発行されたHTTPS証明書）
    非対称アルゴリズムが使用されます（秘密鍵と公開鍵）。
  3. 実際のメッセージ暗号化
    対称アルゴリズムが使用されます（事前共有共有シークレット）。
  4. メッセージダイジェスト
    暗号化ハッシュアルゴリズムが使用されます。

これらの各コンポーネントは、異なるキーサイズの一連のアルゴリズム（一部は使用が推奨されなくなりました）を使用します。 ハンドシェイク中に、クライアントとサーバーは、使用する方法の組み合わせについて合意します-約12種類の公開キーアルゴリズム（キー交換）、約12種類の対称キーアルゴリズム（暗号）、3種類（2種類は使用しないこと）のいずれかを選択しますダイジェストメッセージのアルゴリズム。これにより、数百の組み合わせが得られます。

たとえば、 ECDHE-RSA-AES256-GCM-SHA384すると、 楕円曲線Diffie-Hellman Ephemeral（ECDHE）アルゴリズムを使用してキー交換が実行されます 。 証明機関は、 Rivest-Shamir-Adleman（RSA）アルゴリズムを使用して証明書に署名しました。 対称メッセージ暗号化は、 256ビットキーでAdvanced Encryption Standard（AES）暗号を使用し、 GCMモードで動作します。 メッセージの整合性は、 384ビットのダイジェストを使用するSHAセキュアハッシュアルゴリズムによって保証されます。 （ アルゴリズムの組み合わせの完全なリストが利用可能です ）。

そのため、いくつかの構成を選択する必要があります。

暗号スイート


使用する暗号スイートの選択は、互換性とセキュリティのトレードオフです。


OpenSSLは、サポートされている組み合わせ（上記を参照）を暗号強度の降順でリストします。 これは、クライアントとサーバー間の最初のハンドシェイク中に、両方の当事者によってサポートされる組み合わせが見つかるまで、最も強い組み合わせから順番に並べ替えられるように行われます。 他に選択肢がない場合は、最初に最も安全な組み合わせを試し、次にセキュリティを徐々に弱めることは理にかなっています。

ウィキペディアには、すべてのTLSコンポーネントのアルゴリズムの網羅的なリストが含まれており、 SSLおよびTLSの異なるバージョンでのサポートを示しています。

Mozilla SSL構成ジェネレーターは、サーバーで使用する暗号化方法を非常に有用で強く推奨するリファレンスです。 後で実際のサーバー構成で使用します。

キータイプ


Elliptic Curve Cryptography（ ECC ）証明書は、RSA証明書よりも処理が速く、使用するCPUが少ないため、モバイルクライアントにとって特に重要です。 ただし、Amazon、CloudFront、Herokuなどの一部のサービスは、この記事の執筆時点ではまだECC証明書をサポートしていません。

ECCの256ビットのキー長で十分と見なされます。

Rivest Shamir Adleman（ RSA ）証明書は低速ですが、多種多様な古いサーバーと互換性があります。 RSAキーはサイズが大きいため、2048ビットのRSAキーが最小許容範囲と見なされます。 4096ビット以上のキーを持つRSA証明書は、パフォーマンスを低下させる可能性があります-さらに、ほとんどの場合、追加の保護を損なう2048ビットの中間キーによって署名されます！

上記の記述の曖昧さと数字の欠如に気づいたかもしれません。 1つのサーバーをロードできるものは、別のサーバーをロードしません。 パフォーマンスへの影響を判断する最善の方法は、実際のWebサイトと実際の訪問者を使用して、自分のサーバーでダウンロードを確認することです。 そして、それも時間とともに変化します。

手続き


HTTPS証明書を取得するには、次の手順を実行します。

  1. 秘密鍵と公開鍵のペアを作成し、組織と公開鍵に関する情報を含む証明書署名要求（CSR）を準備します。
  2. 証明機関に連絡し、CSRに基づいてHTTPS証明書を要求します。
  3. 署名済みHTTPS証明書を取得して、サーバーにインストールします。

公開鍵インフラストラクチャ（PKI）のさまざまなコンポーネントを含むファイルのセットがあります：秘密鍵と公開鍵、CSR、および署名済みHTTPS証明書。物事をさらに複雑にするために、異なる当事者は異なる名前（および拡張子）を使用して同じものに名前を付けます。

手始めに、情報を保存するための2つの一般的な形式、DERとPEMがあります。1つ目（DER）はバイナリで、2つ目（PEM）はbase64でエンコードされたDERファイル（テキスト）です。デフォルトでは、WindowsはDER形式を直接使用し、フリーシステムの世界（LinuxおよびUNIX）はPEM形式を使用します。ファイルをある形式から別の形式に変換するツール（OpenSSL）があります。

例として、次のファイルを使用します。


ファイル名（および拡張子）は標準化されていません。どれでも使用できます。これらの名前を選んだのは、それらが話しているように見え、各コンポーネントが実行する機能を明確にするためです。意味のある任意の命名スキームを使用できます。主なことは、構成プロセス中にコマンドおよびサーバー構成で対応するキーおよび証明書ファイルを指定することです。

秘密鍵は、ランダムに生成された特定の長さの文字列（2048ビットを使用）で、次のようなものです。鍵を秘密にしてください！これは、非常に限られた権限（600）で保護し、誰にも開示しないことを意味します。彼のパートナー- 公開鍵 -は次のようになります。

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAm+036O2PlUQbKbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9N
i8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4E
S17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWu
Q30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnf
b/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDil
Tt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQgNQIDAQABAoIBAEAO2KVM02wTKsWb
dZlXKEi5mrtofLhkbqvTgVE7fbOKnW8FJuqCl+2NMH31F1n03l765p4dNF4JmRhv
/+ne4vCgOPHR/cFsH4z/0d5CpHMlC7JZQ5JjR4QDOYNOpUG51smVamPoZjkOlyih
XGk/q72CxeU6F/gKIdLt6Dx03wBosIq9IAE8LwdMnioeuj18qaVg195OMeIOriIn
tpWP4eFya5rTpIFfIdHdIxyXsd6hF/LrRc9BMWTY1/uOLrpYjTf7chbdNaxhwH7k
buvKxBvCvmXmd6v/AeQQAXbUkdSnbTKDaB9B7IlUTcDJyPBJXvFS1IzzjN6vV+06
XBwHx5ECgYEAyRZLzwnA3bw8Ep9mDw8JHDQoGuQkFEMLqRdRRoZ+hxnBD9V9M0T6
HRiUFOizEVoXxf6zPtHm/T7cRD8AFqB+pA/Nv0ug6KpwUjA4Aihf5ADp0gem0DNw
YlVkCA6Bu7c9IUlE0hwF7RLB7YrryJVJit9AymmUTUUHCQTWW2yBhC8CgYEAxoHS
HGXthin5owOTNPwLwPfU2o7SybkDBKyW69uTi0KxAl3610DjyA/cV2mxIcFlPv1y
HualGd9eNoeCMBy/AUtjzI0K77yeRpjj321rj6k8c8bYWPHH539SiBXLWTY/WQ0w
pxfT3d/Z4QMh5d6p+p5f3UIrXESYQd+fAaG5tNsCgYEAksTdTB4YUT9EsWr6eN9G
jPlclFQUKV3OMvq77bfYvg8EJORz32nnDDmWS7SUjoOtemwutBlMeWbaKk25aMp3
5JNMXuV6apeMJ9Dd8GU7qBUqlIvVK31/96XPvzmnYzWZPqRVwO2HPcRFG3YcJmkg
JmZQyexJvCQ3wFNxiYUm+y0CgYBXQSMhFnCUg4jWbbDcHlnwRT+LnjHrN2arPE3O
eKLfGL6DotmqmjxFaStaRPv2MXMWgAMUsB8sQzG/WEsSaOBQaloAxJJlFIyhzXyE
bi1UZXhMD8BzQDu1dxLI/IN4wE6SDykumVuocEfuDxlsWDZxEgJjWD2E/iXK9seG
yRa+9wKBgEydVz+C1ECLI/dOWb20UC9nGQ+2dMa+3dsmvFwSJJatQv9NGaDUdxmU
hRVzWgogZ8dZ9oH8IY3U0owNRfO65VGe0sN00sQtMoweEQi0SN0J6FePiVCnl7pf
lvYBaemLrW2YI2B7zk5fTm6ng9BW/B1KfrH9Vm5wLQBchAN8Pjbu
-----END RSA PRIVATE KEY-----





-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQbKbSSs2ik
6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5
e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+H
fBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTIN
WniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBC
eVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQg
NQIDAQAB
-----END PUBLIC KEY-----

証明書要求は次のようになります。この特定のCSRには、サーバーの公開キーと、イギリスのロンドンにあり、ドメインを所有しているACME Inc.に関する情報が含まれています。最後に、署名済みのHTTPS証明書は次のようになります。すべての部分が接続されており、互いに一致する必要があります。最後の証明書は、単に例のために生成されたものです。これは、いわゆる自己署名証明書です。これは、承認された認証局によって署名されていないためです。

-----BEGIN CERTIFICATE REQUEST-----
MIICzjCCAbYCAQAwgYgxFDASBgNVBAMMC2V4YW1wbGUuY29tMQswCQYDVQQLDAJJ
VDEPMA0GA1UECAwGTG9uZG9uMRIwEAYDVQQKDAlBQ01FIEluYy4xIDAeBgkqhkiG
9w0BCQEWEWFkbWluQGV4YW1wbGUuY29tMQswCQYDVQQGEwJHQjEPMA0GA1UEBwwG
TG9uZG9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQb
KbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3
OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYO
cfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wm
wZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZ
EUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2
tjtp+LQgNQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAGIQVhXfuWdINNfceNPm
CkAGv4yzpx88L34bhO1Dw4PYWnoS2f7ItuQA5zNk9EJhjkwK8gYspK7mPkvHDbFa
Um7lPSWsm3gjd3pU7dIaHxQ+0AW9lOw5ukiBlO4t3qgt+jTVZ3EhMbR0jDSyjTrY
kTgfuqQrGOQSmLb5XviEtCcN0rseWib3fKIl8DM69JiA2AALxyk7DCkS1BqLNChT
pnbgvtlUhc4yFXNCtwPGskXIvLsCn2LRy+qdsPM776kDLgD36hK0Wu14Lpsoa/p+
ZRuwKqTjdaV23o2aUMULyCRuITlghEEkRdJsaXadHXtNd5I5vDJOAAt46PIXcyEZ
aQY=
-----END CERTIFICATE REQUEST-----

example.com



-----BEGIN CERTIFICATE-----
MIIDjjCCAnYCCQCJdR6v1+W5RzANBgkqhkiG9w0BAQUFADCBiDEUMBIGA1UEAwwL
ZXhhbXBsZS5jb20xCzAJBgNVBAsMAklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNV
BAoMCUFDTUUgSW5jLjEgMB4GCSqGSIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20x
CzAJBgNVBAYTAkdCMQ8wDQYDVQQHDAZMb25kb24wHhcNMTYwNDE5MTAzMjI1WhcN
MTcwNDE5MTAzMjI1WjCBiDEUMBIGA1UEAwwLZXhhbXBsZS5jb20xCzAJBgNVBAsM
AklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNVBAoMCUFDTUUgSW5jLjEgMB4GCSqG
SIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20xCzAJBgNVBAYTAkdCMQ8wDQYDVQQH
DAZMb25kb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCb7Tfo7Y+V
RBsptJKzaKTo7pNjLr5mxqzmgCTcaKgYuXVFb02LyRqCp2cPr0S3b2bW+Xk4g+wG
hbc5ZvVoFbl7cnTH2mtcjVb9+m+4/02ascFQ3gRLXtWWJGl9Ufdod88Lysqm/ca8
dg5x86Yw34d8FmVR4okqzpzlaZJV2dkHRHhQBa5DfRocQFWq2uGAepgMGiRV7T8f
jCbBkQhBMg1aeII4VHlSmEl/mc/yWMZuY/E1Od9v+IdL9yGNyMXtMYwbfp7sQGhC
KNkRRCzkgEJ5V586cUsrmMvH4EL/9f4U3MHIOKVO36Xbwj/dk3W6OFqTvdgVtaOM
tHa2O2n4tCA1AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBABwwkE7wX5gmZMRYugSS
7peSx83Oac1ikLnUDMMOU8WmqxaLTTZQeuoq5W23xWQWgcTtfjP9vfV50jFzXwat
5Ch3OQUS53d06hX5EiVrmTyDgybPVlfbq5147MBEC0ePGxG6uV+Ed+oUYX4OM/bB
XiFa4z7eamG+Md2d/A1cB54R3LH6vECLuyJrF0+sCGJJAGumJGhjcOdpvUVt5gvD
FIgT9B04VJnaBatEgWbn9x50EP4j41PNFGx/A0CCLgbTs8kZCdhE4QFMxU9T+T9t
rXgaspIi7RA4xkSE7x7B8NbvSlgP79/qUe80Z7d8Oolva6dTZduByr0CejdfhLhi
mNU=
-----END CERTIFICATE-----



このプロセスを、cPanel、Linux、FreeBSD、およびWindowsで実行される実際の手順で説明します。これは、すべてのタイプの証明書に適した普遍的なプロセスです。無料のDV証明書を取得する場合は、Let's Encrypt and Cloudflareで説明されている他の手順に従ってください。

ステップ1.秘密鍵と証明書要求を作成する


次の例では、互換性が高いため、2048ビットRSA証明書を使用します。サーバーがインストールされているプロバイダーがECCをサポートしている場合（たとえば、HerokuまたはAWSサービスを使用しない場合）、ECCを使用することをお勧めします。

cpanel


  1. ホストのcPanelにログインします。
  2. “Security” “SSL/TLS”.


    “Security” cPanel ( . )

  3. “SSL/TLS Manager”. “Private Keys (KEY)” .


    “SSL/TLS Manager” cPanel ( . )

  4. “Generate, Paste or Upload” “Private
    Key”. 2048 “Generate”.


    (“Private Key”) cPanel ( . )

  5. , :


    cPanel ( . )

  6. “Private Keys”, :


    “Private Keys” cPanel ( . )

  7. “SSL/TLS Manager”. “Certificate Signing Requests (CSR)” .


    “SSL/TLS Manager” cPanel ( . )

  8. “Generate Service Request”. . ( !), “Domains”, , HTTPS. ( example.com ); www ( www.example.com ). “Generate”.


    “Create New Certificate Signing Request” cPanel ( . )

  9. CSR, :


    CSR cPanel ( . )

  10. 「証明書署名要求」セクションに戻ると、そこに新しいCSRが表示されます


    。cPanelの「証明書署名要求」セクションには、新しく生成されたCSRがあります（大きなバージョンを参照）


Linux、FreeBSD


OpenSSLがインストールされていることを確認してください。これを確認できます：

openssl version

そうでない場合は、コンソールを開いてプラットフォームにインストールします：


：その後、チームとして秘密鍵とCSRを生成する

openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr

秘密鍵が生成され、あなたは、CSRのためにいくつかの質問に答える必要があります。正しくすべての質問に答える（彼らはあなたの署名付き証明書に表示するためにオープンになります！）、に特別の注意セクション「一般名」 （たとえば、FQDNサーバーまたはYOUR名）。これは、HTTPS証明書を要求しているドメイン名と正確に一致する必要があります。最上位ドメイン（）のみをそこに含めます。証明機関は通常、サブドメイン自体を追加します（つまり、）：

Generating a 2048 bit RSA private key
........................+++
................................................................+++
writing new private key to 'example.com.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.

example.comwwwwww.example.com

Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:London
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:ACME Inc.
Organizational Unit Name (eg, section) []:IT
Common Name (eg server FQDN or YOUR name) []:example.com
Email Address []:admin@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


  1. “Start” → “Administrative Tools” → “Internet Information Services (IIS) Manager”. . “Server Certificates” :


    “Internet Information Services (IIS) Manager”. “Server Certificates”. ( . )

  2. “Create Certificate Request” .


    “Create Certificate Request” . ( . )

  3. , “Common Name”, . “Next”.


    . ( . )

  4. “Cryptographic Service Provider.” “Bit length” 2048 . “Next”.


    “Bit length” 2048 . ( . )

  5. CSR “Finish”.


    CSR “Finish”. ( . )


2. HTTPS


Webサイトの証明書を取得するには、まず、証明書の販売者から選択したタイプ（DV、OV、EV、1つのサイト、複数のサイト、サブドメイン-上記参照）のHTTPS証明書のローンを購入します。プロセスの最後に、選択したドメインの購入したローンを使用する証明書のリクエストを送信する必要があります。行-----BEGIN CERTIFICATE REQUEST-----とを含むすべてのCSRテキストを提供するように求められます（つまり、ダウンロードフィールドに挿入します）-----END CERTIFICATE REQUEST-----。EVまたはOV証明書が必要な場合は、証明書を要求している法人を指定する必要があります。また、この会社を代表しているという事実を確認する追加の書類を求められる場合があります。次に、証明書レジストラがリクエスト（およびすべての関連ドキュメント）をチェックし、署名済みHTTPS証明書を発行します。

HTTPS証明書の取得


ホスティングプロバイダーまたはHTTPSレジストラーは異なる登録手順を持っている場合がありますが、一般的なロジックは同じです。

  1. HTTPS証明書の販売者を見つけます。
  2. 証明書の種類（DV、OV、EV、1つのサイト、複数のサイト、サブドメイン）を選択して、バスケットに追加します。ご希望の支払い方法を選択して、支払いを行ってください。
  3. ドメインの新しいHTTPS証明書をアクティブにします。フォームに貼り付けるか、証明書に署名するリクエストを含むファイルをアップロードできます。システムは、CSRから証明書情報を抽出します。
  4. « » (“Domain Control Validation”, DCV) — , HTML ( HTML ), TXT ( DNS ). DCV .
  5. , HTTPS. .


証明書に自分で署名し、この権限を認証機関に与えないことも可能です。暗号化の観点から、自己署名証明書は他の証明書と違いはありませんが、ブラウザーはそれを信頼しませんが、セキュリティ警告が表示され始めるため、これはテスト目的に適しています-誰でも偽装できますが、これは信頼できる第三者によって検証されませんユーザーがWebサイトを信頼する場合、ユーザーはブラウザーに例外を追加できます。これにより、証明書が保存され、今後のアクセスでサイトが信頼されます。

たとえば、自己署名証明書は上記で公開されています-ドメインexample.comで使用でき、その期間は機能します。

OpenSSLを備えた任意のプラットフォームで自己署名証明書を作成できます。

openssl x509 -signkey example.com.key -in example.com.csr -req -days 365 -out example.com.crt

証明書が生成されたら、サーバーにインストールする必要があります。1つのプロバイダーからホスティングとHTTPS登録サービスを所有している場合（多くのホスティングプロバイダーもHTTPS証明書を販売しています）、Webサイトの新しいHTTPS証明書をインストールしてアクティブにするための自動手順が有効になる場合があります。別の場所でホストしている場合は、証明書をダウンロードし、それを使用するようにサーバーを構成する必要があります。

ステップ3. WebサイトのHTTPS証明書をインストールする


cpanel


  1. 「SSL / TLSマネージャー」に戻ります。「証明書（CRT）」をクリックして、新しい証明書をインポートします。


    cPanelの「SSL / TLSマネージャー」セクション（ラージバージョンを参照）

  2. “Paste, Upload or Generate” “Certificate”. , HTTPS, “Browse”.


    HTTPS cPanel ( . )

  3. HTTPS, , . “Save Certificate”.


    HTTPS cPanel ( . )

  4. , .


    HTTPS cPanel ( . )

  5. “Certificates (CRT)”, HTTPS.


    “Certificates” cPanel HTTPS. ( . )

  6. “SSL/TLS Manager”. “Install and Manage SSL for your website (HTTPS)”, - .


    “SSL/TLS Manager” cPanel. ( . )

  7. “Install an SSL Website”. “Browse Certificates” HTTPS. - ( ) “Certificate” “Private Key”.


    “Install an SSL Website” cPanel. ( . )


でWebサイトにアクセスできることを確認しますhttps://www.example.com。すべてが正常に機能する場合は、おそらくHTTPトラフィックをHTTPSに永続的にリダイレクトする必要があります。これを行うに.htaccessは、サーバーのルートディレクトリにあるファイル（Apache Webサーバーがある場合）に数行を追加します。ファイルが場合は既に存在している、あなただけの行を挿入し、単に既存のディレクティブの後。

RewriteEngine On

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

.htaccessRewriteCondRewriteRuleRewriteEngine On

Linux、FreeBSD


生成された秘密鍵（example.com.key）、証明書署名要求（example.com.csr）および有効なHTTPS 証明書（）を適切なディレクトリに配置しexample.com.crtます。


ファイルはルートに属し、権限設定によって保護されている必要があります600。


アパッチ


サイトでHTTPSを有効にするには、次を実行する必要があります。


をチェックすることから始めmod_sslます。オペレーティングシステムに応じて、オプションのいずれかが機能します。

apache2 -M | grep ssl
または
httpd -M | grep ssl

mod_sslインストールされている場合、あなたはそのような答えを得るでしょう... ...または類似した何か。インストールされていないか機能しない場合は、これを試してください：

ssl_module (shared)
Syntax OK






Apache構成ファイル（httpd.conf）を編集します。



 Listen 80 Listen 443 <VirtualHost *:80> ServerName example.com ServerAlias www.example.com Redirect 301 / https://www.example.com/ </VirtualHost> <VirtualHost *:443> ServerName example.com Redirect 301 / https://www.example.com/ </VirtualHost> <VirtualHost *:443> ServerName www.example.com ... SSLEngine on SSLCertificateFile/path/to/signed_certificate_followed_by_intermediate_certs SSLCertificateKeyFile /path/to/private/key # Uncomment the following directive when using client certificate authentication #SSLCACertificateFile /path/to/ca_certs_for_client_authentication # HSTS (mod_headers is required) (15768000 seconds = 6 months) Header always set Strict-Transport-Security "max-age=15768000" ... </VirtualHost> # intermediate configuration, tweak to your needs SSLProtocol all -SSLv3 SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS SSLHonorCipherOrder on SSLCompression off SSLSessionTickets off # OCSP Stapling, only in httpd 2.3.3 and later SSLUseStapling on SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb:/var/run/ocsp(128000)

この構成は、前述のMozilla SSL Configuration Generatorを使用して生成されました。これを使用して、構成の関連性を確認します。証明書と秘密キーの正しいパスを編集します。ここに示されている構成は中間設定で生成されています-最適な設定を選択する前に、各設定の制限とブラウザーの構成について読んでください。

HTTPからHTTPSへのリダイレクト、および非wwwドメインc www（SEOタスクに有用）からのリダイレクトを処理するために、コードにいくつかの変更が加えられました。

Nginx


nginx（nginx.conf）構成ファイルを編集します。


この構成は、前述のMozilla SSL Configuration Generatorを使用して生成されました。これを使用して、構成の関連性を確認します。証明書と秘密キーの正しいパスを編集します。ここに示されている構成は中間設定で生成されています-最適な設定を選択する前に、各設定の制限とブラウザーの構成について読んでください。

ジェネレーターは、HTTPからHTTPSへのリダイレクトを処理するコードを自動的に生成し、最初にHTTP / 2サポートをアクティブにします！


  1. “Start” → “Administrative Tools” → “Internet Information Services (IIS) Manager”. . “Server Certificates” .


    “Internet Information Services (IIS) Manager”. “Server Certificates”. ( . )

  2. “Complete Certificate Request” .


    “Complete Certificate Request” . ( . )

  3. ( example.com.crt ), . - “Friendly name”, . “Personal” (IIS 8+). “OK”.


    . ( . )

  4. , “Server Certificates”.


    “Server Certificates”. ( . )

  5. . “Sites” -, HTTPS. “Bindings” .


    - “Bindings”. ( . )

  6. “Site Bindings” “Add”.


    “Add”. ( . )

  7. :
    • “Type”: “https”
    • “IP address”: “All Unassigned”
    • “Port”: “443”

    “SSL Certificate” HTTPS . “OK”.


    “HTTPS” HTTPS. ( . )

  8. - HTTP HTTPS.


    - HTTP HTTPS. ( . )



アドレスバーの近くに、警告サインと「接続は安全ではありません！ページの一部は保護されていません（画像など）。」これは、証明書を誤ってインストールしたことを意味するものではありません。ローカルサーバーとリモートサーバーの両方のすべてのリソース（イメージ、スタイルシート、スクリプトなど）へのリンクがで始まらないことを確認してくださいhttp://。すべてのリソースは、ルート（に関連したアドレスを指している必要があり/images/image.png、/styles/style.cssなど。D.）または（現在のドキュメントに対する相対../images/image.png）、またはそれで始まる完全なURLでなければなりませんhttps://よう<script src="https://code.jquery.com/jquery-3.1.0.min.js"></script>。

これらのヒントは、混合コンテンツの警告を解決するのに役立ち、ブラウザには感嘆符のないロックされた南京錠が表示されます。

サーバーテスト


HTTPSを使用してサーバーを構成して起動したら、Qualys SSL Server Testを使用して構成のセキュリティを確認することを強くお勧めします。構成の包括的な評価を含むWebサイトをスキャンし、潜在的な弱点を特定し、推奨事項を作成します。彼のヒントに従って、サーバーのセキュリティ構成をさらに改善してください。

更新


証明書は一定の期間-通常は1年間有効です。それを更新する最後の瞬間を待たないでください-更新の期限が近づいているときにレジストラはあなたに電子メールを送信し始めます。最初の通知を受け取ったらすぐに新しい証明書を発行します。手順はほぼ同じです。証明書署名要求を作成し、新しいHTTPS証明書を取得して、サーバーにインストールします。証明書は署名した瞬間から失効しますが、有効期限は前の証明書の失効から1年後に設定されます。したがって、両方の証明書が有効になる期間があり、古い証明書の有効期限が切れてから1年が経過します。この重複の間、あなたは確認する機会があります古い証明書の有効期限が切れる前に新しい証明書が正常に機能することにより、ウェブサイトの円滑な運用が保証されます。

フィードバック


サーバーが危険にさらされている場合、または誰かがプライベートキーにアクセスできる可能性があると思われる場合は、現在のHTTPS証明書をすぐに取り消す必要があります。レジストラによって手順は異なりますが、一般的には、レジストラの特別なデータベースで侵害された証明書を非アクティブとしてマークし、新しいHTTPS証明書を発行することになります。もちろん、誰もあなたになりすますことができないように、できるだけ早く現在の証明書を失効させ、セキュリティ違反の原因を見つけて修正した後にのみ新しい証明書をインストールしてください。レジストラに助けを求めることができます。

暗号化しましょう


ウェブサイトLet's Encryptを引用しましょう：

Let's Encrypt — , (CA), . Let's Encrypt Internet Security Research Group (ISRG) .

Let's Encrypt:


  • Let's Encrypt .
  • 自動化
    - Let's Encrypt , .
  • 安全性
    Let's Encrypt TLS, , - .
  • 透明性
    発行または取り消された証明書はすべて、公的に記録され、誰でも閲覧できるようになります。
  • 開放性
    自動発行および更新プロトコルは、他の人が使用できるオープンスタンダードとして公開されます。
  • コラボレーション
    インターネットの根底にあるプロトコルと同様に、Let's Encryptは、どの組織にも管理されていないコミュニティの利益のための共同プロジェクトです。

Let's Encryptを利用するには、ホスティングまたはサーバーでアカウントを適切に構成する必要があります。暗号化を行って、短期的な証明書を発行します。これは、定期的に更新してHTTPS Webサイトを運用し続ける必要があります。

仕組み


Let's Encryptと他の認証機関のパフォーマンスにはいくつかの重要な違いがあります。上記の最初の3つのポイントに従って、これらの違いは次のとおりです。


制限事項


暗号化はDV証明書のみを発行します。 OVおよびEV証明書はサポートされていません。現在、それらをサポートする予定はありません。証明書は1つまたは複数のドメインに対して発行されますが、現時点ではサブドメイン（ワイルドカード）を持つ証明書はありません。詳細については、Let's Encrypt FAQを参照してください。

Let's Encryptの自動モードでは、意図的で意図しない悪用からインフラストラクチャを保護するために、使用にいくつかの制限が課されます。使用強度の制限は十分に高いため、数百のドメインを自由に使用できる一般ユーザーでも使用できません。ただし、HTTPS証明書を非常に大規模に管理する場合は、これらの制限に慣れる必要があります。

古いクライアントとエキゾチックなクライアント（Windows XP SP3より前）はサポートされていません。詳細については、互換性ページを参照してください。

HTTPS証明書を実際に暗号化してみましょう


cpanel


  1. ホストのcPanelにログインします。
  2. 「セキュリティ」セクションまでスクロールダウンし、「cPanelで暗号化しましょう」をクリックします。


    cPanelのセキュリティセクション。（ラージバージョンを参照）

  3. 「cPanelで暗号化しましょう」セクションにいます。ドメイン名（の両方をチェックexample.comしてwww.example.com）をした後、「発行複数」をクリックしてください。


    両方のドメイン名を確認し、「複数発行」をクリックします。（ラージバージョンを参照）

  4. . ( - www , www , “Subject Alt Name” (SAN) HTTPS. “Issue”. , , — .


    “Issue” . ( . )

  5. , . «», .


    , . ( . )

  6. さらに、「Let's Encrypt certificatesを使用したドメイン」を参照してください。、- https://。


    Let's Encrypt。（。）



Let's Encrypt— Certbot。-—。


Certbot for Let's Encrypt（。）


現在、WindowsにはIISの公式クライアントはありませんが、いくつかの回避策があります。

Let's EncryptのネイティブWindowsクライアントを作成することを目的とするいくつかのプロジェクト：


クラウドフレア


Cloudflareは、コンテンツ配信ネットワーク（CDN）、Webサイトのセキュリティサービス、およびDDoS攻撃に対する保護を提供するサービスです。無料の料金を含むすべての料金プランで無料のHTTPS証明書を提供します。これはDV Cloudflare Universal SSLの集合証明書です。一意のHTTPS証明書を取得するには、ビジネス料金に切り替える必要があります。

証明書を取得するには、アカウントを作成し、Webサイトを作成して「暗号化」セクションに進みます。

CertSimple


CertSimpleはEV証明書のみを提供します。DV HTTPS証明書市場でLet's Encryptが行ったように、EV HTTPS証明書市場に革命をもたらし、通常は遅くて負担が大きい組織を検証するためのより迅速で簡単なプロセスを提供しました。その利点は次のとおりです。


- HTTPS IP-


ハンドシェイクプロセスの性質のため、同じIPアドレス上の仮想ホストはTLSの問題です。クライアントはHTTPリクエストのヘッダーにドメイン名を含めるため、仮想ホストは機能しますが、HTTPSを使用する場合、最初のHTTPリクエストが送信される前にTLSハンドシェイクが発生します。ヘッダーを含む。そのため、クライアントに接続する前に、サーバーはどの証明書を提示するかを知らないため、構成ファイルの最初の証明書が表示されます。そしてもちろん、この証明書はリストの最初のTLSサイトでのみ有効です。

この問題を回避する方法はいくつかあります。TLSを使用して各ドメインの一意のIPアドレスを取得するか、1つの証明書ですべてのドメインを登録します。両方の方法は実際にはあまりよくありません-IPv4アドレススペースは既に使い果たされています.1つの大きなHTTPS証明書にすべてのサイトを登録すると、新しいサイトをサーバーに追加するときに、証明書全体を複数のドメインに再発行する必要があります。

この制限に対処するために、TLSプロトコルの拡張がServer Name Indication（SNI）という名前で開発されました。サーバーとクライアントの両方でサポートされている必要があります。 SNIサポートは今日広く普及していますが、可能性のあるすべての顧客との互換性の保証があなたにとって重要である場合、まだ100％保証されていません。

SNIの開始に関する詳細Apache、nginx、およびIIS（8+）については、関連ドキュメントを参照してください。

有用なリソース


Source: https://habr.com/ru/post/J332294/

More articles:


All Articles