ACME プロトコルを利用した UPKI サーバ証明書の自動更新システムの試験的な実装
宇田川 暢
東海国立大学機構 名古屋大学
udagawa@icts.nagoya-u.ac.jp

Experimental implementation of automatic UPKI server certificate renewal
system using ACME Protocol
UDAGAWA Mitsuru
Nagoya Univ., Tokai National Higher Education and Research System
概要
近年、サーバ証明書の有効期限が短縮され続ける傾向にあり、その更新作業に対応する負荷が大きな問題になる懸念がある。学内でサーバ証明書の発行申請に対応する「登録担当者」、および、実際にサーバ証明書の発行申請や設定作業を行う「利用管理者」の負荷軽減を目的とし、ACME プロトコルを用いた自動更新システムの実現可能性の検討を行った。

1

はじめに

2

サーバ証明書発行の自動化

国立情報学研究所より、UPKI 電子証明書発行

2.1

従来のサーバ証明書の発行申請サービスが提供され、加入機関はサーバ証明書やホストの所有証明のみを目的としたクライアント証明書などを利用することができるDV(Domain Validation)サーバ証明書を取得すようになっている。
現在は同サービスで提供されるサーバ証明書（以下、UPKI サーバ証明書）の有効期限は 396

る 場 合 に は 、 サ ー バ 側 で 作 成 し た
CSR(Certificate Signing Request)とともに所とおよそ 13 ヵ月である。これは「2020 年 10 月 1

定のフォームに情報を記載の上、ドメインの日以降は 398 日を超える有効期限を持つサーバ証

Whois 情報に登録されたメールアドレスやドメ明書の発行を許可しない」というように規定がイン名に関連した指定のメールアドレスに送らCA/Browser Forum の Baseline Requirements for theIssuance and Management of Publicly-TrustedCertificates（以下、BR） Version 1.7.5 で改定され、れたメール中のリンク等から当該ホストの所有UPKI サーバ証明書もそれに準拠する必要があるの事実を確認し、サーバ証明書を発行するという方式の有償サービスが一般的であった。また、2010 年代前半ではその費用として年間数千円ためである。
サーバ証明書の有効期限について、以前は最長（単一 FQDN）から数万円（ワイルドカード）

5 年であったが、3 年、2 年と短縮されてきた経緯をサーバ証明書の取得および維持に支払う必要がある。今後さらに有効期限が短縮されることががあった。

予想されるが、有効期限が短くなるにつれて、サ

2.2ーバ管理者がサーバ証明書の更新作業を行う頻度が増し、負荷が増大する。登録担当者として対応する学内の IT 部門についても同様となる。

Let’s Encrypt の登場
2015 年 に Internet Security Research Group 1(ISRG)により、サーバ証明書の提供サービスが開始された。Let’s Encrypt と呼ばれるこのサービスは、そこで、サーバ管理者、登録担当者の双方の負無償で自動化されたサーバ証明書発行手続きによ担を軽減できる自動化されたシステムの実現可能性を検討してみる。

1210

https://www.abetterinternet.org/

り、サーバ証明書の導入を容易にした。

3.5

Order の作成

Let’s Encrypt でのサーバ証明書の取得は、クラACME クライアントはサーバ証明書の発行をイアントと Boulder と名付けられた CA(Certificate

要求する全ての FQDN のリスト(以下、identifiers)

Authority) サ ー バ と の 間 を 、 ACME(Automaticを newOrder エンドポイントに送信する。ACME

Certificate Management Environment)プロトコルとサーバは Order として保存する。

呼ばれる HTTPS 通信により行われる。クライアン

3.6

2

トは主として Certbot が利用されていると思われ3る。

Authorization の作成

ACME サーバは Order の identifiers 中の FQDN
毎に、それぞれの認証結果を記録する Authorization

3

ACME プロトコル

3.1

ACME プロトコルの概要を作成し、それらへのエンドポイントを含めてnewOrder へのレスポンスとして返す。つまり、
一 つ の Order に 対 し て FQDN の 数 だ け

ACME プロトコルは RFC 8555 に規定されていAuthorization が作成される。また、各 Authorization

る。RFC の Draft で存在した ACMEv1 は現在ではには（複数の）Challenge が含まれている。

廃止されており、ACMEv2 が利用されているため、

3.7

Authorization へのアクセス

ACME クライアントがレスポンスに含まれる

本稿では ACMEv2 について解説する。
ACME プロトコルは前述の通り ACME クライ

任意の Authorization のエンドポイントにアクセス

アントから ACME サーバに対するサーバ証明書発

すると、その FQDN の所有を証明するための行の要求からホストの所有の確認、サーバ証明書Challenge の情報が返される。のダウンロードまでのやりとりについて定めてい3.8て、サーバ証明書を取得するまでの大まかな流れ

ACME クライアントは Authorization に含まれる任意の手段（現在は http-01 および dns-01 のみ規定）

は以下のようになる。
3.2

Challenge によるチェック

で FQDN の所有を証明する。http-01 では ACME

Directory 情報の取得

ACME クライアントはまず ACME サーバのプロトコルで規定された場所(URL)から指定され/directory エンドポイントにアクセスし、今後の処たトークンを ACME サーバから読み取れること、理に必要ないくつかのエンドポイントの URL な

dns-01 では DNS の規定されたレコードから指定さどを得る。

れたトークンを ACME サーバが名前解決可能なこ3.3とをもって FQDN の所有証明としている。

nonce の利用

ACME プロトコルでは基本的にリクエストごACME クライアント側で準備が完了した際にとに nonce(Number Used Once)と呼ばれる使い捨てChallenge 用エンドポイントにアクセスすると、の値を利用する。これはリプレイ攻撃を防ぐため

ACME サーバは指定された手段でチェックを行う。に利用され、最初の nonce は Directory 情報に含まチェックの結果として ACME サーバが FQDNれる newNonce エンドポイントから取得し、次回の所有を確認できた場合は、Challenge を valid と以降は ACME サーバのレスポンスに含まれるもの

す る 。 一 つ で も Challenge が valid と な っ たを利用することになっている。

Authorization は valid となる。

3.4

3.9

Account の作成または認証

CSR の送信

ACME クライアントは公開鍵暗号の鍵ペアを全ての Authorization が valid となった後、ACME生成し、公開鍵を newAccount エンドポイントに送クライアントは Order のレスポンスに含まれてい信する。ACME サーバは公開鍵を登録し、利用者た finalize 用エンドポイントに CSR を送信する。の識別に利用する。また、ACME クライアントはCSR に問題が無ければサーバ証明書の作成を行う。

リクエスト改竄防止のため、以降のリクエストでこの時点ではサーバ証明書そのものや、ダウンロ公開鍵と、秘密鍵で行った署名を付与して送信すード方法に関する情報は提供されない。

ることになっている。

3.10 サーバ証明書のダウンロード
ACME クライアントは CSR の送信後、Order のhttps://github.com/letsencrypt/boulder
3 https://github.com/certbot/certbot
2

エンドポイントにアクセスを続け、certificate エイ
ドポイントの URL がレスポンスに含まれた場合に、certificate エンドポイントにアクセスし、サー211

バ証明書の取得を行う。

この新規 OU の扱いに苦慮していたが、本シス

4 ACME プロトコルを利用した UPKI
サーバ証明書取得の検討
4.1

テムの検討中に BR 1.7.9 より OU が廃止となった
ため、OU については考慮する必要がなくなった。
4.7

サーバ証明書作成にかかる時間

経験上、UPKI サーバ証明書は「電子証明書自前提条件

UPKI サーバ証明書の発行を自前の専用サーバ

動発行支援システム」（以下、支援システム）に申と ACME プロトコルにより自動化することを目指

請用 TSV を送信してからサーバ証明書がダウンロし、まず技術的に問題になる可能性となる点につード可能になるまで、およそ数分から 10 分程度のいて洗い出しを行った。

時間が必要になる。Certbot がタイムアウトにならACME クライアントずに発行完了まで耐えられるかについては、

4.2

ACME クライアントを自作すると開発の手間--issuance-timeout オプションで 900 秒など十分にがかかるだけでなく、サポートの面からも現実的大きい値を与えることで解決できると考えた。

ではないため、特に致命的な問題が無い場合は、4.8

支援システム上での状態フラグ

前述の Certbot を利用する前提とした。なお、本稿

UPKI サーバ証明書は支援システムでの申請後では検討および検証に”CertbotACMEClient/1.22.0”にダウンロード用 URL がメール通知され、通常はを利用している。

そのリンク先からダウンロードすることになる。

4.3

しかしながら、今回検討のシステムではそのようACME サーバのエンドポイント URL

Certbot ではデフォルトで Let’s Encrypt の ACMEな処理を行うことが困難なため、支援システムかサーバに接続するようになっている。これについら「サーバ証明書証明書情報一括ダウンロードて独自のエンドポイントを指定することが可能でTSV」（以下、証明書一括 TSV）を取得し、そこかあるかが問題になるが、--server オプションで任意らサーバ証明書を取得することになる。
その場合に、支援システム上で”状態”フラグがに指定できることが分かった。
4.4「発行案内メール送信済み」から変更されないた

CSR の作成

Certbot では与えられた FQDN から CSR を作成するが、DV 証明書用の CSR となるため、UPKIめ、サーバ証明書の失効申請を行うことが不可能になってしまう。

で必要な他の DN の属性値を実行時に指定するこ

これについては対応の仕様が無いため、自動化とができない 。また、UPKI では SANs(Subjectしたとしても通知メールのリンク先から証明書をAlternative Names)の値を CSR に含めることも許可取得する作業を行うように利用者に依頼することされていない。ACME プロトコルでは ACME サーが妥当と思われる。

バ側から送られた秘密鍵をクライアント側が受け

4.9

証明書一括 TSV のダウンロード頻度取ることを明示的に禁止しているため、ACME サ

支援システムから証明書一括 TSV をダウンロ

ーバ側で CSR を作成することも不可能である。

ードする際にレートリミットが存在するため、支これらについては--csr オプションで別途作成

援システムへの申請用 TSV 送信の後、証明書一括した CSR を利用することで解決することとした。

TSV をダウンロードして処理状況を確認する場合

4.5

は、あまり頻繁に支援システムにリクエストが送

SANs の指定CSR に含めることができない以上、なんらかの方法で SANs を ACME サーバに送信する必要があられることが無いように考慮する必要がある。
4.10

検討結果

る。これについては--user-agent-comment オプショ

以上の結果から、Certbot を利用するサーバ証明ンで実行時に指定するしか他に手段が無いと考え書申請システムを作成することが可能だろうといた。

う結論を得た。

4.6

OU(Organizational Unit Name)の判定

部署名を示す OU については事前に UPKI によ

5

ACME サーバの実装って許可されたリストに含まれている必要があり、実際に UPKI サーバ証明書の申請を行う ACME

また、新規 OU の場合は無関係な組織や他者のササーバ（以下、本サーバ）を開発するにあたり、ービス等を誤認させるようなもので無いことが求支援システムとのやり取り部分を作成する必要性められる。

212

などから、以前に作成した「UPKI サーバ証明書管6.3

理用ツール」[1]を拡張する形で実装することとした。

中間証明書について

通常は UPKI サーバ証明書用の中間証明書を指定されたサイトからダウンロードして適用する必本サーバでは ACME プロトコルの全てを実装要があるが、本サーバからのサーバ証明書ダウンするのではなく、実現可能性の検証に必要な部分ロード時に中間証明書を結合してからダウンローに限定した。そのため、前掲のサーバ証明書取得ドさせることで、利用管理者の手間を減らすことまでの流れのうち、Account についてはリクエストが可能となる。

に対して HTTP_CREATED を返すだけのスタブとなっている。また、実際に支援システムに TSV を7

さいごに送るのではなく、TSV 作成に必要情報を取得する

いくつか解決すべき課題があるものの、UPKIのみに留め、ダウンロードさせるサーバ証明書もサーバ証明書の自動更新システムは実現可能であ以前に発行されたサーバ証明書を返すようにしてると言える。

いる。前者は申請のサービスデザインやシステム

ただし、各大学がシステムを導入するよりは、連携が必要なためで、後者は支援システムへの負支援システム側で ACME プロトコルに対応するこ荷や実際には不要なサーバ証明書が多数発行されてしまうことを避けるためである。
結果として期待した通りに動作することが確認できた。とが自然であるように感じる。その場合は、externalAccountBinding を利用した認証をそれぞれの大学が求める認証方法とうまく擦り合わせることが重要であると思われる。

6

本サーバの実装により得られた知見

参考文献

6.1

認証と Account の問題[1] 宇田川、UPKI サーバ証明書管理用ツールの開発、大学 ICT 推進協議会、2019

ACME プロトコルには今のところ実行途中にプロンプトを表示して認証を要求するような仕組みは存在しない。しかし、externalAccountBindingと呼ばれる仕組みを利用し、Certbot の実行時に引数として識別子と MAC キーと呼ばれる値を渡すことが可能となっている。
この仕組みを利用して、事前に別途用意する申請用ページで認証後に必要な値を取得し、利用管理者の認証を行うことが可能になる。
あるいは、初回申請だけ従来の方法で行うこととして、更新時には本サーバでの自動更新を可能にするといった対応も考えられる。この場合はexternalAccountBinding を利用する必要はない。
6.2

処理時間の問題

通常であれば certificate エンドポイントに断続的にアクセスを継続したのち、90 秒後にタイムアウトとして打ち切られるところ、見込み通りオプションによりタイムアウトを延長することで 10分以上も対応することが可能であった。ただし、その間 Certbot の画面出力は変化しないため、利用管理者が処理が進んでいないと判断して Certbotを停止する事態も考えられる。やはり長くてもTSV 送信後 30 秒以内にサーバ証明書のダウンロードが完了できることが望ましいであろう。

213