web-dev-qa-db-ja.com

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

Java コード署名 証明書を探しているので、Javaアプレットはそのような恐ろしいセキュリティ警告をスローしません。しかし、私が見つけたすべての場所では、(私の意見では)料金が高すぎます。たとえば、年間200米ドルを超えています。調査中、コード署名証明書は [〜#〜 ] ssl [〜#〜] 証明書。

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

40
davr

簡単な答え:いいえ、違います。

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

39
John Meagher

Firefox(など)に新しいCA証明書をインポートするとき、信頼できる証明書の使用を選択するオプションがあります。

  • サインサーバー
  • サインコード(アプレットなど)
  • 電子メール証明書に署名する

だから私にとっての答えは:はい、それらは同じです。さらに、 OpenSSL (Unixではman openssl、man x509、man reqなど)を使用して独自に生成してみませんか?警告を静かにしますかまたは必要ですかその他あなたのコードを信頼するために会ったことのない人?他のユーザーがブラウザやOSなどにバンドルされているアンカーCAに信頼を連鎖させる必要がない場合は、OpenSSLを使用して独自のCAを生成します。

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

4
Purfideas

X.509証明書には、 キー使用フィールド (KU)および 拡張キー使用フィールド (EKU)が含まれる場合があります。 RIAの署名を作成する方法を説明するOracleテクニカルノート キー使用フラグなしで証明書を作成します。これは問題なく機能します(信頼できるCAに署名してもらうことができる場合)

しかし、ますます多くのCAが、これらの主要な使用フィールドで証明書を発行しています。存在する場合、これらのフィールドrestrictは証明書の使用法です。 Javaプラグインは EndEntityChecker にこれらのフィールドが存在するかどうかをチェックします:

/**
 * 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はそのうちの1つである必要があります。
  • eKUが指定されている場合は、EKUコード署名(oid 1.3.6.1.5.5.7.3.3で識別)またはEKU任意の使用法(oid 2.5.29.37.0で識別)も指定する必要があります。

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

  • 基本的な制約(oid "2.5.29.19")および
  • サブジェクト代替名(oid 2.5.29.17)

他の重要なEKUが見つかった場合は、falseを返します。

1
flup

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

1
jtimberman