[CertMgr] テスト用のクイック・スタート

Domino 12.0 の新機能「証明書管理（CertMgrタスク）」は、Let's Encrypt が「おすすめのクライアント」に掲載されたことからもわかるように、TLS証明書を自動で取得/更新することが可能な ACME クライアントのひとつです。

オンラインヘルプには「Let's Encrypt CA 証明書要求: クイック・スタート」というページがあります。

このページあるコマンド「load certmgr -r -c -o -y  -ACCEPT_TOU」を実行すると、かなりのことを自動でやってくれます。

1. 証明書ストア（CertStore.nsf）の作成
2. 2つあるACMEアカウント文書のうちステージング用のLet's Encrypt の利用条件に同意
3. 現在のサーバーのホスト名でTLS証明書文書を作成
4. DSAPIフィルタの設定（この設定は 12.0.1 で不要になる模様）
5. HTTPタスクの起動（実行中なら再起動）
6. ACMEプロトコルの HTTP-01 チャレンジを使用して Let's Encrypt へ証明書を要求

このコマンドを実行して証明書を取得するには、グローバルIPアドレスがありFQDNがDNSに登録済みでLet's Encrypt側からポート80（HTTP）でアクセスできることが条件になります（ざっくりすぎますが...）。

先日このコマンドをバージョン 12.0 の Domino で実行する機会があったのですが、ちょっと思うところがありましたのでここに残しておこうと思います。

結論から言ってしまうと、証明書は取得できました。初期設定もなしに証明書の取得ができるなんて素晴らしい！

取得した証明書は .kyr ファイルではなく証明書ストア（CertStore.nsf）の「TLS証明書」文書内に保存されます。

Let's Encrypt は本番で使用できる「プロダクション」とテスト用途での使用を想定した「ステージング」という２つの環境があります。オンラインヘルプのクイック・スタートのページにあるコマンドを実行すると、テスト用の「ステージング」から証明書を取得します。ステージングで発行される証明書は、ブラウザやクライアントが持っていない（信頼度の低いルートを持つ）ものです。

クイックスタートのページにあるコマンドでは本番サーバーで使用可能な証明書の取得はできませんのでご注意ください。証明書を取得するプロセスが正しく動作することを確認するために用意されているもの、という位置づけのように思います。

証明書ストア内に自動で作成されたTLS証明書文書を開いてみると、2つある「ステータス」欄の下のほうに”警告”と"No root found"の文字が目立つ色で表示されていました。

取得した証明書のルートと一致するものがDomino側に見つからないようです。

自動で取得できた証明書のルートは「CN=(STAGING) Doctored Durian Root CA X3/O=(STAGING) Internet Security Reserch Group/C=US」です。

証明書ストアには「信頼するルート」ビューがあり、そこにはいくつかのルート証明書が登録されています。しかしながら、上のルートと一致するものはありません。

そこで、Let's Encrypt の Staging Environment からリンクされているリストから11種類ある .pem ファイルをダウンロードして、証明書ストアの「信頼するルートの追加」ボタンで追加したところ「CN=(STAGING) Doctored Durian Root CA X3/O=(STAGING) Internet Security Reserch Group/C=US」のルート証明書は存在しました（下図）。しかしながらすでに期限切れ(Certificate expired)していました...orz

「信頼するルート」もTLS証明書と同様に有効期限があることを再認識しました。本番のルート証明書が忘れたころに期限切れになってそうです...そうならないよう気を付けたいですね。

「信頼するルート」文書にも[要求の送信]ボタンがあります。更新されるかな？と思って試しに押してみたのですが、ステータスは"待機中"のまま変化しません（下図で選択中の行）。

ここで、ステージング用のルート証明書がキータイプ（RSA or ECDSA）とサイズ/曲線名によって異なることに気付きました。

自動作成されたTLS証明書文書では、キータイプが"RSA"、サイズは"4096"です。

そこで、同じホスト名（FQDN）を指定したTLS証明書文書を新規に作成して、キータイプに"ECDSA"を選択して[要求の送信]ボタンを押しました。

そうして Let's Encrypt から取得した証明書のルートは、証明書ストアの「信頼するルート」（上のリスト）に存在する名前と一致しており、TLS証明書文書のステータスは"有効"になりました。めでたしめでたし。

今回はクイックスタートページにあるコマンドで証明書管理に必要な構成を自動で作成してみましたが、この操作の結果が（Let's Encrypt ステージング側の証明書の変更があったことで）"警告"となることはサポートへ報告済みで、CertStore.ntf への現行ルート証明書の追加が問題報告番号 STAAC6Q2PG として要請されました。

ところで、自動作成されたものと新たに作成したもので、同じホスト名でキータイプの違うTLS証明書文書が２つ存在することになりました。ブラウザからアクセスしたときにどちらの証明書が優先されるの？とサポートに聞いてみたところ、次の回答がありました。

１．同じホスト名に対して、RSAとECDSAの証明書が混在する場合ECDSAが優先 ２．ホスト名別ビューで、ECDSAの証明書のうち上位にあるものが優先

なお、今回は新たに別のTLS証明書文書を作成してしまいましたが、キー・ロールオーバーを要求することでも対応可能です。[要求の送信]を行い、新しいキーと証明書が発行されると、古い内容のTLS証明書が「アーカイブ」ビューに保存されます。次からキー・ロールオーバーを活用しようっと。