Job Director R17（以下、Job Director）は、タスクスケジューラでは物足りないが、統合運用管理ツールでは高機能すぎるというお悩みを抱えるシステム管理者にぴったりなジョブ管理ツールです。それ自身、スケジュール機能を備えたWindowsの機能や他社ツールは多いですが、それらの機能やツールをコマンドラインで制御できれば、Job Directorの柔軟なジョブネットワークとカレンダ／スケジュール定義に基づいて、運用管理タスクのスケジュールを一元化できます。 今回は、近年、短命化が進む公開TLS証明書の更新・入れ替え作業を自動化する、Job Directorの活用例を紹介します。

※この記事の内容は、Job Director R16以前も対応しています。ただし、メール送信部品のMicrosoft 365 OAuth2対応はR17の機能です。

いま、公開TLS証明書の短命化に備えた対応が急務に 

　電子証明書を使った通信の安全性や利便性を向上させるためのガイドラインを策定している任意団体「CA/Browser Forum（CA/ブラウザーフォーラム）」は、2025年4月、TLS証明書の有効期間を段階的に短縮するTLSベースライン要件の改正を採択しました。これにより、パブリックTLS証明書の最大有効期間は、以下の表に示すように、2026年3月15日から200日（現在）、2027年3月15日から100日、そして2029年3月15日からは47日へと段階的に短縮されます。

　パブリックTLS証明書を発行する認証局（CA）各社は、CA/Browser Forumが定めるベースライン要件に基づいて証明書を発行しています。例えば、Let's Encryptは現在、通常の証明書を有効期間90日で発行しています。今後は段階的に短縮され、2027年2月10日から64日、2028年2月16日から45日となる予定です。また、証明書や秘密鍵が漏えいした際のリスクを抑えるため、さらに有効期間の短い「shortlived」プロファイル（6日）も既に提供されています。

　証明書の有効期間が短くなれば、それだけ証明書を更新する機会も増えます。これまで年あるいは数年に1回程度で済んでいた証明書の更新作業も、将来的には年に何度も行う必要が生じます。証明書の取得からサーバーへの適用までを人手で行っている環境では、管理者の負担が増えるだけでなく、更新忘れによる証明書の期限切れが発生するリスクも高まります。

　そこで重要になるのが、証明書の取得や更新を自動化する仕組みです。そのための標準プロトコルとして、2019年3月にIETF標準として策定された「ACME（Automatic Certificate Management Environment）」（RFC 8555）が既にあります。ACMEクライアントを利用することで、ドメインの所有・管理権限の確認から証明書の発行、更新までの一連の処理を自動化できます。ACMEクライアントには、Linux環境で広く利用されている「CertBot（https://certbot.eff.org/）」や、Windows/IISとの連携に強い「win-acme（https://www.win-acme.com/）」、WindowsでのGUI操作向けの「Certify The Web（https://certifytheweb.com/）」など多数あります。

　一例として、win-acmeを使用したIISサイト向けのTLS証明書の発行とインストール、そして証明書の更新操作について説明します。その後、Job Directorを用いた、更新作業の自動化と監視を紹介します。

win-acmeによるIISサイトのTLS設定

　この記事では、Windows Serverの「インターネットインフォメーションサービス（IIS）」のWebサイトのTLS設定を、win-acmeクライアントを使用してセットアップする方法を紹介します。証明書は、win-acme既定のLet’s Encryptから取得（無料）します。なお、win-acmeは、ACME対応の他のCAにも対応できます。その方法については、CA各社のACME関連ドキュメント（例、DigiCert、ZeroSSL、Google Trust Services）を参考にしてください。

　ACMEには、次の3つの方式に対応しています。

• HTTP-01 ･･･ subdom.example.jp がインターネットからIISへ到達できる必要がある（通常TCP/80）。

• DNS-01 ･･･ DNSに _acme-challenge.example.jp のTXTレコードを作成して認証する方式；CA側はTXTレコードの値を検索してそのドメイン管理権を検証する。IISをインターネット公開する必要はない。

• TLS-ALPN-01 ･･･ RFC 8737で追加された方式。443/TCPのTLSレイヤーだけでドメイン管理権を検証する。

　一般的に利用されるHTTP-01とDNS-01の両方で説明します。HTTP-01方式は、対象のIISのWebサイトのTCP/80にインターネットから到達できる必要があります。一方、DNS-01はTXTレコードを用いてドメインの管理権を検証するため、ドメインIISのWebサイトをインターネットに公開する必要がありません。また、*.example.jp（www.example.jpやwww2.example.jpなどをカバー）のようなワイルドカード証明書を使用する場合は、DNS-01方式にする必要があります。

HTTP-01方式によるIIS Webサイトのセットアップ

　まず、IISに新しいWebサイトを作成し、サイトのバインドを編集して、HTTPバインド（ポート80）にホスト名（ホストヘッダー）としてCAから取得するホストのFQDN（例、www.example.jp）を設定します。この時点でHTTPSバインド（ポート）は必要ありません（画面1）。PowerShellでサイトを作成する場合は、次のコマンドラインを実行します（サイトの物理パスがC:¥InetPub¥demositeの場合）。

画面1　IISにWebサイトを作成し、HTTPバインド（ポート80）にホストヘッダーを設定する

　IISのWebサイトを用意したら、win-acme（win-acme･･･.zip）をダウンロードして、IISホストの任意のパスに展開します。PowerShellウィンドウでwin-acmeｎ展開先のパスに移動し、次のコマンドラインを実行します。--notaskschedulerを指定するかしないかについては後述します。

※コマンドラインを見やすくするため、wacs.exeをPowerShellで実行することを前提に、バッククォート（`）で改行しています。 wacs.exeをcmd.exeで実行する場合は ` をキャレット（^）に置き換えるか、` と改行を削除し、コマンドラインを1行で記述してください。

　wacs.exeの実行が完了すると、Let's Encryptから発行された証明書が証明書ストア（通常、ローカルコンピューターの「Web ホスティング」ストア）にインストールされ、（--installation iisパラメーターにより）WebサイトのHTTPSバインド（TCPポート443）がセットアップされ、HTTPSによるTLS Webアクセスが可能になります（画面2）。

画面2　wacs.exeのコマンドラインを実行すると、ホスト用のTLS証明書が要求、発行され、WebサイトのHTTPSバインドがセットアップされる

DNS-01方式によるIIS Webサイトのセットアップ

　DNS-01方式では、CAの証明書の要求中に、DNSのTXTレコート「_acme-challenge.example.jp」に設定する値が示されるので、そのレコードを、ドメインを管理しているDNSサーバーに登録し、CAから検証させる必要があります。検証後、TXTレコードは次回の更新に備えて削除する必要もあります。

　win-acmeでは、自動化のためDNS-01検証用スクリプトとして、TXTレコードの作成用スクリプトを--dnscreatescriptパラメーターに、TXTレコード削除用スクリプトを--dnsdeletescriptパラメーターに指定することができ、各スクリプトに--dnscreatescriptargumentsと--dnsdeletecriptargumentsパラメーターで引数を渡すことができます。引数には変数{Identifier}{ZoneName}{RecordName}{Token}を指定できます。例えばワイルドカード証明書*.example.jpの場合、{Identifier}は*.example.jp、{ZoneName}はexample.jp、{RecordName}は_acme-challenge.example.jp、{Token}はTXTレコードに設定する値がセットされます。

　DNS事業者の中には、DNSレコード更新用APIを提供している場合があります（Azure DNSのAzure REST API/PowerShell/CLI、AWS Route 53のAWS API/CLI、Google Cloud DNSのGoogle Cloud API、MyDNS.jpなど）。また、BINDやMicrosoft DNSなども動的更新（nsupdate）やAdd/Remove-DnsServerResourceRecord（Microsoft DNS）など外部からのDNSレコードの作成/削除に対応しています。利用環境によって異なるため、次のC:￥tools￥dnsvalidation.ps1は作成と削除の両方に対応した検証用スクリプトだと思ってください（参考として、今回の動作確認のために使用したMyDNS.jp用スクリプトのサンプル）。

　検証用スクリプト（TXTレコードの作成/削除用スクリプト）を用意したら、PowerShellウィンドウでwin-acmeの展開先のパスに移動し、次のコマンドラインを実行します。--notaskschedulerを指定するかしないかについては後述します。

※コマンドラインを見やすくするため、wacs.exeをPowerShellで実行することを前提に、バッククォート（`）で改行しています。 wacs.exeをcmd.exeで実行する場合は ` をキャレット（^）に置き換えるか、` と改行を削除し、コマンドラインを1行で記述してください。

　TXTレコートの検証に成功すれば、WebサイトのHTTPSバインド（TCPポート443）がセットアップされ、HTTPSによるTLS Webアクセスが可能になります（画面3）。

画面3　DNS-01方式によるIIS WebサイトのTLS設定

win-acmeによる証明書の入れ替え

　HTTP-01/DNS-01の方式に関係なく、IIS WebサイトのTLS設定をwin-acmeでいったん行えば、あとは、次のコマンドラインを実行するだけで、必要に応じて新しい証明書が要求、発行され、入れ替えられます。現在の既定では有効期限まで55日切ると（win-acme展開先のsettings.jsonで調整可能）、新しい証明書に差し替えられます。--forceパラメーターを付けると、55日の期限を待たずに強制的に入れ替えることができます（1日以内の場合はさらに--nocacheを追加）。

　実は、IIS Webサイトのwin-acmeによるセットアップ時に--notaskschedulerパラメーターを付けなかった場合、タスクスケジューラに「win-acme renew...」タスクが作成され、上記のコマンドラインが毎日9:00に自動実行されるようになります（画面4）。そのため、以後、何もしなくても証明書は自動管理されます。ただし、タスクスケジューラでは、更新に失敗した場合に気づきにくいという欠点があります。

画面4　wacs.exe --renewは手動で実行しなくても、スケジュールタスクとして毎日9:00に実行されるため、通常は有効期限切れを心配する必要はない。ただし、失敗時の情報が少ないという欠点がある。Job Directorなど別の方法で管理する場合はこのタスクを削除（または無効に）

　wacs.exeは成功すると終了コード「0」、失敗すると終了コード「-1」を返します。成功または失敗は、タスクスケジューラでタスクの「前回の実行結果」列で「この操作を正しく終了しました。(0x0)」（成功）または「(0xFFFFFFFF)」（失敗）で判断できますが、失敗の詳細な理由まで追跡できません。詳しく調査するには、win-acmeのログ（既定で%ProgramData%￥win-acme￥acme-v02.api.letsencrypt.org￥Logs 」に出力）をあたる必要があります。

　証明書更新コマンド（wacs.exe --renew）をタスクスケジューラではなく、Job Direcorでスケジュール実行させれば、トラッカーを使用して成功/失敗の結果だけでなく、コマンドの標準出力やエラー出力を参照して原因を追跡できます。また、ジョブネットワークのフローを使用して、有効期限切れが近くなったら更新を実行し、その結果をメールなどで通知するといったフローを実現できます。なお、Job Directorによる管理に切り替える場合は、自動作成されたwin-acmeのタスクを削除（または無効に）してください。あるいは、IIS Webサイトのセットアップ時に--notaskschedulerパラメーターを付け、タスクの自動作成をスキップさせます。

Job Directorによる証明書更新の自動化と監視

　win-acmeの更新処理をJob Directorで管理するのは非常に簡単です。最低限、win-acmeの証明書更新コマンド（wacs.exe --renew）をジョブネットワークの単位ジョブのスクリプトに記述し、ジョブネットワークをスケジュール実行させるだけで十分です。コマンドの実行結果はトラッカーを使用して、コマンドの標準出力やエラー出力を追跡できるからです。なお、タスクスケジューラと同様に、Job Directorでは終了コードを符号なし8ビット（uint8、0～255）で扱います。wacs.exeの異常終了「-1」は、Job Director上では「状態: ERROR、終了理由: exit（ 255）で終了しました」の異常終了（単位ジョブの既定では0以外は異常終了）になることに注意してください。

　画面5は不必要な実行や実行結果の通知を含めてジョブネットワークにしたもの、画面6はこのジョブネットワークにより証明書の入れ替えが成功した時のトラッカーの記録です。win-acmeによる更新は、単位ジョブ「RunNew」のスクリプトに記述しています。その前後、単位ジョブ「CheckDaysLeft」および「CheckDaysLeftAgain」では、スクリプトに次の1行のコマンドラインを記述しています。このコマンドラインは、Webサイトにバインドされている証明書の有効期限までの日数を終了コードとして返します。ジョブネットワークでは、残り14日（終了コード0-14）の場合に「RunRenew」に進み、有効期限が十分な場合は何もせず終了します。「CheckDaysLeftAgain」では、更新処理により有効期限の残り日数の問題が解消されたかどうかで成功/失敗を判断し、その結果をメールで通知します。

画面5　更新処理（RunNew）の前後に有効期限までの日数をチェックし、必要な場合に更新して、更新結果をメール通知するジョブネットワーク。分岐のために直前の単位ジョブの終了コードは0-200を正常と判断

画面6　有効期限が残り14日になったため（CheckDaysLeft）、更新処理が行われ（RunRenew）、更新後の有効期限が89日（90日-数秒）になったことがわかる（更新失敗時のトラッカーの画面はこちら）

　このようなジョブネットワークを定期的（毎日または毎週）自動実行するようにスケジュールすれば、必要なときにだけ更新処理を行い、更新の成功/失敗をトラッカーで追跡できるうえ、管理者にメールで通知することができます。これは、タスクスケジューラのタスク（win-acmeの既定）では簡単には実現できないことです。

　メールによる結果の通知には、Job Directorの拡張カスタムジョブ部品の1つである「メール送信部品」を使用できます。Job Director R17では、メール送信部品がMicrosoft 365のOAuth2認証、STARTTLS、TLS 1.1/1.2（既定）/1.3に対応しました（Job Director R16以前は基本認証およびTLS 1.0のSMTPSに対応）。

　メール送信部品のfile_includeカスタムパラメーターにメール送信部品より前のジョブの「ジョブ名.o」や「ジョブ名.e」を設定すると、メール本文に}でそのジョブの標準出力（通常、wacs.exeの更新失敗理由はこちらに出力）やエラー出力の内容を差し込むことができます（画面7）。メール通知のためのメール送信部品の使用方法およびバージョンによる変更点については、Job Directorのマニュアル「拡張カスタムジョブ部品利用の手引き」。製品コラムの記事、およびJob Directorリリースメモで確認してください。

拡張カスタムジョブ部品利用の手引き｜Job Director R17 ガイドダウンロード

What’s new in Job Director R17: Microsoft 365に対応したメール送信部品、設定方法解説｜製品コラム

Job Director R17.1 リリースメモ｜Job Director ダウンロード

画面7　メール送信部品を使用して成功したコマンドの標準出力をメールに差し込んで通知（更新失敗時のメールの通知例はこちら）