ウェブサイトの信頼性を担保する認証局とブラウザベンダーで構成される「CA/Browser Forum」において、セキュリティ向上を目的に、TLSサーバ証明書（サイトの身元証明と通信暗号化のための電子証明書）の最大有効期間を段階的に47日間へ短縮する方針が決定されました。UPKIサーバ証明書を運用する国立情報学研究所（NII）もこれにしたがい、下記のスケジュールで有効期間を短縮することを公表しています。

有効期間が47日になると年に7〜8回の更新が必要となり、従来の手動更新では更新漏れによるサービス停止リスクや作業コストの増加が懸念されます。これに対応するため、NIIではUPKIサーバ証明書をACME（Automatic Certificate Management Environment）プロトコルで自動更新する機能（以下、ACMEサービス）の提供を開始しており、京都大学でも利用可能となりました。なお、従来のサーバ証明書サービスは将来的に縮小・廃止予定ですので、今後は本サービスをご利用ください。

ACMEサービスの利用方法

ACMEは、証明書を利用する「サーバ」と証明書を発行する「認証局」が直接対話し、発行・更新・失効を自動的に行う標準的な手順です。サーバにインストールしたクライアントソフトが認証局とやり取りして証明書を取得します。証明書を発行する際には、対象ドメインを管理していることを示す「ドメイン所有権の確認」が必要で、確認方法には次の2種類があります。

 HTTP-01チャレンジ（簡単おすすめ） 

• DNSのAレコード、AAAAレコードまたはCNAMEレコードの指すサーバに対しHTTP（80/TCP）接続 
• 検証時に生成したランダム値が /.well-known/acme-challenge/ の値と一致すればOK 

DNS-01チャレンジ 

• 検証時に生成したランダム値がDNSの _acme-challenge.[ドメイン名] のTXTレコードと一致すればOK
• 都度DNSレコードの登録が必要だがDNS登録APIがあれば自動化は可能

UPKIのACMEサービスの利用方法

UPKIでは上記のドメイン所有権の確認に加えて、アカウント発行のためのEAB情報（External Account Binding：認証局にアカウントを紐づける鍵情報）が必要です。京都大学ではKUINSDBにログインして下記の手順でEAB情報を申請してください。 

1. サーバのホスト管理者またはドメインのドメイン管理者がKUINSDBにログイン後、申請対象のホスト情報またはドメイン情報を開いてください。ホスト管理者が申請した場合はドメイン管理者の承認が必要になります。 
2. ACME申請マニュアルを参考に申請してEAB情報を取得します。EAB情報が不要になった場合の「失効」や、紐付けるDNSレコードなどが変更になった場合の「引継」も可能です。 　

EAB情報の申請はKUINSDBマニュアル（ https://db.kuins.kyoto-u.ac.jp/manual/user/part2/part2_17.html ）でご確認ください。

ACMEクライアントツール「certbot」の利用方法 

以下に、代表的なクライアントツール「certbot」の簡単な利用例を示します。 

（インストール）

Redhat系 （EPELリポジトリを有効にすること）

sudo dnf install certbot

Debian系

sudo apt install certbot

（アカウント登録） 

sudo certbot register \ 
 --server 'https://secomtrust-acme.com/acme/' \
 --eab-kid xxxxxxxxxxxx --eab-hmac-key xxxxxxxxxxxx \
 --email server-admin-name@example.kyoto-u.ac.jp --agree-tos --no-eff-email

※ --eab-kid と--eab-hmac-key はKUINSDBで取得したEAB情報、--email は連絡先メールアドレス

（HTTP-01証明書取得）

sudo certbot certonly \
 --server 'https://secomtrust-acme.com/acme/' \
 --webroot -w /var/www/webroot -d host1.example.kyoto-u.ac.jp --key-type rsa \
 --deploy-hook 'systemctl reload nginx.service'  

 ※ -w はWeb公開するルートディレクトリパス、-d は証明書のドメイン名、--deploy-hook は証明書取得後に実行するコマンド 

（証明書更新）

 sudo certbot renew

※ systemd timerにて自動実行できます。

※一度設定すれば、それ以降の更新は自動で行われます。これがACME移行の最大のメリットです。

その他の利用ケース例

● Webサービス以外のサーバ

•  メールサーバなどWebサーバ未使用の場合は --pre-hook や --post-hook オプションで証明書取得の直前・直後に実行コマンドを設定でき、Webサーバの起動・停止やファイアウォール許可・制限のような処理を追加できます。 

● ロードバランサなどのアプライアンス機器

• 対応状況はUPKIマニュアル（ https://certs.nii.ac.jp/acme/appliances/ ）でご確認ください。非対応機器でも下記の処理で対応可能です。 
  • HTTP接続が複数台に分散する場合は、HTTP-01チャレンジ用URLに限り特定サーバで受信するよう設定し、当該サーバでcertbotを実行します。 
  • 証明書を取得したら --deploy-hook の処理でexpectコマンドによるCLI操作（またはcurlによるGUI操作）でロードバランサを更新します。 
• クラウドサービスのロードバランサなら、クラウドが提供するサーバ証明書サービスの利用をおすすめします。

● KUINS-IIIサーバ

•  学外から接続不可でHTTP-01チャレンジが使えない場合は、DNS-01チャレンジで取得可能です。KUINSDBのDNS登録APIによる直接登録機能を使えば自動取得ができます。APIの利用方法はKUINSDBマニュアル（ https://db.kuins.kyoto-u.ac.jp/manual/user/part1/part1_11.html ）でご確認ください。

 （DNS-01証明書取得） 

sudo certbot certonly \
 --server 'https://secomtrust-acme.com/acme/' \
 --manual --preferred-challenges dns -d host2.example.kyoto-u.ac.jp --key-type rsa \
 --manual-auth-hook '/path/to/auth_script.sh' --manual-cleanup-hook '/path/to/cleanup_script.sh' \
 --deploy-hook 'systemctl reload nginx.service' 

※ -d は証明書のドメイン名、--manual-auth-hook は、APIレコード登録処理、--manual-cleanup-hook は、APIレコード削除処理、--deploy-hook は、サービスをリロードするコマンド

※ APIレコード登録処理や削除処理は、curlコマンドなどを使ってJSON形式でPOSTするスクリプトを作成してください。

その他certbotの詳細はUPKIマニュアル（ https://certs.nii.ac.jp/acme/clients/certbot/ ）をご確認ください。

また、certbot以外にも下記のACMEクライアントがございますので、必要に応じてご利用ください。 

• 「acme.sh」Pythonモジュールに依存しないシェルスクリプトの軽量ACMEクライアント 
• 「win-acme」Windows Serverで動作するACMEクライアント 

ACMEクライアントの詳細はUPKIマニュアル（ https://certs.nii.ac.jp/acme/clients/ ）をご確認ください。

無償TLSサーバ証明書「Let’s Encrypt」との比較

同じくACMEで無償の証明書を提供する「Let’s Encrypt」との差異を下表にまとめました。EVサーバ証明書を扱う有償サービスやクラウドのオプションサービスなども含めて検討し、用途に応じた最適なサービスを選んでください。