web-dev-qa-db-ja.com

java keytool-キーストアの所有者と発行者の情報を変更する方法は？

所有者としての証明書と発行者情報として「不明」のキーストアを最初に使用した製品があります。

セキュリティポリシー上の理由から、互換性を保証しながら、元の公開鍵と秘密鍵のペアを保持しながら、所有者と発行者の情報を更新する必要があります（後方互換性のため）。

そのようなことは可能ですか？

certificateskey-generation
1
Melo

TLDR：証明書を変更することはできません。 replaceできます。

証明書はデジタル署名されているため、証明書の内容を変更することはできません。ただし、同じ鍵ペアの新しい証明書を取得できますが、新しい日付、異なる名前、およびその他の変更が含まれる可能性があります。

実際のCAは、所有者（実際はサブジェクト）または発行者のいずれかが「不明」のみを含む証明書を発行しません。両方ともはるかに少ないため、これはほぼ間違いなくkeytoolによって作成されたダミー（プレースホルダー）自己署名証明書です。キーペアを生成します。

確立した信頼できる認証局、別名CAからget 'real' certを行う場合は、keytool;を使用できます。実際、これは通常のプロセスです。

  1. keytool -genkeypair：キーペアと自己署名証明書を（キーストアに）作成します
  2. keytool -certreq：証明書署名要求またはCSR（キーストアのキーペア用）を作成します
  3. iDの証拠（多くの場合、特にSSL/TLSサーバー、インターネットドメイン名、場合によっては別の種類のID）と、該当する場合は支払いとともに、CSRをCAに送信します
  4. 該当する「チェーン」または「中間」証明書とともにCAから新しい証明書を受信/取得する
  5. keytool -importcert：新しい証明書をインストールしてキーストアにチェーンします

Javaのマニュアル https://docs.Oracle.com/javase/8/docs/technotes/tools/unix/keytool.html#keytool_examples などのマニュアルを参照してください。手順3と4の詳細は、使用するCAによって異なり、私が今まで見たすべてのCAは、Javaシステムに証明書を発行するためのカスタマイズされた手順を持っています。 'typical' Javaシステム、そのCAに合わせて調整されています。ステップ1は事実上完了していますが、サブジェクト名が間違っています。残りのステップを1つのバリエーションで完了する必要があります。

  • ステップ2でkeytool -certreqオプション-dname 'newnamefields'を追加し（Windowsでは"を使用）、CSRの修正されたリクエスター/サブジェクト名を指定します。

証明書名に関する一般情報は、同じページにあります 見出しX.500識別名 。この証明書（およびキー）がSSL/TLSサーバー用である場合、サブジェクト名は'CN=servername'であるか含まれている必要があります。ここで、servernameはマニュアルに記載されている人物の名前ではなく、代わりにクライアントがアクセスしたときのサーバーの名前に一致する名前またはワイルドカード（最初のコンポーネントのみ）。パブリック/インターネットサーバーの場合、これは通常、完全修飾ドメイン名（別名FQDN）またはまれにIPアドレスですが、一部のイントラネットまたはLAN環境は他の名前を使用します。

Otherwise：新しい自己署名証明書を作成する場合、keytoolにはそのオプションがありません。それを実行するプログラムを作成することもできますが、少し遠回りですが、代わりにse OpenSSLを使用する方が簡単です。 OpenSSLを使用して、keytoolがサポートしていないオプションをいくつか使用して実際のCA証明書を要求することもできます。 Linuxを使用している場合は、おそらくOpenSSLがすでにインストールされています。他のUnixでは、ほとんどの場合、ベンダーの通常のリポジトリ/チャネル/ etcからインストールする必要があります。 Windows（WSLを搭載したWindows10を除く）では、 ShiningLightパッケージ をインストールする必要があります。概要は次のとおりです。

  1. keytool -importkeystore -srckeystore jksfile -destkeystore tempp12 -deststoretype pkcs12 # convert from Java-only JKS to standardized PKCS12

  2. openssl pkcs12 -in tempp12 -nocerts -out tempkey # convert from PKCS12 to OpenSSL's 'private' PEM format

  3. 自己署名の場合：openssl req -new -x509 -inkey tempkey -validity days -out newcertと名前のプロンプトに応答（または-subj 'namefields'を指定）。詳細については、UNIXのman req、または Webまたは以前のバージョンの該当する場合 を参照してください。次にkeytool -importcert -file newcert -keystore jksfile [-alias entry_if_not_mykey]

  4. CA署名の場合：必要に応じてOpenSSL構成ファイル（またはコピー）を変更してからopenssl req -new [-config conffile] -inkey tempkey [-subj 'namefields'] -out csrfileを実行し、上記のJavaの場合と同じ方法でこのCSRをCAに送信します。新しい証明書とそのチェーンを取得するには、次のoneを実行します。

    4a。 keytool -importcert必要なチェーン証明書を別のエントリに、またはJavaで説明したように、上から下に個別に別のエントリに、次にEE証明書を同じエントリに

    4b。 EE証明書とそのチェーン証明書をすべてPEMで1つのファイルに結合し、チェーン全体を同じエントリにkeytool -importcert

    4c。 openssl pkcs12 -exportを使用して、tempkeyと（新しい）証明書を結合し、単一のファイルにチェーンして、newp12ごとにman pkcs12または ここまたはそれ以前 と言います。 、古いエントリを削除した後、keytool -importkeystore -srckeystore newp12 -srcstoretype pkcs12 -destkeystore jksfile、またはこれが（望ましい）エントリのみの場合はファイルを削除します。

2
dave_thompson_085