はじめに
AWS等のクラウドを用いてインフラ構築を行う際にSSL/TLSを意識せずに、
AWS Certificate Manager (ACM)を利用してなんとなく実装していませんか。
本記事はAWS ACMを用いると本来ユーザがやるべき手順をどのように、
簡略化してくれているのか整理した記事となります。
前提として
AWS Certificate Manager (ACM) とは
一言でいうと、
AWSが管理するSSL/TLS証明書(電子証明書)の発行・管理を自動的に実施してくれるサービスです。
ACMを利用すれば証明書の発行・設定・管理といったプロセスの自動化をしてくれます。
そもそもSSL/TLSとは
一言でいうと、
アプリケーション層で使用されるデータ暗号化プロトコルです。
SSL/TLSは単独で使用するプロトコルではなく、他のL7プロトコルと合わせて利用します。
例：
- HTTP*SSL＝HTTPS(ポート443)
- FTP+SSL=FTPS(ポート990)
SSL/TLSの目的は
通信への攻撃からデータを守ることが目的になります。
※通信に対するセキュリティ対策であり、保存されたデータやストレージへの対策ではありません。
その他具体的な説明は以下記事を参照
SSL/TLSが持つ機能
SSL/TLSには「暗号化」「ハッシュ化」「電子証明書」という3つの技術を兼ね備えており、ACMはその技術の中で「暗号化」「電子証明書」に関連するサービスとなります。
電子証明書とは
主な機能はサイトの実在証明と暗号化であり、
その端末が本物であることを証明するファイルのことです。
より細かく言うと公開鍵が被証明者のものであることを証明してくれるます。
電子証明書はユーザの申請により第三者機関である認証局が発行するファイルであり、
リクエスト先のサーバを本当に実在してなりすまされていないことを保証してくれます。
なお、Web ブラウザと Web サーバー間（サーバー同士でも可能）でSSL/TLS暗号化通信を行うためのファイルとなります。
■デジタル証明書の説明図
参考先：デジタル証明書とは
■デジタル証明書の活用説明図
参考先：デジタル証明書の仕組み
電子証明書の種類/内容
ACMは以下の内「認証局による証明書」に該当します。
ACMを使用するとAWS側が認証局として証明してくれます。
電子証明書の種類
| 証明書の種類 | 証明者 | 概要 |
|---|---|---|
| 自己証明書 | 自分自身 | ・手軽に作成できるが信頼性はない ・自己署名の場合は「この証明書」は信頼されていないとみなされ、ブラウザ上で例外設定が必要になる。 ※ブラウザに登録されているルート証明書から復号できないために発生 |
| 認証局による証明書 | 認証局 | ・証明を行う専門組織である「認証局」が署名する。 ・手間はかかるが、信頼性は高い ・ブラウザに登録されているルート証明書で復号できるため、例外設定は不要 |
電子証明書の内容
| 証明方法 | 証明内容 | 発行方法 | 信頼性 |
|---|---|---|---|
| ドメイン証明 | ドメインの所有権の有無 | メールのみのやり取りで完結できる | 低 |
| 実在証明(法的) | ドメインの所有権の有無+法的にそのサイトの運営者が存在すること | 帝国データバンクへの記載や公認会計士に意見書記載依頼などの上、発行 | 中 |
| 実在証明(物理) | ドメインの所有権の有無+法的、物理的にそのサイトの運営者が存在すること | 厳格なプロセスであり登記情報などを確認の上、発行 | 高 |
AWS Certificate Manager (ACM) が代替してくれる作業
本来であれば電子証明書を作成・管理するのに以下フローが必要になります。
ACMはその全てを代替作業してくれます。
■電子証明書作
1：秘密鍵/公開鍵/CSR(証明書作成要求書)を作成
2：証明書の申請
3：証明書の配置
4：証明書の運用管理
ACMを使わずに手動で電子証明書を作成してみた場合
1.秘密鍵/公開鍵/CSR(証明書作成要求書)を作成
前提として、秘密鍵はOpenSSLを使用して作成をします。
1-1.秘密鍵/公開鍵/CSR作成コマンド実行
以下コマンドにて一括で作成可能
なお、公開鍵は生成されたCSR情報に含まれているためファイルとして出力されません。
openssl req -newkey rsa:4096 -keyout server-key.pem -out server-req.pem
-newkey：RSAで暗号化された新しい秘密鍵とCSRを生成する
-keyout：秘密鍵の出力ファイル名
-out：CSR情報の出力ファイル名
※CSR の用途:認証局 (CA) に提出して、署名済みの SSL/TLS 証明書を取得するために使用します。
上記コマンドに続いてCSR情報の入力
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:TOKYO
Locality Name (eg, city) []:TEST-shi
Organization Name (eg, company) [Internet Widgits Pty Ltd]:test
Organizational Unit Name (eg, section) []:test
Common Name (e.g. server FQDN or YOUR name) []:testname
Email Address []:test@gmail.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:testtest
An optional company name []:ssltest
Country Name：申請組織の国名（JP 固定）
State or Province Name：都道府県名
Locality Name：市町村名
Organization Name：申請組織の名称
Organizational Unit Name：会社名
Common Name：SSL接続に使用したいドメイン名(FQDN)
Email Address：Eメールアドレス
1-2.秘密鍵とCSRの作成確認
以下コマンドにて作成されていることを確認します。
$ dir server*
2024/09/01 08:23 1,826 server-req.pem
2024/09/01 08:21 3,476 server-key.pem
$ type server-cert.pem
-----BEGIN CERTIFICATE REQUEST-----
MIIF4zCCA8ugAwIBAgIU~~~~~~~~~~~~~~~~~
-----END CERTIFICATE REQUEST-----
$ type server-key.pem
-----BEGIN ENCRYPTED PRIVATE KEY-----
NE/jNy+cfaS8rK5zM0fa~~~~~~~~~~~~~~~~
-----END ENCRYPTED PRIVATE KEY-----
2.証明書の申請
認証局による証明書払い出しは以下記事に詳しく記載がありました。
今回は自己認証で証明書払い出しを実施します。
■認証局による証明書払い出し参考先
■自己認証よる証明書払い出し手順
2-1.自己認証用秘密鍵と証明書作成コマンドの実行
以下コマンドで発行する証明書は自己署名のCA証明書となり、信頼性がない証明書になります。
そのため、通常のブラウザからではブラウザが所有しているルート証明書で解決できずデフォルトではHTTPS通信が行えません。
なお、秘密鍵を作成する理由はクライアントからCSRを受領した際に、
デジタル証明書として公開鍵を含めた署名前証明書をCAの秘密鍵で暗号化するため。
※通常の証明書は他の誰かが「この人は本物です」と保証するところ、
自己署名は「私は本物です」と自分で宣言するようなものとなります。
$ openssl req -x509 -newkey rsa:4096 -days 365 -keyout ca-key.pem -out ca-cert.pem
-x509：規格
-newkey：自己認証用の新しい証明書と秘密鍵の作成
-days：証明書の有効期間
-keyout：生成された秘密鍵の出力ファイル名
-out：生成された自己証明書の出力ファイル名
2-2.自己認証作成に必要な情報を求められるため入力
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:TOKYO
Locality Name (eg, city) []:TEST-shi
Organization Name (eg, company) [Internet Widgits Pty Ltd]:test
Organizational Unit Name (eg, section) []:test
Common Name (e.g. server FQDN or YOUR name) []:testname
Email Address []:test@gmail.com
2-3.秘密鍵と証明書の作成を確認
2024/08/30 21:08 2,136 ca-cert.pem
2024/08/30 21:07 3,476 ca-key.pem
$ type ca-cert.pem
-----BEGIN CERTIFICATE-----
MIIF4zCCA8ugAwIBAgIU~~~~~~~~~~~~~~~~~
-----END CERTIFICATE-----
-----BEGIN ENCRYPTED PRIVATE KEY-----
NE/jNy+cfaS8rK5zM0fa~~~~~~~~~~~~~~~~
-----END ENCRYPTED PRIVATE KEY-----
2-4.電子証明書(サーバー証明書)の発行
既存のCAを使用してサーバー証明書を生成します。
$ openssl x509 -req -in server-req.pem -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem
-req -in server-req.pem：CSR情報(サーバの公開鍵入り)
-CA ca-cert.pem：署名に使用する認証局(自己認証)の証明ファイル
-CAkey ca-key.pem：認証局の秘密鍵
-out server-cert.pem：証明書を作成するファイル名
2-5.デジタル証明書の確認
$ type server-cert.pem
-----BEGIN CERTIFICATE-----
MIIF0TCCA7mgAwIBAgITd2rbHkNQgd~~~~~~~~
-----END CERTIFICATE-----
3.証明書の配置
今回はAmazonLinux2023を搭載したEC2インスタンスに対して設定します。
3-1.Apacheのインストール・起動設定
$ sudo yum install httpd
⇒Apatchインストール
$ sudo systemctl start httpd
⇒Apatch起動
$ ps -ax
⇒Apatch起動の確認
$ grep "DocumentRoot" /etc/httpd/conf/httpd.conf
$ vi /var/www/html/index.html
⇒画面表示したいhtmlファイルの作成
$ sudo yum install mod_ssl -y
⇒mod_ssl パッケージのインストール
3-2.Apacheサーバへ発行した秘密鍵とサーバ証明書の格納
以下ディレクトリ作成後は前段で作成した秘密鍵とサーバ証明書を格納します。
$ sudo mkdir /etc/httpd/conf/ssl.key
⇒秘密鍵格納用ディレクトリ作成
$ sudo mkdir /etc/httpd/conf/ssl.crt
⇒証明書格納用ディレクトリ作成。
$ ll /etc/httpd/conf/ssl.key /etc/httpd/conf/ssl.crt
⇒ファイルの存在を確認
3-3.Apacheの設定ファイルの作成
$ vi /etc/httpd/conf.d/ssl.conf
<VirtualHost _default_:443>
ServerName your_domain.com # あなたのドメイン名またはIPアドレス
DocumentRoot "/var/www/html" # ドキュメントルートのパス
SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/server-cert.pem # 証明書ファイルのパス
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server-key.pem # 秘密鍵ファイルのパス
</VirtualHost>
$ sudo systemctl restart httpd
4.証明書の運用管理
証明書の運用管理についてはPJの体制に伴い、定期的な作業が必要となります。
運用管理はシステムや体制によって異なるため本記事からは内容を割愛します。
おわりに
初めてSSL証明書を作成してみましたが、想像以上に面倒でした。
運用管理まで考えると工数が莫大になるので制約はあれどACMは便利だと痛感しました。
参考
その他落ち葉拾い
その他落ち葉拾い
SSL/TLSを利用することで以下のような通信への攻撃を防ぐことができる - 盗聴 - インターネット上で送受信される個人情報や決済情報、Cookieなどの機密性の高いデータを第三者が盗み見する行為のこと - 改ざん - 悪意ある第三者が、ユーザがフォームから送った内容を通信の途中で書き換えること。 - なりすまし - ウェブサイトの運営者になりすました第三者が、ログイン情報や決済情報などを取得し不正に取引を行うこと - 否認 - 行為者が自身のした振る舞いを認めずに否認すること電子署名
目的：なりすまし、否認対策
概要
特定の者のみが保有する暗号化鍵でデータを暗号化することで、
情報の送信元を特定する方法
通信への攻撃例
インターネット通販の流れに沿って確認。
-
インターネット通販サイトに行く(セキュリティリスク：なりすまし)
もし、偽の通販サイトだった際に決済情報が抜き取られる可能性有 -
商品を選びカートに入れる(セキュリティリスク：盗聴)
-
カートに入れた商品を決済する(セキュリティリスク：盗聴)
もし、カート情報や決済情報が抜き取られる可能性有 -
商品を送付するために自分の住所と名前を入力する(セキュリティリスク：改ざん)
もし、送付先情報が変更される可能性有 -
確定ボタンをクリックし商品を購入する(セキュリティリスク：改ざん、否認)
もし、不要な商品に変更される可能性有また、購入した本人の購入をごまかされないようにする。
SSL/TLSの主な機能
暗号化
暗号化の目的は盗聴対策
概要
２者間でルールを取り決め、そのルールに従って通信路上の情報を変更することで、
「2者の間でしか読めないデータ」でやり取りする方法
詳細
- 共通鍵暗号方式
- 暗号化・復号化に同じ鍵を利用する
- 通信する相手の数だけ鍵が必要
- 鍵の配送時に盗聴される可能性あり
- メリット
- 暗号化・復号化処理が高速
- デメリット
- 通信する相手の数だけ鍵が必要であり、鍵の配送時に盗聴される可能性がある
- 公開鍵暗号方式
- 暗号化・復号化に別々の鍵が必要になる
- 別々の鍵を使用するため通信に時間がかかる
- メリット
- 鍵の管理と配布が簡単
- デメリット
- 暗号化・復号化に時間がかかる
■公開鍵暗号化
※参照：公開鍵暗号方式とは？初心者でもわかる公開鍵暗号方式の基礎
- ハイブリッド暗号方式
- 鍵の交換は公開鍵暗号方式(鍵配送時の盗聴リスク対策)
- 鍵交換後のメッセージのやり取りは共通鍵暗号方式
- メリット
- 暗号化・復号化の処理高速化、通信後の鍵廃棄による鍵管理の簡素化
※参照：ハイブリッド暗号方式---共通鍵暗号と公開鍵暗号を組み合わせる
暗号化手順
MAC
MACの目的は改ざん対策
概要
任意のデータと共通鍵を使って、ある関数(MAC関数)を用いて算出した値(MAC値)とそのデータを合わせて送信し、
受信側は受け取ったデータから同じMAC関数を用いて計算し受け取ったMAC値と同じであれば改ざんされていないと考えることができる。
電子署名
目的：なりすまし、否認対策
概要
特定の者のみが保有する暗号化鍵でデータを暗号化することで、
情報の送信元を特定する方法