ApacheでHTTPS通信を実現する(WEBサーバ構築編)

はじめに

WEBサーバーの基本設定をして簡単な静的コンテンツを作成し、ブラウザーからSVへhttp通信して
コンテンツを参照する動きをwiresharkで確認したら、通信内容が本当に丸見えで驚いた笑

そこで通信を傍受できないように暗号化通信（HTTPS）の設定をしたのでそのメモ。
Apacheには、データをSSL(TLS)で暗号化するhttpsが実装されている。

認証局の話も出て決まってしまってますが、認証局は単体で後ほど投稿します

環境

OS:Rocky Linux 8.6 (RedHat系)
Apache/2.4.37

NAME="Rocky Linux"
VERSION="8.6 (Green Obsidian)"

[root@sv ~]# httpd -v
Server version: Apache/2.4.37 (rocky)
Server built:   Nov  8 2022 11:30:54

SSLモジュールのインストール

ApacheでHTTPS通信を実現するためには、WEBサーバー側でモジュールmod_sslをインストールする必要がある。

デフォルトで既にインスト―ル済みのようだが、一応次のコマンド叩き確認

[root@sv ~]# rpm -qa | grep mod_ssl
mod_ssl-2.4.37-51.module+el8.7.0+1059+126e9251.x86_64
[root@sv ~]# dnf install -y mod_ssl
メタデータの期限切れの最終確認: 6:51:19 時間前の 2022年12月04日 16時15分55秒 に実施しました。
パッケージ mod_ssl-1:2.4.37-51.module+el8.7.0+1059+126e9251.x86_64 は既にインストールされています。
依存関係が解決しました。
行うべきことはありません。
完了しました!

モジュールの確認

[root@sv ~]# cat /etc/httpd/conf.modules.d/00-ssl.conf 
LoadModule ssl_module modules/mod_ssl.so

一応デーモンの状態確認

[root@sv ~]# systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2022-12-04 15:46:42 JST; 7h ago

FWの設定

FirewallにHTTPS通信を許可する

[root@sv ~]# firewall-cmd --list-services 
cockpit dhcpv6-client http ssh
[root@sv ~]# firewall-cmd --add-service=https  --permanent --zone=public
success
[root@sv ~]# systemctl restart firewalld.service 
[root@sv ~]# firewall-cmd --list-services 
cockpit dhcpv6-client http https ssh

これでsshの基本設定終わり。
本当に通信が暗号化されたかwiresharkで確認する。

動作確認

Wiresharkを起動し、利用中のNIC(enp0s3)をキャプチャする。
フィルタリング：ip.addr==172.16.1.201 and ssl

CL側のブラウザーでWebサーバーhttps://www.d000.mgt.localにアクセス

どこかのサイト訪問した時に同じような警告画面を見た記憶がある。
この警告画面は、 認証局によってこのWebサーバーが認証されていないことを示唆している。

※認証局とは、Webサイトの正当性を保証する組織

右下の詳細情報クリック。

証明書を確認をクリック。

この証明書をサーバー証明書と呼ぶ。

CLが今からアクセスするSSHサーバーはちゃんとしたサーバーなのか確認が行われる（ホスト認証）。
CLがsshで初めてSVにアクセスすると、一回目だけサーバーが自身を表す公開鍵（finger print）をCLに送る。
サーバーから送られてきた公開鍵をクライアント側のknown_hostsで保存する（/home/yuzo/.ssh/known_hosts）。
2回目以降は、送られてきたSVの公開鍵とknown_hostsを比較し、CLがSVを認証する。

これをホスト認証と呼ぶ。(※この動き理解してないといけないので後で記事にする)

今回のsslではサーバー証明書の中にサーバー自身を表す公開鍵情報が送られてくる。

危険を承知で続行を押すと、サーバー証明書がブラウザーに登録される。

アクセス後、アドレスバーに'https'になっている

鍵のマークの黒い三角の警告マークは、
証明書がブラウザーに組み込まれたが、ちゃんとした証明書じゃないんだよ
という意味。
つまりブラウザーからしてみると、「安心してアクセスしていいサイトじゃない」と警告している。

鍵アイコンをクリックする。

右三角をクリック

詳細を表示をクリック

これらの画面から足元の状況は次の通りと理解できる
①認証が怪しい（CL側からするとサイト自体が安全かどうか確証がない状態）
②しかしCL-SV間の暗号通信に関しては、問題なし

ここからサーバー証明書に関して説明していく

サーバー証明書

以下の画像は、SV証明書がブラウザーに組み込まれたので、
次回以降www.d000.mgt.localにアクセスした場合、警告画面は表示されない。

この仕組みは、sshの仕組みとほぼ同じ。
※sshのホスト認証の図を後でここに貼る。

違う点は、ブラウザーの場合は、SVから送られてきたサーバー証明書（公開鍵）が
ブラウザーに組み込まれるという違いだけ。
（※https通信の全体像を図にしたものを後で張る）

Webサーバーは予め、サーバー自身を表すペアの鍵（①公開鍵 ②秘密鍵）がある。
秘密鍵はSV側で絶対に秘匿しておく必要がある。
公開鍵は外部に公開しても構わない鍵。
HTTPS通信に対応したWEBサーバーはみんなサーバー証明書を持っている。

通信をWiresharkで確認すると、全ての通信が暗号化されていることがわかる

https通信だけの投稿にしようかと思ったが、認証局の話を入れてしまい纏まりがなくなってしまった。
しかしブラウザーってただ送られてきたhtmlファイルを人間が読めるように画面上に表示するだけでなく
世界中の認証局のリストを保有していて、初めて通信するサーバの認証局と照合したりと
裏で色々働いてるんだと思うと、無料で使えてるのが不思議になりますね