画像をクリックすると、Amazonの購入ページが別窓で開きます。
| 2022年03月04日 | 公開。 |
リスト1のスケッチの中には、GmailのSMTPサーバーとSSL/TLS通信をするのに必要なルート証明書が埋め込まれています。(リスト3参照)
/**
* Google Trust Services LLCのルート証明書。有効期間が2036年6月22日で終わるので、その日より後では、
* SECURE_MODEをdefineしていると、このスケッチは動作しない。
*/
const char ROOT_CERT[]=
"-----BEGIN CERTIFICATE-----\n"
"MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH\n"
"MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM\n"
"QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy\n"
"MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl\n"
"cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB\n"
"AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM\n"
"f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX\n"
"mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7\n"
"zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P\n"
"fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc\n"
"vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4\n"
"Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp\n"
"zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO\n"
"Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW\n"
"k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+\n"
"DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF\n"
"lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV\n"
"HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW\n"
"Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1\n"
"d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z\n"
"XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR\n"
"gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3\n"
"d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv\n"
"J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg\n"
"DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM\n"
"+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy\n"
"F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9\n"
"SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws\n"
"E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl\n"
"-----END CERTIFICATE-----\n";このルート証明書がどういう働きをしているかや、ルート証明書の文字列をどの様に取得したのかについて、次の節から説明します。
リスト1のスケッチでは、SSL/TLSプロトコルでSMTPサーバーと通信を行なっています。このSSL/TLSというのは、インターネット上で情報を安全にやり取りするために、データを暗号化して通信するプロトコルです。
SSL/TLSで通信する事により、本当に通信したい相手になりすました、悪意のある第三者と通信してしまう事を防いだり、通信の内容を通信経路のどこかで盗聴されて、通信内容が漏洩してしまう事を防いだり、通信内容を悪意のある第三者に改竄されてしまう事を防いだりできます。(図14参照)
WebサイトのURLに、http:で始まるものが減ってきて、だんだんhttps:で始まるものが増えてきている事に気が付いている人は多いでしょう。
HTTPは、WebブラウザがWebサーバーと通信する際に使うプロトコルです。URLがhttp:で始まっている場合、そのWebサイトへのアクセスは、HTTPで行なわれます。HTTPでは、通信内容が平文のまま(暗号化されずに)やり取りされるため、セキュリティ的に問題がありました。
最近では、通信のセキュリティ確保のため、HTTPに代わって、通信の内容がSSL/TLSにより暗号化されるHTTPSが多く使われる様になってきたのです。HTTPSでは、HTTPと同様の通信を、SSL/TLSにより安全に行なえます。URLがhttps:で始まる場合は、そのWebサイトとの通信がHTTPSで行なわれます。
Webサイトの閲覧だけではなく、メールのやり取りに関しても、通信のSSL/TLS化が進んでいます。
1ページで紹介したSahara's WebLogの2016年4月4日付けの記事では、SSL/TLSを使わずにGmail経由でメールを送信するスケッチが載っていますが、この事から、2016年4月時点では、GmailのSMTPサーバーに、SSL/TLSを使わずにアクセスできた事が分かります。しかし、2022年3月現在では、GmailのSMTPサーバーにアクセスするには、SSL/TLSによる通信が必須になっています。
SSL/TLS通信では、クライアントがサーバーに接続すると、サーバーはクライアントにサーバー証明書を送信します。
サーバー証明書は、サーバーの運用者の情報(サーバーのドメイン名等)、サーバーの使う公開鍵、証明書の期限、その証明書を発行した認証局の情報、認証局の署名等を記載したデジタル証明書です。(図15参照) このサーバー証明書によって、サーバーが正規の運用者によって運用されている事が確認でき、また、その後行われる通信の暗号化ができるのです。
サーバー証明書は「書」という言葉が付いていますが、紙の書類ではなく、実際には電子的なファイルです。
サーバー証明書は、認証局と呼ばれる、デジタル証明書を発行する機関により発行されています。認証局は、サーバー証明書において、証明書内に埋め込まれている公開鍵が、証明書に記載されたドメイン名のサーバーの所有者の物であると証明します。
クライアントは、受け取ったサーバー証明書を検証して、正規の運用者が運用しているサーバーにアクセスしている事(すなわち、正規の運用者になりすました第三者と通信していない事)を確認します。この作業をサーバー認証といいます。
サーバー認証の際に、クライアントは、サーバー証明書内の認証局の署名を確認します。その署名が、実在し、信頼できる認証局の署名なら、サーバー証明書が信頼できます。
ただし、サーバー証明書が、認証局になりすました何者かが発行した物なら、信用する訳にはいきません。そのため、クライアントは、サーバー証明書に書いてある認証局の情報を元に、認証局の証明書をインターネット経由で取得し、その証明書により、信用できる認証局である事を確認します。
認証局の証明書は、たいていの場合、他の認証局により発行されており、その証明書を発行した認証局の署名が付いています。
この様に、認証局の信頼性を他の認証局が証明し、証明した認証局の信頼性をさらに他の認証局が証明し…と永遠に続けていれば、いつまでたってもサーバーの信頼性が証明できないのですが、実際には、認証局の証明書の連鎖は、途中で終わります。この様子を図16で説明しています。
この図は、クライアントがサーバーAに、インターネット経由でSSL/TLSプロトコルで接続し、サーバーAからサーバー証明書の提示を受けた所を表わしています。
クライアントは、サーバー証明書を検証し、サーバーAが、サーバーAになりすました別のサーバーではない事を検証します。(サーバー認証) そのためには、まず、自分がアクセスしているサイトのドメイン名(URLの一部)と、サーバー証明書に記載されているドメイン名が一致しているかを確認します。
また、提示されたサーバー証明書が、信頼できる認証局で発行されたものであるかどうかを確認する必要があります。デジタル証明書は、OpenSSLというソフトを使えば、誰にでも作れてしまうため、サーバー証明書も、信頼のおける認証局が発行した物でないと、信用できないのです。
参考:サーバー証明書を自分で作る方法は、次の参考リンクのリンク先で説明されています。
サーバー証明書にはその証明書を発行した認証局の情報が載っており、さらにその認証局の署名が入っています。図16の例では、サーバーAのサーバー証明書(ピンク色の証明書)を見ると、認証局Cが発行した証明書である事が分かりました。
参考:サーバー証明書内の認証局の署名は、認証局の証明書に記載されている認証局の公開鍵と組み合わせる事で、サーバー証明書が、確かにその認証局により発行された事を確認するために使われます。それでは、認証局Cの信頼性はどうやって確認するかというと、認証局Cの証明書を見ればいいのです。サーバー証明書に認証局CのURLが記載されていますので、そこから認証局Cの証明書(図中の水色の証明書)が得られます。
認証局Cの証明書を見ると、その証明書は認証局Bによって発行されている事が分かりました。認証局Bが信頼できる認証局でないと、認証局Cも信用する訳にはいきませんので、認証局Bの証明書(図中の黄色の証明書)を取得します。
認証局Bの証明書を見ると、その証明書が認証局Aによって発行されている事が分かりました。認証局Aが信頼できる認証局でないと、認証局Bも信用する訳にはいきませんので、認証局Aの証明書(図中の薄緑の証明書)を取得します。
認証局Aの証明書を見ると、その証明書は認証局A自身で署名されている事が分かりました。この様に、自分自身が発行した証明書を自己署名証明書と呼びます。
この様に、認証局の証明書の連鎖をさかのぼって行くと、最後は自己署名証明書で終わります。この様に、認証局の証明書の連鎖の最上位にいて、自己署名証明書を自身の証明書として使っている認証局を、ルート認証局といいます。また、ルート認証局の発行する自己署名証明書を、ルート証明書といいます。
一方で、他の認証局から証明書を発行してもらう事で、自らの正統性を証明している認証局を、中間認証局といいます。
ルート証明書はルート認証局が自分自身で発行した物なので、他人から、その正統性が保障されている物ではありません。よって、ルート証明書により、ルート認証局が、不正な証明書を発行をしない、信用のおける認証局である事を保障する事はできません。
ただし、ルート認証局は、定期的に第三者機関の審査を受けており、その審査結果を公表しています。その結果により、ルート認証局の信頼性を確認する事ができます。(下記参考リンク参照)
世界中に認証局は数多くありますが、図16を見れば分かる様に、認証局はツリー構造をなしており、上位の認証局(図で上の方に載っている認証局)になるほど数が減ります。ルート認証局になると、数はかなり減りますので、あらかじめクライアントのユーザーが、信頼できるルート認証局のルート証明書を収集しておき、その証明書は無条件に信頼する事で、証明書の連鎖の全体の信頼性を確認する事ができます。
クライアントのユーザーがあらかじめルート認証局のルート証明書を収集するというと大変な様ですが、実際には、インターネットにアクセスするソフト(Webブラウザーやメーラー等)をダウンロードすると、そのダウンロードパッケージの中に、主要なルート証明書の一覧が含まれています。よって、実際には、ユーザーが自らルート証明書を収集する必要は、ほとんどの場合ありません。(Webブラウザに組み込まれたルート証明書の閲覧の仕方は、Webブラウザに登録されているルート証明書を見るという記事に書いているので、そちらもご覧ください。)
参考:さらにいうと、証明書には期限があるので、収集したルート証明書の期限が切れる前に、新しい証明書に更新する必要があるのですが、Webブラウザ等をアップデートすれば、最新のルート証明書に更新されます。
この様に、通常の場合はインターネットにアクセスするソフトに、ルート証明書の一覧が付いてくるのですが、ESP8266等に自作のプログラムを載せて、インターネットにSSL/TLS通信で接続する場合は、自分でルート証明書を用意する必要があります。今回の場合、とりあえずGmailにアクセスできればいいので、Gmailのサーバー証明書を認証するのに必要なルート証明書のみを用意しました。それがリスト3のルート証明書なのです。
参考1:組込機器の場合、パソコン用のソフトの様に、主要なルート認証局のルート証明書を全て組み込んでしまうと、記憶容量や処理速度的や手間の点で不利になります。また組込ソフトの場合、特定のサーバーと通信するアプリケーションを作る場合が多くあります。こういった観点から、リスト3の様に、必要最低限のルート証明書のみをプログラムに組み込む事が多くあります。
参考2:ここでは説明しませんでしたが、SSL/TLS通信ではサーバー認証のために、電子署名を用いて、サーバーがサーバー証明書内の公開鍵に対応する秘密鍵を所有している事の確認も行います。
今回は、ルート証明書の説明をしました。次回は、リスト3のルート証明書の取得方法に付いて説明する予定です。続きを書くのはボチボチと。
