mTLSで証明書いっぱい出てくるから整理してみた

どうも。CX事業本部Delivery部のえーたん（@eetann092）です。

mTLS（相互TLS認証）を設定する時に、いつ誰が何のために「〇〇証明書」「証明書〇〇」を作成・使用するのか分からなかったため、整理してみました。

mTLSとは？

mTLSは、サーバーとクライアントが相互に認証するしくみです。 相互TLS認証とも呼ばれています。

TLSでは、サーバーからクライアントに渡す「サーバー証明書」のみで認証します。
mTLSでは、サーバー証明書に加え、クライアントからサーバーに渡す「クライアント証明書」も使って認証します。

参考：mTLS（TLS相互認証 / 相互TLS認証）とは - IT用語辞典 e-Words

登場人物

mTLSの流れを説明する前に、登場する用語（と説明に使う図）を整理します。

認証局

ルート認証局

ある認証局が信頼できるかどうかは、その認証局の証明書が上位の認証局によって署名されていることで確認できます。 その上位の認証局が信頼できるかどうかは、さらにその上位の認証局によって……と繰り返していきます。 これではキリがないため、ソフトウェアには信頼できる「ルート認証局」の証明書（＝ルート証明書）があらかじめ組み込まれています。
証明書をたどり、ルート認証局まで行き着いたら検証は無事終了です。

検証については、以下の記事に詳しく書かれています。

ルート証明書

ルート証明書は、証明書を検証する時に、その証明書が信用できるかを確認するために使います。

自己署名証明書

自己署名証明書はその名の通り、自らの身元を証明するために、自分の証明書の署名を自分で行ったものを指します。 ルート認証局が発行するルート証明書も自己署名証明書です。

よく聞く「オレオレ証明書」は、正式な認証局ではなく開発者が勝手に発行する自己署名証明書のことです。

中間CA証明書

中間CA証明書は、ルート認証局以外の認証局が身元を証明するために、上位の認証局から発行してもらうものです。

サーバー証明書

サーバー証明書は、接続時にサーバーがクライアントに渡し、クライアントがサーバーを検証するために使います。

クライアント証明書

クライアント証明書は、接続時にクライアントがサーバーに渡し、サーバーがクライアントを検証するために使います。

証明書署名要求

証明書署名要求は、証明書の発行を認証局に依頼する時に使うものです。 認証局は、依頼者から渡された「証明書署名要求」と「認証局の自己署名証明書」「認証局の秘密鍵」を使って証明書を発行します。

証明書署名要求には、申請者についての情報の他に公開鍵の情報も含まれています。

mTLSの流れ

OpenSSLを使う想定でmTLSの流れを説明します。

手順は以下の記事を参考にしました。

証明書の話に絞って説明します。

認証局の準備

認証局の準備の流れは以下です。

最初に、認証局の秘密鍵RootCA.keyの作成します。

openssl genrsa -out RootCA.key 4096

次に、認証局の秘密鍵RootCA.keyを使い、ルート証明書（自己署名証明書）RootCA.crtを発行します。 本当は証明書署名要求（CSR）を作ってからですが、自分自身に要求して署名するため、-x509オプションで省きました。

openssl req -new -x509 -days 7 -key RootCA.key -out RootCA.crt -subj "/C=JP/CN=eeetann-ca"

以下のコマンドで、ルート証明書RootCA.crtの中身を確認できます。

openssl x509 -in RootCA.crt -noout -text

出力は以下のような形式です。ルート証明書（自己署名証明書）は公開鍵を含むことが分かります。

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: xxxxxxxxxxxxxxxxxxxx
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=JP, CN=eeetann-ca
        Validity
            Not Before: Jul 20 09:17:52 2022 GMT
            Not After : Jul 27 09:17:52 2022 GMT
        Subject: C=JP, CN=eeetann-ca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         xxxxxxxxxxxxxxxxxxxxxxx

サーバー証明書の準備

サーバー証明書の準備の流れは以下です。

最初に、サーバーがサーバーの秘密鍵server.keyを作成します。

openssl genrsa -out server.key 2048

次に、サーバーがサーバーの秘密鍵server.keyを使い、証明書署名要求server.csrを発行します。

openssl req -new -days 7 -key server.key -out server.csr -subj "/C=JP/CN=hoge"

今回は中間認証局ではなくルート認証局に直接証明書の発行を依頼するとします。 ルート認証局が「証明書署名要求server.csr」と「認証局の自己署名証明書RootCA.crt」「認証局の秘密鍵RootCA.key」を使い、サーバー証明書を発行します。

openssl x509 -req -in server.csr -CA RootCA.crt -CAkey RootCA.key -days 7 -set_serial 01 -out server.crt -sha256

クライアント証明書の準備

クライアント証明書の準備は、サーバー証明書とそんなに変わりません。 流れは以下です。

最初に、クライアントがクライアントの秘密鍵client.keyを作成します。

openssl genrsa -out client.key 2048

次に、クライアントがクライアントの秘密鍵client.keyを使い、証明書署名要求client.csrを発行します。

openssl req -new -days 7 -key client.key -out client.csr -subj "/C=JP/CN=hoge"

今回依頼する認証局はサーバーと同じ認証局ということにします。 認証局が「証明書署名要求client.csr」と「認証局の自己署名証明書RootCA.crt」「認証局の秘密鍵RootCA.key」を使い、クライアント証明書を発行します。

openssl x509 -req -in client.csr -CA RootCA.crt -CAkey RootCA.key -days 7 -set_serial 01 -out client.crt -sha256

接続

実際に接続する際のざっくりとした流れは以下です。

クライアントとサーバーは、お互いの証明書を認証局をたどって検証し、信頼できるかを確認できてからやりとりします。

参考：

• mutual-TLS(mTLS, 2way TLS)相互認証の仕組み ~クライアント認証とトークンバインディング over http | SEの道標
• 【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜 | SEの道標
• 【図解】クライアント証明書(https,eap-tls)の仕組み ~シーケンス,クライアント認証,メリット~ | SEの道標
• Getting certificates ready in AWS Certificate Manager - Amazon API Gateway
• mTLSとは？| 相互TLS | Cloudflare