この記事は、私のように知識や技術を曖昧にしか理解していない
ひよこエンジニアにとって、少しでも役に立つ内容になることを
祈って書いていたりいなかったりする。
エンジニアにとってバグやエラーは日常茶飯事で、
常に遭遇する事象であるが、
蓋を開けてみればなんてことない話だったりすることがほとんどだ。
私のように知識ないゆえに、理解が浅いゆえに
苦しんでいるエンジニアのようになりたくなければ、
あなたも基本的な仕組みから理解を深めていくことをお勧めする。
Webサイトをhttps化する際に躓いたこと
現在、携わっているクラウド上にWebアプリケーションを
構築するプロジェクトで、一部のページへのアクセスをhttpsに
する必要があり、apacheの設定を変更した際の躓きについて紹介したいと思う
そもそもhttpsとは？
ブラウザからインターネットを介して、特定のWebサイトにアクセスする際に
用いられる通信規格は「http」であるが、httpsはhttpによる通信を行う際に、
情報を暗号化するプロトコルである。
仕組みとしては、公開鍵暗号化方式によるクライアント-サーバ間の認証と
認証後の共通鍵暗号化方式による通信により実装できる。
httpsの具体的な仕組みとは？
実際に一部のページへのアクセスをhttpsにする場合に、
apacheの拡張モジュールであるmod_sslを用いて、
opensslコマンドで秘密鍵と対になる公開鍵を作成し、
プライベート認証局によるサーバ証明書（.crtファイル）を作成する。
秘密鍵はサーバ側に保持し、サーバ証明書には公開鍵情報が記載される。
クライアントがサーバにアクセスすると、サーバは
クライアントに対してサーバ証明書を渡し、
クライアントは、サーバのルート認証局が正規な認証局であるか、
サーバ証明書そのものが改ざんされていないか、
サーバのドメインとSanSが一致しているか、を確認し、
問題なければクライアントのDH公開鍵をサーバの公開鍵で暗号化してサーバに渡す。
サーバは暗号化されたクライアントのDH公開鍵を秘密鍵で復号化し、
認証を行う。
移行は、共通鍵を生成しサーバとクライアント間の通信を
共通鍵を用いて暗号化・復号化することで安全な情報通信を確立する。
どこで躓いたのか？
今回のWebアプリケーションは、クラウド上で構築しており、
Linuxサーバ内のファイアウォールシステムと、
クラウドプラットフォームが提供するWAFの２段階の
セキュリティが設定されていた。
systemctlコマンドでapacheのステータスを確認すると、
httpsとhttpのポート（443，80）がlistenとなっており問題なし。
systemctlコマンドでfirewallのステータスを確認すると、
disableとなっており、こちらも問題なし。
apacheのアクセスログやエラーログを確認しても、
問題はなし。
フレームワークのアプリケーションログを確認すると、
httpsでアクセスしたログの履歴が出力されていない。
つまり、apacheに対するリクエストが届いていない。
apacheにリクエストが届く前にブロックされているということは、
サーバのfirewallではなく、インスタンスに対するFirewall（WAF）によって
通信が遮断されている可能性がある。
ここで、クラウドプラットフォームのコンソールから
セキュリティを確認すると、通信を許可するポートが
「http：80」と「ssh：22」のみであることが分かった。
「https：443」ポートが解放されていないために、
インスタンスレベルで通信が遮断され、apacheまでリクエストが到達
していないことが分かった。
まとめ
正直、このレベルの躓きはよほどクラウドサービスに対する理解が浅い
初心者エンジニアしか遭遇しないと思われますので、あまり読者の参考には
ならないかと思いますが、自分への戒めや今後の成長に対する覚悟も込めて
記録として残しておきたいと思う。