Easy-RSA が PKI が無いと言う? 別の場所を見ている
CA 鍵や index.txt が無いというのは、通常 Easy-RSA 3 が別のディレクトリを選んだという意味です。まず PKI セレクタ、優先順位、発行者のフィンガープリントを確認してください。
ca.crt や index.txt が無いためにコマンドが停止しますが、CA は何ヶ月も証明書を発行し続けています。認証局側には何も変わっておらず、コマンドが単に別の場所を見ただけです。Easy-RSA 3 は PKI ディレクトリをオプション、環境変数、vars ファイル、組み込みの既定値から決定し、そのどれもが配備の認証局とは別の場所を指す可能性があります。何かを作る前に、どれが勝ったかを確認してください。
エラーが示すのはファイルであり、ディレクトリではない
インストール先ディレクトリと発行者ディレクトリは別の場所です。easyrsaがマシン上にあることは、ツールがインストールされている証明にすぎず、VPN が信頼する認証局を見つけた証明ではありません。
だからこそ、パッケージの再インストールや init 手順の再実行は効果がありそうに見えて、何も変わりません。
何よりも先にセレクタを確認する
Easy-RSA 3 ではセレクタはEASYRSA_PKIまたは対応する--pki-dirオプションです。次のような絶対パスを渡せば--pki-dir=/srv/pki/office、答えは偶然いた場所に依存しなくなります。この一つの習慣でこの不具合の一類が丸ごと消えます。とくに cron や CI チェックアウトから実行するスクリプトでは重要です。
まず世代を確認する。Easy-RSA 2 のvarsファイルとbuild-keyという習慣は、Easy-RSA 3 が期待するモデルとは別物だからです。easyrsa --versionは何よりも先に世代を表示し、./easyrsa --helpはサブコマンドを一覧します。build-keyという対象は 2.x を意味し、build-client-fullは 3.x を意味します。ディレクトリ名が馴染み深いからといって古いKEY_DIRパスを 3.x の呼び出しに持ち込むと、まさにこのエラーになります。
バージョン文字列とコマンド構文が食い違うなら、作業を止めて、インストールされているリリース自身のドキュメントを読んでください。
優先順位が vars ファイルの敗因を説明する
文書化された優先順位は、コマンドラインオプション、次に環境、次に vars ファイル、次に組み込みの既定値です。したがってvarsの正しい値は継承された環境変数に負けます。これがこの障害の静かな版です。環境全体をチケットに流し込むのではなく、意図した変数とファイル選択を調べてください。両者の違いは通常、秘密です。
連鎖を順にたどり、コマンドが使ったパスをどのソースが提供したかを記録してください。それが分かれば、修正はフラグか export であり、新しい認証局ではありません。
Easy-RSA設定リファレンスがセレクタと優先順位を定義しており、チケットに載せるべき引用はこれです。
公開された素材で発行者を確認する
通常のファイルベースの発行者なら、ca.crtを読み、そのフィンガープリントを承認済みの発行者記録と照合します。一致するサブジェクト名は身元の証拠ではなく、production という名前のディレクトリも同様です。見つけたファイルを、ピアが信頼するよう言われた認証局に結びつけるのはフィンガープリントだけです。
読み取り専用の確認で十分です。openssl x509 -in /srv/pki/office/ca.crt -noout -subject -issuer -serial -fingerprint -sha256。
次にそのディレクトリの役割を確定します。クライアントが使うリクエスト用ディレクトリは発行者データベースではなく、オフラインで保管する署名鍵がすべての VPN ホストにあるべき理由はありません。ca.keyが無いことはその構成における設計上の性質であり、代替の認証局をでっち上げる許可ではありません。
状態が本当に失われている場合
パスが正しく、状態が本当に無いこともあります。空のindex.txtと再起動したシリアルカウンタは、健全に見えて、一度も見たことのない証明書については何も証明できない PKI を与えます。更新は古い証明書を失効させず、新しい番号は履歴と衝突します。代わりに CA の承認済みバックアップから復元してください。空の PKI を別の場所で初期化しても、エラーが移動するだけで、無関係な第二の認証局が残るからです。
パスと発行者が一致したら、次の障害はその内容で判断してください。Permission denied、パスフレーズを要する署名鍵、発行記録の欠落は三つの別の障害であり、いま直したディレクトリに関わるのは一つだけです。
パスの誤りを覆い隠すために鍵の暗号化を外したり、ディレクトリの権限を広げたりしないでください。誤りの修正は安く済みますが、修復はそうではありません。