新機能：プロジェクトの最新情報についてはTwitterとMastodonでご確認ください。

よくある質問 (FAQ)

このページでは、cert-managerに関するよくある質問への回答を見つけることができます。

用語集

「公開的に信頼されている」と「自己署名」とはどういう意味ですか？

これらの用語は、TLS用語集ページで定義されています。

「ルート」、「中間」、「リーフ」証明書とはどういう意味ですか？

これらの用語は、TLS用語集ページで定義されています。

証明書

cert-managerで更新を任意にトリガーできますか？

これは、v0.16以降のcert-managerの機能で、cmctl CLIを使用します。詳細については、renewコマンドのページを参照してください。

証明書はいつ再発行されますか？

証明書の再発行が必要かどうかを判断するために、cert-managerはCertificateリソースのspecと最新のCertificateRequest、およびX.509証明書を含むSecretのデータを確認します。

発行プロセスは、常に以下の場合にトリガーされます。

  • Certificateのspecで指定された名前のSecretが存在しない、秘密鍵または証明書データが不足している、またはデータが破損している場合
  • Secretに保存されている秘密鍵が、Certificateの秘密鍵のspecと一致しない場合
  • 発行された証明書の公開鍵が、Secretに保存されている秘密鍵と一致しない場合
  • Secretのcert-manager発行者アノテーションが、Certificateで指定された発行者と一致しない場合
  • 発行された証明書のDNS名、IPアドレス、URL、またはメールアドレスが、Certificateのspecのものと一致しない場合
  • 証明書の更新が必要な場合（期限切れであるか、更新時間が現在時刻または過去時刻である場合）
  • 証明書の更新が手動でマークされている場合 cmctlを使用

さらに、Certificateの最新のCertificateRequestが見つかった場合、cert-managerは、以下の場合にも再発行します。

  • CertificateRequestで見つかったCSRの共通名が、Certificateのspecのものと一致しない場合
  • CertificateRequestで見つかったCSRのサブジェクトフィールドが、Certificateのspecのサブジェクトフィールドと一致しない場合
  • CertificateRequestの有効期間が、Certificateのspecの有効期間と一致しない場合
  • CertificateのspecのisCAフィールドの値が、CertificateRequestのものと一致しない場合
  • CertificateRequestのspecのDNS名、IPアドレス、URL、またはメールアドレスが、Certificateのspecのものと一致しない場合
  • CertificateRequestのspecのキー使用状況が、Certificateのspecのものと一致しない場合

特定のフィールドについては、変更時の再発行は、cert-managerが以前の発行以降にCertificateのspecが変更されたかどうかを判断するために使用できるCertificateRequestがある場合にのみトリガーされます。これは、一部の発行者はこれらのフィールドの要求された値を尊重しない可能性があるため、発行されたX.509証明書の値に依存できないためです。そのようなフィールドの1つは.spec.durationです。このフィールドへの変更は、比較するCertificateRequestがある場合にのみ、再発行をトリガーします。再発行が必要だが、CertificateRequestがないために（つまり、バックアップと復元後）自動的に再発行がトリガーされない場合は、cmctl renewを使用して手動でトリガーできます。

発行されたSecretのtls.crtにルート証明書がないのはなぜですか？

場合によっては、TLSチェーンに関する誤った選択をしたシステムを使用している人がいます。TLS仕様には、TLSハンドシェイクの「サーバー証明書」セクションに関する次のセクションがあります。

これは証明書のシーケンス（チェーン）です。送信者の証明書は、リストの先頭に配置する必要があります。後続の各証明書は、それを先行する証明書を直接証明する必要があります。証明書の検証には、ルートキーを独立して配布する必要があるため、ルート認証局を指定する自己署名証明書は、リモートエンドがそれを検証するためにすでにそれを所有している必要があるという前提の下で、チェーンから省略される場合があります。

標準的で安全に、正しく設定されたTLS環境では、ルート証明書をチェーンに追加することは、ほとんどの場合不要であり、無駄です。

証明書が信頼される方法は2つあります。

  • 明示的に、信頼ストアに含めることによって。
  • 署名を通して、証明書のチェーンを明示的に信頼されている証明書まで遡ることによって。

重要なことに、ルート証明書は定義上自己署名であり、署名によって検証することはできません。

そのため、クライアントがサーバーから送信された証明書チェーンを検証しようとする場合、接続が開始される前に、クライアントは既にルート証明書を保有している必要があります。クライアントが既にルート証明書を保有している場合、サーバーから送信される必要はありませんでした！

ルート証明書を送信しないという同じロジックは、サーバーがクライアント証明書を検証しようとする場合にも適用されます。同じ正当性がTLS RFCで示されています。同じ正当性

私の発行されたシークレットのca.crtに、私の証明書のチェーンが含まれていないのはなぜですか？

ユーザーは、ca.crtに変更を加えて、より多くの証明書または異なる証明書を含めることについて、頻繁に質問します。私たちは、ca.crtがほとんどの場合、ユーザーにとってリスクであると信じているため、これらの要求を却下する傾向があります。

ca.crtは、発行元CAが何であったかの「最善の推測」でcert-managerによって満たされます。重要なのは、cert-managerは多くの場合推測しかできないことです。発行元がルート証明書を含む完全なチェーンを提供しない場合、cert-managerがチェーンのルートが何かを知る方法がない可能性があります。その場合、cert-managerはチェーンの中で最も深い発行元を使用するよう最善を尽くします。

その「最善の努力」は、ca.crtが危険となる理由の1つです。正しくない可能性があり、cert-managerに変更がない場合でも、発行元が変更されると変更される可能性があります。

ca.crtのもう1つの問題は根本的なものです。証明書が更新されると更新されます。一部のユーザーは信頼のためにca.crtを使用しようとしますが、信頼できる証明書の安全なローテーションは、古いCA証明書と新しいCA証明書の両方を同時に信頼できる場合に依存します。

シークレットからCAを直接使用すると、これが不可能になります。ca.crtには、現在の証明書のCAに対する最善の推測しか含まれず、古いCAまたは新しいCAは含まれません。

cert-managerはすべてのイベントをKubernetesイベントメカニズムに公開します。 kubectl describe <resource> <name>を使用して、特定のリソースのイベントを取得できます。

Kubernetesイベントメカニズムの性質上、これらはしばらくするとパージされます。専用のログシステムを使用している場合は、Kubernetesイベントを既に保存しているか、保存できる可能性があります。

発行に失敗した場合、再試行されますか？

手動による介入が必要なまれな例外的なケースを除き、cert-managerは発行に失敗した場合は再試行します。

ネットワーク接続エラーなどの短命の障害の場合、短い遅延後に再試行し、「終端」障害の後、指数関数的に増加する長い遅延後に再試行することを目指しています。

CertificateのIssuing条件がfalseに設定され、status.lastFailureTimeが設定されている場合、最新の発行が最終的に失敗したことがわかります。この場合、新しいCertificateRequestを作成することで、指数関数的に増加する遅延（1〜32時間）後に発行が再試行されます。cmctl renewコマンドを使用して、すぐに更新をトリガーできます。終端障害は、発行元がCertificateRequestを失敗に設定した場合（たとえば、CAがレート制限に達したために要求を拒否した場合）、または無効な場合、またはCertificateRequestが承認者によって拒否された場合に発生します。

短命の障害は、短い遅延（最大5分）後に同じCertificateRequestを再同期させることになります。通常、それらはcert-managerコントローラーのログでのみ観察できます。

発行がスタックしているように見え、cmctl renewが機能しない場合は、最新のCertificateRequestを削除できます。これはほとんど無害な操作です（起こりうる最悪の事態は、進行中の可能性のある成功した発行がある場合の重複発行です）。しかし、これはユーザーフローの一部ではないようにすることを目指しています。フローを改善できるケースを見つけたと思われる場合は、ご連絡ください。

ECC（楕円曲線暗号）はサポートされていますか？

cert-managerはECDSAキーペアをサポートしています！証明書リソースのprivateKey部分で、証明書がECDSAを使用するように設定できます。

例えば

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ecdsa
spec:
  secretName: ecdsa-cert
  isCA: false
  privateKey:
    algorithm: ECDSA
    size: 256
  dnsNames:
    - ecdsa.example.com
  issuerRef:
    [...]

renewBeforeまたはdurationが定義されていない場合、デフォルト値は何になりますか？

デフォルトのdurationは90日です。renewBeforeが設定されていない場合、Certificateはその実際の期間の2/3で更新されます。

JKSまたはPKCS#12ファイルのパスワードはなぜ役に立たないのですか？

この質問は、次のような多くの形で寄せられます。

  • 「これらのパスワードをハードコードしても大丈夫なのはなぜですか？」
  • 「これらのパスワードを安全に保管する必要がありますか？」
  • 「これらのパスワードは安全な方法で使用されていますか？」

具体的には、このFAQでは、PKCS#12およびJKS「キーストア」のパスワードについて説明します。

簡単な回答

PKCS#12またはJKSファイルの「パスワード」は、ほとんどの場合、セキュリティの場当たり的な対策であり、これらのファイルのパスワードのないバージョンを解析できないアプリケーションをサポートするためにのみ必要です。これらのファイルに安全なパスワードを使用した場合でも（まれですが）、弱い暗号化アルゴリズムと基礎となる素材の管理によって、通常は安全なパスワードが無効になります。

これらのパスワードをレガシー実装の詳細として扱い、パスワードを使用する必要がある場合は、これらのパスワードに短いハードコードされた文字列を使用することをお勧めします。これらのファイルの「安全な」パスワードを生成または処理しようとしないでください。 changeitまたはnotapassword123などの定数を単に選択し、生成するすべてのPKCS#12またはJKSバンドルで使用してください。

詳細な回答

多くの人が、JKSやPKCS#12バンドルを扱う際に「パスワード」という言葉を見て、それが注意深く扱う必要がある貴重なセキュリティリソースであるという当然の結論を導き出します。

一般的に、これは事実ではありません。これらのパスワードは実際にはパスワードではなく、いかなる種類のセキュリティにとっても意味を持つ可能性は非常に低いからです。

ほとんどの場合、これらのパスワードが存在するのは、一部のアプリケーションでパスワードの設定が必要であるためだけです。その要件が、cert-managerとそのサブプロジェクトがこれらの種類のバンドルにパスワードを設定することをサポートする唯一の理由です。

これらのパスワードをセキュリティ上重要ではないと考える主な理由はいくつかあります。

  1. これらのパスワードを使用するほとんどのアプリケーションは、パスワードを含むファイルを、使用するバンドルとまったく同じアクセス許可とアクセス制御で、プレーンテキストでマウントします。これは、最も安全なパスワードであっても、セキュリティ対策として完全に無意味なものになります。
  2. 暗号化されたほとんどのPKCS#12とJKSバンドルは、根本的に安全でない非常に古い暗号化アルゴリズムを使用しています。
  3. 「パスワード」という言葉は、人間が覚えられるパスワードを思い起こさせますが、この種の暗号化には適切ではありません。つまり、使用されるパスワード自体もこのコンテキストでは安全でないことが多いのです。
  4. PKCS#12またはJKSファイルを生成する場合、ほとんどの場合、暗号化されていない秘密鍵と同じSecretに存在します。

非常に詳細な脅威モデルを作成し、システムアーキテクチャに非常に偏執的な方法で真剣な時間を費やさない限り、これらの「パスワード」に時間を費やすことは、ほとんどまたはまったく見返りのない無駄な時間になります。あなたの努力は、ほとんどの場合、他の方法でシステムを保護することに費やした方が良いでしょう。

これらの「パスワード」の使用方法については、上記の「簡単な回答」を参照してください。

その他

Kubernetesには、組み込みのCertificateSigningRequest APIがあります。なぜそれを使用しないのですか？

Kubernetesには、Certificate Signing Requests APIと、証明書署名要求を承認し、Kubernetesクラスタの認証局（CA）によって署名させることができるkubectl certificatesコマンドがあります。

このAPIとCLIは、非制御プレーンPodで使用するための証明書の署名に誤用されることがありますが、これは間違いです。Kubernetesクラスタのセキュリティのために、Kubernetes認証局へのアクセスを制限することが重要であり、制御プレーン以外で使用される証明書の署名にその認証局を使用しないことが重要です。このような証明書は、Kubernetes APIサーバーへの攻撃の機会を増やすからです。

Kubernetes 1.19では、Certificate Signing Requests APIがV1に到達し、要求署名プロセスに従って（または自動化して）より一般的に使用できるようになりました。

cert-managerは現在、このリソースに対して限定的な実験的なサポートを提供しています。

「cert-manager」の書き方

cert-managerは常に小文字で記述する必要があります。タイトルや文頭など、通常は大文字になる場合でも同様です。単語間には常にハイフンを使用し、スペースに置き換えたり、削除したりしないでください。