UPKIサーバー証明書「有効期間47日」時代への備え：ACME自動化の支援と最新アップデート

最後にですね、私からUPKIの最新動向、アップデートのご案内とお知らせをさせていただきます。時間がまずいということでですね、頑張ります。

改めまして、私水元でございます。UPKIの担当をしております。ということで、サーバー証明書の有効期間段階短縮についてというスライドは用意していたんですけれども、3人目だなスライドっていうことでですね、ちょっとこの内容をはしょっていきたいんですけれども、すでにですね、現行200日になっているところで、年度末に100日が控えているという状況でございます。ということでですね、非常に困難を迎える、危機的な状況にあるのではないかということで、そういった現状にあると我々は認識しております。

やはりこう何度もお話がありましたけれども、こう人間が頑張ろうというのでですね、限界が来てしまうということで、我々の基本方針としてもですね、ACMEプロトコルを活用した証明書更新の自動化を推進していきたい。で、この自動化というのはですね、自動販売機ぐらいの自動ではなくって、自動販売機って結構人間の手は介在してると思うんですけど、そういうのではなくって、1回設定してしまうと、見ていればオッケーという、そういった、こう、ピタゴラスイッチのようなですね、自動化をですね、進めていけば、なんとか対応できるのではないかという風に考えておるところでございます。

ですが、そういったことをやっていこうとした時にですね、現場が直面する壁というのが当然ございまして、やっぱりこう技術的にACME導入化するのが難しいぞっていう非互換性ですとか、あとはネットワークですとかセキュリティの都合で、なかなかうまくいかないというところも存在する。で、実際にこううまくできるのかっていうですね、運用手続き面の不安みたいなのも出てくるわけですね。

で、今日頂いたお二方のお話でかなりですね、こう解決への道筋が見えるというか、あ、こういう風にすればなんとかうまくいくんじゃないかなという道筋をですね、感じ取っていただけたのではないかなと思っております。

で、特にですね、集中管理をしてみようですとか、あとはオーケストレーションのツールを入れてみようですとか、そういった形でですね、対処が何とかできるんではないかという風に見通しが立つのではないかという風に考えているところです。

で、今日ご講演いただいたのに加えてですね、私もですね、UPKIで提供するつまずかないための支援サイトということでですね、ACMEプロトコルを用いた証明書発行・更新の自動化への移行を支援するための、ドイングですね、このACMEの証明書管理に初めて触れるような方向けの支援の情報をまとめたサイトというのを作らせていただいております。

でですね、これがUPKIのウェブサイトで出てるんですけれども、是非ですね、ご覧いただけるといいんですが、UPKIのホームページのお知らせのところにも掲載してございますけれども、文字量がですね、なんか新書1冊分ぐらいになってまして、なかなかこう分量が多いので、必要なところをかいつまんで見ていただくというやり方をしていただくのがいいかなと思っております。

で、コンテンツの構成なんですけれども、よくお問い合わせをいただくですね、複数のEABクレデンシャルの扱い、こういったところをどうすればいいのかという手順が書いてあったり、あとはですね、ちょっとずっとお待ちいただいている、WindowsでACMEを使うための手順ですね。そういったところもご案内をさせていただいております。で、win-acmeっていうツールがあって、これは非常に有用なものではあるんですけれども、UPKIで扱おうとすると必ずはまる点があったりとかですね、そういったところを回避できるような文書になっております。ということでですね、是非ご参考にしていただければと思います。また特にですね、よく使われているのではないかなというアプライアンスが結構あるんですけれども、それについてのですね、対応状況みたいなものもいくつか書かせていただいております。10いくつぐらいかな。こちらで調べて、こういった手順のご案内されてるページがありますよというところを記載しておりますので、これもですね、また見ていただければ、お役に立つのではないかなと思っております。

といったところでですね、こういった自動化の支援というのをですね、我々も進めておりますというご案内をさせていただきました上で、最後にですね、事務的な連絡、それからアップデートのご連絡というのをさせていただきたいと思います。

まず、ACMEでのマルチドメインの対応ですね、しばらく皆様にお待ちいただいてたんですけれども、これもできるようになりまして、アカウント作成時、つまりは、ACMEを使いたいよっていう申請をする時に複数のFQDNの設定が可能になりました。8個までということでですね、これで扱えるようになっております。で、certbotのコマンドの例が下に出てるんですけれども、この配分例って書いてあるところをですね、列挙していただければ大丈夫という形になっておりますので、是非ご利用いただければと思います。特にマルチドメインですでに発行していた証明書を、こちらのACMEに移行したいという段では必要になる機能でございますので、ご覧いただければと思います。

これはすでに完了しているものになるんですけれども、RSAの証明書のCAの変更が実施されております。中間CAでございますね。これが変更されております。で、現在このRSAの証明書ですと、クロスルート証明書という形で、ルートからですね、エンドまで4段ということになっていまして、ちょっと設定のお手間がかかるような状況になっているんですけれども、もう近日中に、もう数ヶ月以内という段でですね、Windows以外の各プラットフォームへの搭載というのも進むという風に、かなり大詰めのところまで来ておりますのでですね、もうちょっとだけ時間かかるんですけれども、お待ちいただければと思います。この夏以降にまたがるということはまずないと思っておりますので、これで、かなり設定の手順というのが楽になるのではないかなと思っておるところです。

で、また、今年の9月25日ですね、ここでECDSAのサーバー証明書を発行する中間CAも新しいルートCA配下のものに変更されますということで、こちらもですね、ご記憶いただければと思います。この日以降ECDSAのものを扱う場合には、中間CAが変更になっている、ルートも変更になっているということを覚えておいてください。

で、現在はですね、この新しい中間CA証明書とクロスルート証明書のインストールを忘れずに実施しなければならないんですけれども、ACMEをご利用いただいてる場合には、自動でですね、設定されるようになっていて、ちゃんと結合されたものが認証局から送られてくるという風になっておりますので、そういった意味でもですね、設定ミスを避けるためにもですね、移行できるところは移行していただくといいのではないかなと思っております。

で、先ほどもちょっと触れましたけれども、クロスルート証明書としてインストール必須になっている証明書についてはですね、Google及び各プラットフォームへの搭載作業が進んでおりまして、もう少しでできるはずという段になっております。

で、ですね、現在年2回ぐらいご対応いただくことになっているドメイン所有権の確認ですね。メールを送ってくださいとか、DNSの値を変更してくださいというのが出てるんですけれども、こういった形で3つの方式を現在選択できているんですけれども、2028年の3月15日以降ですね、DNSを変更するというもののみが利用可能に変わるという風にですね、規定が変わっておりますということでですね、ここに至るまでに皆様の方でですね、このDNSを変更するというやり方、認証局から固有値をDNSのTXTレコードに書いてくださいという指定が来るので、それを書くというものなんですけれども、これでお答えをいただけるように、皆様シフトしていっていただきますようお願いを申し上げます。

で、さらにさらにという話なんですけれども、この証明書の有効期間短縮のスケジュールと合わせて、ドメイン審査の有効期間ですね、再審査までの期間というのが短縮されていきます。で、現在だと200日、その次だと100日に短くなるんですけれども、証明書の有効期間がですね、47日になると同時に、その期間がですね、10日間になるということになります。で、実質的にサーバー証明書発行の都度ACMEプロトコルによる各FQDNの自動検証というのが標準となるという風にお考えいただきたくて、こう本当に毎週こうDNSの値を変更してっていう対応はどう考えても難しいぞということでですね、お手間が増えるばっかりではあるんですけれども、早期の移行をですね、ご検討いただければと思っております。

で、最後の事務連絡ですね、請求書毎年送らせていただいておりますけれども、6月末から7月の頭ぐらいを目処に、現在作業を進めておりましてですね、事務も含め、私も封筒詰め頑張りますので、皆さんのお手元に届きましたら、ご対応をお願いいたします。で、1つ、今年からですね、請求の額が変更になっておりますので、こちらご注意いただきますようお願いを申し上げます。新しい額をこちらにあげておる通りです。

時間ギリギリではございましたけれども、私からは以上とさせていただきまして、いくつかですね、質問をいただいてすでにいただいておるところだと思います。これへのご対応をさせていただきたいと思います。

さあ、1番上にあるのは、私の手元でいいねが1番集まっているのはすでに魚根先生にご対応いただいたものですね。ということで、時間がですね、かなり押しているということで、早くせえというご指示が来ておりますので、いいねが多く集まっているものいくつかで、ご回答させていただきたいと思います。

で、まずですね、ACMEでのDNS-PERSISTの標準化はどのような感じでしょうか?ですね、すでにLet's Encryptの方では使えるようにするよという表明がなされておりましてですね、当面、技術的にも規格的にも安定するのではないかなという状況でございます。で、一方でUPKIではどうなるのかっていう話なんですけれども、これですね、認証局が、その辺りの技術的に枯れた感じで、導入しても問題ないとした段階で入ってくるとは思うんですけれども、こちらですね、DNSの取り扱いにかなり注意が必要というものがございまして、DNSへの署名か、DNSSECか、それが必要になってくるという風になってまして、なってたと思うんですけれども、で、一方でそれが失敗するとですね、DNSにかなり影響を及ぼすということで、取り扱いがかなり難しい。AWSとかGCPとかのマネージドのDNSであれば対応してるんでそんなに大変ではないと思うんですけども、自前で運用してるようなところだとかなり大変じゃないのかなというので、トラブルシューティングも難しくなるような状況があるということでですね。ちょっとメリット・デメリットと、その困難さみたいなところも勘案した上で、私どもでの導入というのは検討したいと考えているところでございます。

で、アプライアンス製品にもサーバー証明書を導入しているのですが、こちらも自動化ソリューションで対応することは可能でしょうかという、これですね、作用様、レッドハット様へのご質問だと思うんですけれども、ちょっとですね、マイクを持ってっていただいて、わかんないお話をいただいてもよろしいでしょうか?

はい。アプライアンス製品に導入することはできるかなんですけれども、こちら、一応ご説明いたしました通り、CLIもしくはAPIで証明書更新可能なものについては、導入することができます。ただ、別途スクリプトを開発する必要がありますので、可能であればというか、検証環境をご用意いただくことができればちょっと対応しようかなと考えております。で、あとですね、そのアプライアンス製品のメーカーの方でACME対応をする予定があるものについては、弊社がご紹介したソリューションを使わないで、そのメーカー側のACME対応をしたものを利用して証明書の自動更新を行っていただくことを、私たちはお勧めしております。

ありがとうございます。平田さん、今もちょっとマイクをお持ちして。そうですね、レッドハットの製品の話として対応できるかという回答で良いですかね?

はい、大丈夫です。アプライアンスの製品の名前が書いてないので必ずとは言わないんですけれど、基本的に、外部から操作が可能なものであれば、大体ですね、すでにAnsibleという製品に対応してるものがほとんどになってますので、各社がもう対応してくれてるような状況になってますので、おそらくできるはずです。

はい、ありがとうございます。これは、例えばGUI限定のものでもうまくいったりとかするんですかね。

えっとですね、今現状でGUIでしか操作できないものって減ってると思います。ほとんどなくてですね、API経由で基本的には何かしらの操作ができるであるとか、あとは通常のOSに対してですね、マネジメント経由で何かしらできるものがあるはずなので、はい。そういったものであれば大丈夫です。本当にGUIでしかできないものでしたらすいません。できないかもしれません。

ありがとうございます。こういった形で、去年よりもですね、対応状況というのはだいぶ改善されているという状況にありましてですね、そういったところを注視しつつですね、対応が進められるのではないかというお話ではなかったかと思います。で、そろそろ5分押しということでですね、いい加減にしろという目線が来ましたので、残りの質問についてはですね、別途ご回答をさせていただきますので、恐れ入ります。すぐに回答というのはできないんですけれども、何卒ご了承いただければと思います。

さて、本日はですね、OpenRoamingにて大学Wi-Fiがどう変わっていくのか、また証明書で最初のワンステップを踏み出すところから証明書の効率的な集約管理、さらに広範な情報基盤のオーケストレーションですね、そういったところへの発展をご案内させていただきました。皆様に得るものがあれば幸いでございます。本日はどうもありがとうございました。