サーバ証明書・TLS/SSL通信・HTTPS暗号アルゴリズム 実践解説【高校情報１・情報セキュリティ】
■■はじめに■■
サーバ証明書、HTTPS、TLS/SSL技術はITパスポートレベルでも扱われていますが、あまりにも抽象的なので、試験の為の勉強（実務でほとんど役に立たない）と感じています。
高校情報１も範囲ではありますが、サーバ証明書を実際にCSR生成から行ったことのある方は、ほとんどいないと思われます。
教科書レベルの内容と実際の実務に役に立つレベルに大きな乖離があるところでもあります。
本質を伝えたいので、今回は私自身でドメイン取得からサーバ証明書の発行まで自腹で行い、ハンズオン動画にしました。
レベルが高いように思われるかもしれませんが、これでも「基礎」です。
この流れを理解出来たら、高校情報１では、暗号化関連でどんな問題が出ても応用が利くので満点取れると思います。
２０分の動画ですが、製作は２６時間かかりました。。。
■■動画■■
■資料ダウンロード■
情報教育の底上げが目的なので、資料を修正して、
学校・塾（営利目的含む）の授業等で利用して頂いて問題ありません。
私への連絡不要ですが、利用する際には、
YouTubeチャンネル・情報Ⅰ動画教科書・IT用語動画辞典を
紹介してもらえると嬉しいです。
https://toppakou.com/info1/download/99_資料/11_SSL_TLS.pptx
◆◆文字おこし◆◆
先に問題です。
認証局CAにサーバ証明書を発行してもらうための
署名要求のことを何というでしょう。
回答ありがとうございます。
答えはCSRです。
今日はTLS/SSLとHTTPS通信について詳しく説明したあと
ドメイン取得、OPENSSLを使ったCSR作成
サーバ証明書を実在するCAから実際に取得していきます。
HTTPSのプロトコルを用いることで通信が暗号化されるというのは有名な話です。
正確に言うと、HTTPSはTLS/SSLという技術を使ったWebアクセスプロトコルです。
後から詳しく説明しますが、TLSはSSLの進化版で、SSL自体は暗号化したデータが第三者に見破られるPOODLEという脆弱性が発見されているので、現在は、ほとんどTLSに置き変わっています。
こちらのサイトでTLS/SSLの導入割合が分かりますがほとんどがTLSへ移行済みということが分かります。
SSL自体は非常に歴史があるので、実際はTLS通信を行っていても、SSL通信と呼ばれることも多いです。
ここではTLS通信という呼び名で説明させていただきます。
はじめにＨＴＴＰとＨＴＴＰＳ通信のざっくりとした比較を説明します。
まずＴＬＳを使わないＨＴＴＰ通信は
Ｗｅｂブラウザで見たいＷｅｂページのＵＲＬのリンクをクリックしたときに
ＷｅｂサーバとのＴＣＰコネクションの確立が行われます。
ＷｅｂブラウザからＳＹＮフラグの送出、それを受け取ったＷｅｂサーバからＳＹＮ/ACKフラグの返答、それを受け取ったＷｅｂブラウザはＡＣＫフラグの返答をします。
この一連の流れを３ウェイハンドシェイクと言います。
そしてその後に欲しいＷｅｂページの依頼をＷｅｂサーバにおこない、Ｗｅｂサーバはデータを返却します。
では、ＨＴＴＰSの場合は、３ウェイハンドシェイクの後にTLSハンドシェイクを行います。
このTLSハンドシェイクのなかで暗号化に使う鍵を交換します。
そしてHTTPリクエストとレスポンスの通信が暗号化され改ざんの検知ができます。
更に掘り下げてTLSの通信を説明していきます。
TLS通信には、事前にサーバ側にサーバ証明書を登録しておく必要があります。
サーバ証明書はCA認証局と呼ばれる信頼できる第三者機関に発行してもらう必要があります。
その発行のながれを説明していきます。
まずWebサーバーの管理者は、公開鍵と秘密鍵の鍵ペアを生成します。
そして、CSRという依頼書の様なものに公開鍵を添付して送付します。
認証局は申請内容を審査して問題なければ、サーバ証明書を発行し依頼者に送付します。
あとでこの部分をハンズオンします。
Ｗｅｂサーバの管理者はＷｅｂサーバにサーバ証明書を登録します。
ここで発行されるサーバ証明書の中身のレイアウトを説明していきます。
ＨＴＴＰＳ通信しているときにブラウザのＵＲＬ欄に鍵マークが出ますが、鍵マークをクリックすることで、そのＷｅｂサーバのサーバ証明書を確認することもできます。
証明書のフォーマットは Ｘ．５０９ バージョン３（ＲＦＣ５２８０）という仕様で定められています。
構造は「署名前証明書」「証明書の署名アルゴリズム」「認証局の署名」という大きく３つで構成されています。
署名前証明書は
バージョン情報
シリアル番号
署名アルゴリズム
発行者（認証局）
有効期間（開始時刻、終了時刻）
発行対象の企業名など
発行対象の公開鍵
拡張領域
で成り立っています。
認証局による署名は
署名前証明書のハッシュ値をとって証明書の署名アルゴリズムを用いて認証局の秘密鍵で暗号化したデータを署名として追加したものになります。
では、ＴＬＳ通信の流れを説明していきます。
前提として、Ｗｅｂサーバには認証局が発行したサーバ証明書が登録されています。
３ウェイハンドシェイクのあと
そしてＷｅｂサーバは認証局が発行してくれたサーバ証明書を返却します。
送られてきたサーバ証明書の署名前証明書の部分をハッシュ関数に入れてハッシュ値を算出します。
サーバ証明書に添付されいる署名を認証局の公開鍵で復号して、ハッシュ値に戻します。
そのハッシュ値を突き合わせて一致していれば、信頼できるサーバだということが分かります。
実際のデータのやり取りは、暗号化と復号が公開鍵暗号方式より高速で行える共通鍵暗号方式を使います。
クライアントは、共通鍵のもとになるランダムな値をを生成して、サーバ証明書に添付してあったサーバの公開鍵で暗号化します。その、暗号化した「鍵のもと」のデータをＷｅｂサーバに送付します。
受け取ったサーバは自らの秘密鍵で復号します。
クライアントパソコンとＷｅbサーバはその、「鍵のもと」から暗号通信に使う共通鍵を生成します。この流れを鍵交換と言います。
次に実際のデータの送受信になります。
ＷｅｂサーバからクライアントパソコンにＷｅｂページのデータを送るパターンで説明します。
送りたいデータを先ほど生成した共通鍵で暗号化します。
同時にその送信する平文データのハッシュ値も求めます。
そして、暗号化したデータとハッシュ値をセットで相手に送信します。
受信側は、共通鍵でデータを復号して平文にします。これでほしいデータは得られたのですが、途中改ざんされていないか確認するために、復号したデータのハッシュ値を求めて一緒に送られてきたハッシュ値と突き合わせて一致していれば改ざんされていない、つまり完全であることが判断できます。
まとめると、ＴＬＳを用いることによって
・認証局が発行するサーバ証明書によって通信したいサーバが本物であることが証明できます。
・鍵交換技術、共通鍵暗号を用いることで通信内容の暗号化ができます。
・ハッシュ値を使うことで改ざんされていないかの完全性のチェックが行えます。
ＴＬＳやＳＳＬ内部では４つの暗号技術が使われています。
一つ目は、暗号処理に使う鍵を交換する鍵交換技術
二つ目は、Ｗｅｂサイトが本物であることを保証する認証技術
三つ目は 端末とＷｅｂサイトの間を暗号化する共通鍵暗号技術
四つ目は データの改ざん検出するためのハッシュ値を生成するハッシュ関数技術
この４種類の技術を組み合わせたものを暗号スイートといいます。
暗号スイートには特有の表記方法があります。
ＴＬＳまたはＳＳＬの後にアンダースコアを挟んで鍵交換方式、認証技術、ＷＩＴＨを挟んで、共通鍵暗号方式、ハッシュ関数と続きます。
先ほど少し触れましたが、現在SSLは「POODLE」という脆弱性が発見されており、暗号化したデータが解読できる可能性があります。
そのPOODLEの脆弱性に対応した、TLSが現在の主流になっていますが、いくつかバージョンがあります。
2021年現在バージョン1.2が多く、1.3が続いていますが徐々に1.3に以降されつつあります。
TLS1.3の特徴は安全性の向上と高速化です。 ※P129
安全性の向上について
TLS1.2では、安全な暗号方式のほかに互換性の為に残しておいた暗号方式がありますが、TLS1.3ではそれが廃止されています。
具体的にはTLS1.3では鍵交換技術としてRSAが廃止されています。共通鍵暗号方式としてAES-CBCが廃止されています。
高速化について、TLS1.2は２往復だったのに対して、TLS1.3は１往復になっています。
――――――――――――
ここからは、画像貼り付けは無いので、動画でご確認ください。
それでは今話した知識をベースに実際に実務に役に立つレベルでハンズオンをしていきます。
①ドメイン取得（toppakou.tokyo）
②OpenSSLを使ったCSRの生成
⓷サーバ証明書の申請（有料のものにします）
④発行された証明書の中身の確認と中間証明書について
＝＝＝＝＝＝＝＝＝
今話した内容だけでも結構な分量になったので、
Ｗｅｂサーバへの導入編は別途作成予定です。
まずドメイン取得です。ドメイン販売業者は沢山ありますが、今回はムームードメインを使わせて頂きます。
ユーザー登録は終わっているところからスタートします。
ドメイン取得・移管メニューで ドメインを検索を選びます。
自分が取得したいドメインを入力し、検索します。ここではtoppakouという文字だけを検索してトップレベルドメインまでは指定しません。
今取得可能なものにはカートに追加のボタンが表示されます。
.ｊｐなどメジャーなものほど値段が高い傾向があります。
今回はtoppakou.tokyoのドメインを実際に購入します。
カートに追加すると ドメイン設定画面が表示されるのでＷＨＯＩＳ公開情報を選択します。ＷＨＯＩＳはドメイン検索サービスで、yahoo.co.jpの場合はこのような感じで事業者名や住所などが表示されます。
登録者情報を公開するを選択すると自分の家の住所が表示される可能性があるので、ここではムームードメインの情報を代理公開するにしておきます。
ネームサーバーはレンタルサーバのＤＮＳを使う場合は該当するＤＮＳサーバを選んで、独自ＤＮＳを構築する場合は今はまだ使用しないにしておきます。
レンタルサーバ ロリポップの契約にデフォルトチェックが入っているので、ここでは外しておきます。
クレジットカード情報などを入れて次のステップへをクリックします。
問題なければ規約に同意します にチェックを入れて取得するボタンをクリックします。
取得が完了しましたとでたらドメイン取得は完了です。
＝＝＝＝＝＝＝＝＝＝＝
次に、toppakou.tokyoのドメインについて秘密鍵を作成していきます。
作成にはOpenSSLというアプリケーションを使います。
Windowｓ用も存在しますが、以前仮想環境でＷｅｂサーバ構築動画をアップしていますが、その流れで自動的にＯｐｅｎＳＳＬもインストールされているので、今回は以前構築したLinuxサーバで行います。
opensslのコマンドの後のgenrsaはアルゴリズムにＲＳＡを用いるという意味です
その次の-des3 は秘密鍵自体の暗号化にトリプルＤＥＳを用いるということです。
秘密鍵自体を暗号化する必要ない場合はこの部分は不要です。
ＷｅｂサーバのApacheからこの秘密鍵を指定しますが、再起動のたびにこのパスワードが聞かれます。秘密鍵を漏洩から守るという観点ではパスワードはあった方がいいですが、ずっと何年も再起動しないことが多いのでここで、久しぶりにサーバ再起動して秘密鍵のパスワードを紛失したみたいなネット記事もあったので、パスワードの運用はあらかじめ決めておきましょう。またWindowsのＡｐａｃｈｅの場合は、このパスワードがあったらうまく動かないらしいです。
-out の後は秘密鍵名称を入れます。
秘密鍵の拡張子は.keyが用いられることが多いのでここではhimitsu.keyという秘密鍵名にしています。
最後の2048は鍵長です。こちらは、ＣＳＲを受け付けてくれる認証局から2048bitという指示が明記されていたのでそうしています。1024だと暗号強度の観点か受け付けてもらえないらしいです。
エンターを押すと 先ほどトリプルＤＥＳを指定したので秘密鍵のパスフレーズを決める必要があります。これを忘れてしまうと、サーバー証明書申請からやり直すことになるので気をつけてください。
ちなみに、パスワード自体を解除したい場合は
openssl rsa -in [秘密鍵名] -out [秘密鍵名]
のコマンドで解除することも可能です。
今回はテスト専用なので、公開できていますが、実際商用で使う際は絶対に秘密鍵は漏らさないように気を付けましょう。
次に、ＣＡに証明書発行依頼するためのＣＳＲの生成をしていきます。
あれ？公開鍵作っていないんじゃないと思われる方もいると思いますが、ＣＳＲ作成時に公開鍵も添付される形で生成されます。
実際Ｗｅｂサーバで指定するのは、秘密鍵と公開鍵が添付されている認証局が発行した証明書になりますので公開鍵単独での生成は行っていません。
openssl の後に res -new -key と入力し 先ほど生成した秘密鍵名を入力します。
その後の -out の後に出力するＣＳＲのファイル名を指定します。ＣＳＲの拡張子は.csrになります。
先ほど秘密鍵にパスワードを指定している場合は、パスワードを聞かれます。
次から対話形式で必要事項を入力していきます。
CSRの作成 – さくらのサポート情報 (sakura.ad.jp)
項目 内容
国名（C) 申請組織の国名
都道府県名（S/ST) 申請組織の事業所住所の
「都道府県名」（英名）
市町村名（L) 申請組織の事業所住所の
「市町村名」（英名）
※東京は 23 区
組織名（O)
組織単位名（OU) 部署名
コモンネーム（CN) 実際に接続する
URL の FQDN
その後、Ｅｍａｉｌ、パスワードの設定はそのまま入力せずにエンターを押します。
これでＣＳＲが生成されました。
中身を見ると訳の分からない文字がならんでいますが、
このコマンドを使うことで先ほど入力したコモンネームなどちゃんとした形でＣＳＲの中身を確認することができます。
openssl req -noout -text -in [CSR名]
それでは、今作ったＣＳＲを実在する認証局 ＣＡに送って、サーバ証明書を発行してもらいます。
今回はこちらのＣｅｃｕｒｅＣｏｒｅ株式会社のサービスを使わせてもらいました。
SSLサーバ証明書ならSecureCore(セキュアコア)
https://www.securecore.co.jp/
先にサーバ証明書にはいくつか種類があるので説明しておきます。
https://qiita.com/testnin2/items/51697ad87f896f154a80
https://knowledge.sakura.ad.jp/2988/
まず、ＤＶ証明書はドメイン認証を行うものです。ドメインの使用者が、Web サイトの「本物」の運営者であることまでが関連付けられていないということがリスクとしてあります。
OV証明書 は、ドメイン使用権の認証に加え、サーバーを運営する組織の存在を認証したものになります。
ＥＶ証明書は OV よりもさらに踏み込んで組織の存在を認証するものです。
銀行などのホームページにアクセスするとＵＲＬ欄が緑になったりしますが、これはＥＶ証明書が使われていることを示しています。
実在証明という意味での違いはありますが、どの証明書も暗号化は行われ暗号強度に関しては違いはありません。
今回はＤＶ証明書で実践していきます。ＤＶ証明書はＯＶ、ＥＶと比べて比較的安値です。
Let’s Encryptという無料の証明書もあるのですが、これは申請がＣＳＲではなく独自のスクリプトを使っての申請方法となり、サーバ証明書申請の勉強としてはＣＳＲを用いた方式の方が適している為、販売代理店のＳＳＬＢＯＸ経由で、ＣｏｒｅＳＳＬの有料の物を購入します。
格安SSL証明書サービスのSSLボックス｜サイトシール付きSSLが1,650円(税込) (sslbox.jp)
こちらから会員登録は終わっているところからスタートします。
メンバー管理画面のＳＳＬボックス管理の、新規取得から他社サーバで利用するを選びます。
証明書の種類が選べるので、今回はDV証明書のCoreSSLを選び利用規約を確認し申込内容を確認するをクリックします。
新規取得画面で、コモンネーム欄に、先ほどＣＳＲを作成したコモンネームと一致するようにドメインを入力します。
ＣＳＲ入力欄に先ほどOpenSSLで生成したＣＳＲファイルの中身をコピペし、次の画面に遷移します。
ＣＳＲの内容が読み込まれて表示されます。
申請登録情報欄を入力します。
ここで気を付けてほしいのが承認用メールアドレスが、今回申請するドメインのメールアドレスになっていることです。
下の方にもう一つメールアドレスを入れる欄があったのでそちらにメールが届くと思いこのアドレスはとりあえず、admin@toppakou.tyokyoと存在しないものを選んだのですが、実はここで選んだメールアドレスに、承認メールが来ます。
ドメインに紐づくメールサーバの実在確認をしているようです。
一度登録して何も音沙汰無いので調べたら、この項目がかなり重要ということが分かりました。
別で使っているレンタルサーバにtoppakou.tokyoのドメインを一時的に紐づけてadminのメールアドレス作って、メールを再送してもらいました。
メールの再送は専用ボタンがあるので、問い合わせなくても大丈夫です。
他の会社でも同じ感じらしいので、ここは気を付けてください。
必要項目を入力し登録します。
認証キーがさっき選んだ証明書を発行したいドメインのメールアドレスに飛んでくるので、認証キー設定すると即サーバ証明書申請が発行されました。
これが発行されたサーバ証明書になります。
ＣＳＲで入力した項目や認証局の署名も一緒に入っています。
メモ帳で開くと分けわからないですが、拡張子を.crt にすることで証明書画面で見ることができます。
さらに一緒に中間証明書も発行されます。
サーバー証明書は階層構造で例えば、toppakou.tokyoの公開鍵にたいしてＳＳＬＣＯＲＥが承認します。さらにＳＳＬＣＯＲＥの公開鍵が信頼できることを他のＣＡが承認します。
最後はパソコンにあらかじめインストールされているルートＣＡに行き着けば証明書の信頼性が担保できます。
ただ、ルートＣＡに行き着かない場合は、証明書が信用できないということでブラウザが警告を出します。
サーバに今回の証明書を登録する際は、中間証明書も一緒に登録します。クライアントからアクセスがあった場合で証明書がチェーン状につらなっている場合は、中間証明書も一緒にクライアントに返却します。
ＩＴパスポート、基本情報、高校情報科の内容ではサーバ証明書申請は、ＣＡに依頼するくらいしか書かれていないですが、実際はこのような手続きが必要になります。
試験問題を解く際も、イメージが湧きやすくなったと思うので、役に立てていただけると嬉しいです。
最後までご視聴ありがとうございました。