EJBCAのTLS証明書発行までのチュートリアルを日本語訳してやってみた

はじめに

前回記事「EJBCA(PKI および証明書管理アプリ)をビルドしてインストールしてみた」にて、EJBCA(PKI および証明書管理アプリ)をインストールして、とりあえず、管理ページが表示されるところまでやりました。
今回、その続きで、TLS サーバー証明書を発行するところまで EJBCA 公式ドキュメントのチュートリアルを３つやっていきます。

・Tutorial - Create your first Root CA using EJBCA
（https://doc.primekey.com/ejbca/tutorials-and-guides/tutorial-create-your-first-root-ca-using-ejbca）
チュートリアル - EJBCA を使用して最初のルート CA を作成する

・Tutorial - Create a PKI Hierarchy in EJBCA
（https://doc.primekey.com/ejbca/tutorials-and-guides/tutorial-create-a-pki-hierarchy-in-ejbca）
チュートリアル - EJBCA で PKI 階層を作成する

・Tutorial - Issue TLS server certificates with EJBCA
（https://doc.primekey.com/ejbca/tutorials-and-guides/tutorial-issue-tls-server-certificates-with-ejbca）
チュートリアル - EJBCA を使用して TLS サーバー証明書を発行する

の３つです。
この記事では、書いてある通りの手順を実施していきますので、実質日本語版チュートリアルになります。

この記事は、勝手に日本語訳して実施しているだけで、EJBCA および Keyfactor 社、PrimeKey の見解とは一切関係ありません。

ときどき原文に無い説明を加筆しています。それについても、EJBCA および Keyfactor 社、PrimeKey の見解とは一切関係ありません。また、一部誤訳、誤解釈等があるかもしれません。ご了承ください。

本記事情報の設定不足、誤りにより何らかの問題が生じても、一切責任を負いません。

主に「鍵」のことを「キー」と表記します。他、EJBCA の言語選択で、日本語に切り替えられますが、英語のままを前提とします。（日本語に切り替えると、メニュー文言とかでググっても情報が出てこなくなるため、おすすめしません！）

最初のルート CA を作成する

EJBCA を使用して最初のルート CA を設定する方法を学びます。

このチュートリアルでは、次の方法を学びます。：
・証明書プロファイルを作成する
・暗号トークンを作成する
・CA を作成する

ステップ 1 - 証明書プロファイルを作成する

初めて EJBCA 管理ページにアクセスすると、作成された管理 CA が表示されます。
これは、管理者用のすべての内部証明書と、たとえば外部 VA または RA への接続に必要な TLS 接続を発行する CA です。
最初の CA を作成するための最初のステップは、証明書プロファイルを作成することです。
証明書プロファイルは、新しい証明書の制約 (使用できるキーや拡張子など) を定義します。
証明書プロファイルの概要については、「証明書プロファイルの概要（Certificate Profiles Overview）」を参照してください。

【 RA（Registration Authority：登録局） 】

RA は、デジタル証明書の登録申請を受け付けて承認を行う機関です。つまり、ユーザーがデジタル証明書を申請すると、RA はその申請を受けて審査を行い、承認します。

【 VA（Validation Authority：検証局） 】

VA は、デジタル証明書が有効かどうかを確認する役割を果たします。具体的には、デジタル証明書が無効になっていないかを確認するために、証明書失効リスト（CRL）を管理しています。

後の手順で CA を作成するためのテンプレートを提供する証明書プロファイルを作成するには、次の手順を実行します。：

【 LDAP DN order を無効にします 】

この記述は、証明書プロファイルの設定に関するもので、「LDAP DN order」を無効にすることを指示しています。

「LDAP DN order」は、証明書の「DISTINGUISHED NAME」コンポーネントの順序を決定する設定です。

LDAP（Lightweight Directory Access Protocol）は、ディレクトリサービスを提供するプロトコルで、DN（Distinguished Name）は、LDAP ディレクトリ内のエントリを一意に識別するための名前です。

しかし、この「LDAP DN order」は古い順序付け方式で、現在では推奨されていません。

そのため、このプロファイルでは「LDAP DN order」を無効にし、標準の X.509 順序付けを使用することが推奨されています。

この設定を無効にすることで、DN の順序は X.509 標準に従ったものになります。

【 SAN 】

「SAN」は「Subject Alternative Name」の略称で、「サブジェクトの別名」という意味です。

SSL サーバ証明書に含まれる情報として、コモンネームを含むサブジェクトとは別に「SAN」という拡張領域があります。

SSL サーバ証明書のコモンネームには、FQDN（URL）を 1 つしか設定できませんが、SAN を利用すると、1 枚の証明書で複数のウェブサイトの暗号化通信を実現することが可能になります。

これにより、個別で証明書を発行・管理するよりもコストを抑えることが可能です。

新しく作成された MyRootCAProfile が証明書プロファイルのリストに表示されます。

ステップ 2 - 暗号トークンを作成する

EJBCA では、暗号キーは暗号トークンに保存されます。 暗号トークンは、ソフト キーストアと呼ばれるデータベース、またはハードウェア セキュリティ モジュール (HSM) に保存できます。
暗号トークンと使用可能なフィールドの詳細については、「暗号トークンの概要（Crypto Tokens Overview）」を参照してください。

暗号トークンは、デジタル証明書や暗号化されたキーなどの情報を保持するデバイスやソフトウェアのことを指します。（キー情報が入った金庫のようなものです。）

以下では、ソフト暗号トークンと次のキーを作成する方法について説明します。：
・Sign key: CA からのデジタル署名に使用されます。
・Default key: CA が実行する必要がある暗号化に使用されます。
・Test key: 通常、ヘルス チェックまたは HSM keep-alive サービスでのみ使用されます。

⚠ 署名および暗号化キー（default key）ラベルを作成する際に番号を付けておくと、認証局を更新する際に簡単に番号を増やすことができます。

【 HSM 】

HSM（ハードウェアセキュリティモジュール）は、一般的に電子証明書の暗号鍵と鍵管理に関する国際規格を取得しているデバイスです。

具体的な規格としては、以下のものがあります：

FIPS 140-2：米国の連邦情報処理標準です。暗号モジュールのセキュリティ要件を定めています。

Common Criteria（コモンクライテリア）：IT 製品のセキュリティ機能を評価するための国際標準です。

これらの規格は、HSM が暗号鍵の生成、保護、管理などのプロセスを安全に行うことを保証します。

【 HSM keep-alive services 】

HSM keep-alive サービスとは、HSM が正常に動作しているかを定期的に確認するためのサービスのことです。このサービスは、HSM が適切に機能していることを確認し、必要に応じて問題を早期に検出する役割を果たします。

ソフト ルート CA 暗号トークンとキーを作成するには、次の手順に従います。：

ここで、「ソフト」の意味は、HSM を使わないという意味です。

「コンテナー」は、EJBCA のデプロイ環境が Docker 前提で言っているようです。

ここで、Type = SOFT になっていますが、SOFT とは、HSM を使わないで、EJBCA 自身でトークンを持つという意味です。（以降同様に暗黙的に SOFT を選択することになっています。）

これでルート CA 暗号化トークンとキーが作成されたので、引き続き最初の CA を作成できます。

ステップ 3 - CA を作成する

最初のルート CA を作成するには、次の手順に従います。：

keyEncryptKey が - Default key になっていますが、おそらくそれで良いと思われます。

作成された MyFirstRootCACryptoToken が CA のリストに表示されます。

直上の MyFirstRootCACryptoToken は、誤植と思われます。（2024 年 2 月時点）

MyFirstRootCA が CA のリストに表示されます。

PKI 階層を作成する

以降、ここまでの手順で見たような画面の掲載は省略します。

EJBCA で多層認証局 (CA) 階層を作成する方法を学習します。

CA の多層階層を作成することをお勧めします。
この設定では、ルート CA (トラスト アンカー) は下位 CA にのみ証明書を発行し、新しい証明書を発行する権限を下位 CA に与えます。
下位 CA は、証明書をエンド エンティティに直接発行したり、追加レベルの下位 CA を作成したりできます。
この主な利点は、ルート CA を厳密に制御して長い有効期間を与えることができるのに対し、下位 CA の有効期間を短くし、必要に応じて取り消すことができることです。
こうすることで、信頼されたルート CA 証明書を更新および置換する必要性が最小限に抑えられます。
異なる下位 CA は、同じ EJBCA インスタンスでホストされている場合でも、異なるチームによって管理することもできます。
たとえば、内部エンティティ用に 1 つの CA と外部エンティティ用に 1 つの CA を使用したり、リージョン全体で異なる CA を使用したり、目的ごとに異なる CA を使用したりすることができます。

このチュートリアルでは、次の方法を学びます。：
・同じ EJBCA インスタンス内にルート CA と下位 CA を作成する
・既存のプロファイルに基づいて新しい証明書プロファイルを作成する
・CRL 配布ポイントの構成
・権限情報アクセス URI の構成

ステップ 1 - 証明書プロファイルの作成

始める前に、実行中の EJBCA インスタンスが必要です。 また、ルート CA プロファイル テンプレートの作成方法については、チュートリアル「EJBCA を使用して最初のルート CA を作成する」を参照してください。

ルート CA 証明書プロファイルの作成

以下に、「最初のルート CA を作成する」チュートリアル で作成した MyRootCAProfile 証明書プロファイルを複製してルート CA 証明書プロファイルを作成する手順を示します。

後の手順でルート CA を作成するための証明書プロファイルを作成するには、次の手順を実行します。：

【 P-256 / prime256v1 / secp256r1 】

楕円曲線暗号（Elliptic Curve Cryptography, ECC）の一部である楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm, ECDSA）で使用される特定の楕円曲線を指しています。

P-256 / prime256v1 / secp256r1 は、256 ビットのプライムフィールド上の Weierstrass 曲線を指します。ここで、256 は曲線のビット長を示しています。

新しく作成された MyPKIRootCAProfile が証明書プロファイルのリストに表示されます。

サブ CA 証明書プロファイルの作成

後の手順でサブ CA を作成するための証明書プロファイルを作成するには、次の手順を実行します。：

EJBCA Manage Certificate Profiles ページ = CA Functions - Certificate Profiles です。

新しく作成された MyPKISubCAProfile が証明書プロファイルのリストに表示されます。

ステップ 2 - 暗号トークンを作成する

EJBCA では、暗号キーは暗号トークンに保存されます。 暗号トークンは、ソフト キーストアと呼ばれるデータベース、またはハードウェア セキュリティ モジュール (HSM) に保存できます。
暗号トークンと使用可能なフィールドの詳細については、「暗号トークンの概要（Crypto Tokens Overview）」を参照してください。

以下では、ソフト暗号トークンと次のキーを作成する方法について説明します。：
Sign key: CA からのデジタル署名に使用されます。
Default key: CA が実行する必要がある暗号化に使用されます。
Test key: 通常、ヘルス チェックまたは HSM キープアライブ サービスでのみ使用されます。

⚠ 署名および暗号化キー（default key）ラベルを作成する際に番号を付けておくと、認証局を更新する際に簡単に番号を増やすことができます。

ルート CA 暗号トークンの作成

ソフト ルート CA 暗号トークンとキーを作成するには、次の手順に従います。：

ここで、「ソフト」の意味は、HSM を使わないという意味です。

正確には、ECDSA P-256 / prime256v1 / secp256r1 を選択です。

これで、ルート CA 暗号トークンとキーが作成されました。

サブ CA 暗号トークンの作成

ソフト Sub CA 暗号トークンとキーを作成するには、次の手順に従います。：

これで、Sub CA 暗号トークンとキーが作成されました。

ステップ 3 - CA を作成する

証明書プロファイルと CA キーを作成したので、それらをまとめて CA 階層を作成できます。

ルート CA の作成

ルート CA を作成するには、次の手順に従います。：

【 OCSP 】

OCSP（Online Certificate Status Protocol）は、デジタル証明書（公開鍵証明書）の有効性を TCP/IP ネットワークを通じて問い合わせるためのプロトコルです。これにより、デジタル証明書が何らかの理由で有効期限前に失効している場合でも、その情報を迅速に知ることができます。

作成した MyPKIRootCA-G1 が CA の一覧に表示されます。

サブ CA の作成

サブ CA を作成するには、次の手順に従います。：

下の Certificate Profile を選択する前に Signed By を選択する必要があります。

作成した MyPKISubCA-G1 が CA の一覧に表示されます。

これで、ルート CA と下位 CA を含む 2 層の公開キー基盤 (PKI) 階層が作成されました。

TLS サーバー証明書を発行する

EJBCA を使用してエンド エンティティ証明書を手動で発行する方法を学習します。

このチュートリアルでは、次の方法を学びます。：
・サーバー TLS 証明書の証明書プロファイルを作成する
・エンドエンティティプロファイルを作成する
・証明書署名リクエスト (CSR) を作成する
・CSR に基づく証明書の発行

ステップ 1 - 証明書プロファイルの作成

最初のステップは、サーバー TLS 証明書の証明書プロファイルを作成することです。
証明書プロファイルは、新しい証明書の内容と制約を定義します。
たとえば、どのキーのタイプを許可するか、証明書でどの拡張子を使用するかを定義できます。
証明書プロファイルの概要については、「証明書プロファイルの概要（Certificate Profiles Overview）」を参照してください。

サーバー TLS 証明書の証明書プロファイルを作成するには、次の手順を実行します。：

Use にチェックを入れて、Tuesday, Wednesday, Thursday にチェックなしです。

特に指示が無いため、そのままとします。

「デフォルトでは使用できないキーの使用法が必要な場合」という表現は、EJBCAの初期設定では対応していない特定のキーの使用法が必要となる状況を指しています。

言い換えると、「EJBCAの初期設定では対応していないが、特定の目的のために必要となるキーの使用法がある場合」という意味になります。このような場合、EJBCAのシステム設定で新たにそのキーの使用法を追加することが可能です。これにより、その特定の目的（例えばコード署名や電子メール保護など）に対応する証明書を作成することができます。

拡張キー使用法は、管理 Web の System Configuration ページの Extended Key Usages タブで追加および削除できます。

【 Basic Constraints（基本制約） 】

「Basic Constraints」は、証明書がエンドエンティティ（最終ユーザー）の証明書であるか、それとも認証局（CA）の証明書であるかを定義します。

ここで作成している証明書はエンドエンティティの証明書であり、CA の証明書ではないため、「Basic Constraints」をクリアします。

また、「これをオプションにするため」という部分は、この制約をオプションとして設定したいという意図を示しています。

つまり、この制約は必須ではなく、必要に応じて適用できるようにします。

【 エンドエンティティ証明書と認証局（CA）証明書 】

エンドエンティティ証明書と認証局（CA）証明書は、それぞれ異なる目的と役割を持っています。

エンドエンティティ証明書は、通常、個々のユーザーやデバイスに発行されます。

これらの証明書は、その所有者（ユーザーやデバイス）が誰であるかを確認するために使用されます。

例えば、ウェブサイトの SSL/TLS 証明書はエンドエンティティ証明書の一種で、ブラウザがサーバーと安全に通信するために使用されます。

一方、認証局（CA）証明書は、他の証明書を発行および署名するための証明書です。CA 証明書は、信頼された第三者（認証局）によって発行され、その認証局が発行した他の証明書（エンドエンティティ証明書を含む）の信頼性を保証します。

新しく作成された TLS Server Profile が証明書プロファイルのリストに表示されます。

ステップ 2 - エンド エンティティ プロファイルの作成

次に、エンド エンティティ プロファイルを作成ます。これにより、EJBCA がどのような証明書保有者の情報を記録し、サブジェクト情報として追加するかを定義できます。

エンド エンティティ プロファイルを作成するには、次の手順に従います。：

「Add Profile フィールド」は、原文のままで、実際には、Add End Entity Profile フィールド です。

各々選択して Add ボタンをクリックです。

【 CN, Common Name 】

CSRの Common Name は、CSRを生成する際に入力する項目の一つで、ブラウザでサーバにアクセスする際に入力するURL（FQDNまたはIPアドレス）に相当します。具体的には、以下のような形式になります：

URL: https://jp.example.com/contact/inquiry_form.html → Common Name: jp.example.com

URL: https://210.172.xxx.169/index.html → Common Name: 210.172.xxx.169

SSL暗号化通信の際には、コモンネームがサイトのURLと一致しているかを確認するため、異なるサブドメインなどでアクセスした場合にはエラーになります。また、複数のサイトでSSLを利用する場合は、サイトごとに証明書が必要となります。ワイルドカード証明書（*.xxx.xxx.xx）では、同一ドメイン名の複数コモンネームに対応が可能です。

Available Certificate Profiles も CTRL キーを押しながら TLS Server Profile を選択しておく必要があります。

実際の表記は、「Default CA」です。

ステップ 3 - サーバー証明書の発行

サーバー証明書を発行するには、EJBCA RA Web インターフェイスを使用して新しいリクエストを作成し、新しいプロファイルを使用して登録します。

Certificate subtype に言及が無いため、この記事では、TLS Server Profile (default) を選択します。

ダウンロードされた test.my.pki.pem ファイルには、証明書 test.my.pki と、ルート CA およびサブ CA の CA 証明書が含まれています。

Apache で使ってみる

ここからは、チュートリアルに無いオリジナルの実施内容です。
作った証明書は、サーバー証明書のため、Apache に読み込ませて、実際に使用してみます。

# apt -y update
# apt -y install apache2
# a2enmod ssl
# a2ensite default-ssl
# cp test.my.pki.pem /etc/ssl/certs/test.my.pki.pem
# cp tls_server.key /etc/ssl/private/tls_server.key
# chown root: /etc/ssl/certs/test.my.pki.pem /etc/ssl/private/tls_server.key
# chmod 400 /etc/ssl/private/tls_server.key
# vi /etc/apache2/sites-available/default-ssl.conf
    SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
    SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
を以下に変更
↓
    SSLCertificateFile      /etc/ssl/certs/test.my.pki.pem
    SSLCertificateKeyFile /etc/ssl/private/tls_server.key
# systemctl restart apache2

test.my.pki を hosts に追加して、https:/test.my.pki/ にアクセスしてみます。

使えました！

証明書を表示してみます。

見覚えのある情報が入っています！

・・・

「で、その証明書、凄いの？」っていうつっこみは無しです。

以上！