More than 3 years have passed since last update.

サーバー認証まわりの基礎（独自SSL証明書、DNSなど。Amazon CloudFrontでの例。）

Last updated at 2020-05-02Posted at 2020-05-01

いつもいつも忘れてしまうので、備忘のため書いておくことにしました。本当に忘れっぽくて困る・・。

サーバー認証とは

サーバー認証とは、クライアントが、これから接続する相手であるサーバーの正当性を確認することです。

正確には、「サーバーの公開鍵」が正当なものかを確認することです。

クライアントは、サーバーからサーバー証明書を受け取ります。

このサーバー証明書には、以下が記載されています。

クライアントは、サーバーの公開鍵が信頼できるものか確認するために、サーバーの公開鍵に認証局のお墨付きが付いているかを確認します。

具体的には、クライアントは以下を行います。

認証局の公開鍵と、4に書かれてある暗号化方式をもとに、3を復号します。（もともと認証局の秘密鍵で暗号化されているわけですから、認証局の公開鍵で復号できるわけです。）
4に書かれてあるハッシュ関数で、1と2をまとめてハッシュ化します。
両者が一致しているか確認します。

一致していれば、サーバーの公開鍵は認証局が署名した（信頼した）ものである、ということをクライアントは確認できます。

サーバーには、こういったサーバー証明書がインストールされていないと、クライアントからまともなサーバーだと信じてもらえず、TLS通信を開始することができません。

サーバー証明書は、「サブドメイン名」と「ホスト名」を含むFQDNに対して発行されます。

例えば

といった感じです。

また、このように個別で指定するのではなく、

といったように、ワイルドカードを指定することもできます。この場合、「*.example.com」に対してサーバ証明書が発行されます。

ただ、ワイルドカード指定の証明書では、example.comの事業者の実在性は証明できるものの、

userCompany1.example.com

のuserCompany1の実在性までは証明できません。userCompany1の実在性を証明する必要があるならば、ワイルドカードで表現されたドメイン名の証明書ではなく、

userCompany1.example.com

のサーバー証明書を取得する必要があります。

こういった理由から、独自ドメインの独自SSL証明書（サーバー証明書）というものが必要となります。

例えば、AWSのCloudFrontでは

*.cloudfront.net

のサーバー証明書はAWSが取得済みですので、CloudFrontが払い出してくれる

xxxx.cloudfront.net　（xxxxはCloudFrontディストリビューションごとに異なる）

を呼び出し元に公開するのであれば、サーバ証明書についての手続きは不要です。

しかし、これではxxxxのコンテンツオーナーの実在性は証明されません。xxxxのコンテンツオーナーが自社の実在性を証明したければ、独自のドメインを取得し、このドメインのサーバ証明書を取得する必要があります。

例えば

userCompany1.com

のドメインを取得して、このドメインのサーバ証明書を取得するのです。

そして、このドメインをDNSで名前解決できるように、

userCompany1.com 　→　 xxxx.cloudfront.net

という紐付けを表現するCNAMEレコードを登録します。

（なお、xxxx.cloudfront.netとIPアドレスを紐づけるAレコードについては、当然ながらAWSが作成してくれます。）