Javaコード署名証明書はSSL証明書と同じですか？

Question

私はJava code signing証明書を探していますので、Javaアプレットはそのような恐ろしいセキュリティ警告を投げません。しかし、私が見つけたすべての場所は、年間200ドルを超えるように（私の意見では）あまりにも多く料金を請求しています。研究中に、コード署名証明書はSSL証明書とほぼ同じように見えます。

私が持っている主な質問：SSL証明書を購入することは可能ですが、それを使ってJavaアプレットに署名しますか？

Answer 1

短い回答：いいえ、彼らは異なっています。

長い回答：同じ種類の証明書で、同じ暗号ソフトウェアを使用しますが、証明書には何が使用できるかを示すフラグがあります。コード署名とWebサーバーは異なる用途です。

Answer 2

私は、Firefox（など）で新しいCA証明書をインポートするとき、私は証明書は、私が信頼して使用して選択するオプションを持っている：（アプレットなど）

• ログイン・サーバ
• サインコード
• 電子メール証明書に署名する

私には答えがあります：はい、同じです。さらに、OpenSSL（Unixではopenssl、man x509、man reqなど）で自分自身を生成してみませんか？ またはあなたがしたいことはありません他あなたのコードを信頼するために一度も会ったことのない人ですか？あなたのブラウザ、OSなどにバンドルされているアンカーCAへの信頼を連鎖させるために他のユーザを必要としない場合は、OpenSSLを使用して独自のものを生成してください。

「OpenSSLを使用して独自の証明書を生成するにはどうすればよいですか？後者があなたの選択である場合。

Answer 3

Thawteはコード署名証明書hereを提供しています。他の認証局もこのサービスを提供していると思います。 Java keytoolで自己署名証明書を作成することもできます。

Answer 4

X.509証明書には、key usage fields（KU）とextended key usage fields（EKU）が含まれます。 Oracle tech note describing how to create sign your RIA'sは、鍵の使用フラグがなくても証明書を作成します（信頼できるCAに署名することができればうまく動作します）

しかし、これらの主要な使用分野に関するCAの発行証明書がますます増えています。これらのフィールドがある場合、はの証明書の使用を制限します。 EndEntityCheckerでこれらのフィールドの存在のためのJavaプラグインをチェック：

/** 
* Check whether this certificate can be used for code signing. 
* @throws CertificateException if not. 
*/ 
private void checkCodeSigning(X509Certificate cert) 
     throws CertificateException { 
    Set<String> exts = getCriticalExtensions(cert); 

    if (checkKeyUsage(cert, KU_SIGNATURE) == false) { 
     throw new ValidatorException 
      ("KeyUsage does not allow digital signatures", 
      ValidatorException.T_EE_EXTENSIONS, cert); 
    } 

    if (checkEKU(cert, exts, OID_EKU_CODE_SIGNING) == false) { 
     throw new ValidatorException 
      ("Extended key usage does not permit use for code signing", 
      ValidatorException.T_EE_EXTENSIONS, cert); 
    } 

    if (!SimpleValidator.getNetscapeCertTypeBit(cert, NSCT_SSL_CLIENT)) { 
     throw new ValidatorException 
      ("Netscape cert type does not permit use for SSL client", 
      ValidatorException.T_EE_EXTENSIONS, cert); 
    } 

    // do not check Netscape cert type for JCE code signing checks 
    // (some certs were issued with incorrect extensions) 
    if (variant.equals(Validator.VAR_JCE_SIGNING) == false) { 
     if (!SimpleValidator.getNetscapeCertTypeBit(cert, NSCT_CODE_SIGNING)) { 
      throw new ValidatorException 
       ("Netscape cert type does not permit use for code signing", 
       ValidatorException.T_EE_EXTENSIONS, cert); 
     } 
     exts.remove(SimpleValidator.OID_NETSCAPE_CERT_TYPE); 
    } 

    // remove extensions we checked 
    exts.remove(SimpleValidator.OID_KEY_USAGE); 
    exts.remove(SimpleValidator.OID_EXTENDED_KEY_USAGE); 

    checkRemainingExtensions(exts); 
} 

チェック方法のように見えるが、以下：

/** 
* Utility method checking if the extended key usage extension in 
* certificate cert allows use for expectedEKU. 
*/ 
private boolean checkEKU(X509Certificate cert, Set<String> exts, 
     String expectedEKU) throws CertificateException { 
    List<String> eku = cert.getExtendedKeyUsage(); 
    if (eku == null) { 
     return true; 
    } 
    return eku.contains(expectedEKU) || eku.contains(OID_EKU_ANY_USAGE); 
} 

だから、何KUまたはEKUが指定されていない場合は、KUまたはEKUチェッカー楽しくtrueを返します。

しかし

• KUさんが指定されている場合、デジタル署名 KUは、そのうちの一つでなければなりません。
• 任意EKUのは、（OID 2.5.29.37.0によって識別される）任意の使用が指定されなければならないのいずれか（OID 1.3.6.1.5.5.7.3.3によって識別される）署名EKU コードまたはEKU 、指定された場合同じように。

最後に、checkRemainingExtensionsメソッドは残りの重要なEKUをチェックします。唯一の他の重要なEKUのが存在することが許されている

• 基本制約（OID "2.5.29.19"）と
• サブジェクト代替名（OID 2.5.29.17）

の場合他の重要なEKUを見つけたら、それは偽を返します。