Java 代码签名证书是否与 SSL 证书相同？

Are Java code signing certificates the same as SSL certificates?

提问by davr

I'm looking around for a Java code signingcertificate so my Java applets don't throw up such scary security warnings. However, all the places I've found offering them charge (in my opinion) way too much, like over USD200 per year. While doing research, a code signing certificate seems almost exactly the same as an SSLcertificate.

我正在四处寻找 Java代码签名证书，这样我的 Java 小程序就不会发出如此可怕的安全警告。然而，我发现所有提供它们的地方（在我看来）收费太多了，比如每年超过 200 美元。在进行研究时，代码签名证书似乎与SSL证书几乎完全相同。

The main question I have: is it possible to buy an SSL certificate, but use it to sign Java applets?

我的主要问题是：是否可以购买 SSL 证书，但使用它来签署 Java 小程序？

采纳答案by John Meagher

Short answer: No, they're different.

简短回答：不，它们是不同的。

Long answer: It's the same sort of certificate and it uses the same crypto software, but the certificate has flags indicating what it is allowed to be used for. Code signing and web server are different uses.

长答案：这是同一种证书，它使用相同的加密软件，但证书有标志，表明它被允许用于什么。代码签名和 Web 服务器是不同的用途。

回答by Purfideas

When I import a new CA certificate in Firefox (etc.) I have the option of choosing which certificate uses I trust:

当我在 Firefox（等）中导入新的 CA 证书时，我可以选择使用我信任的证书：

• Sign servers
• Sign code (like your applet)
• Sign email certificates

• 签名服务器
• 签名代码（如您的小程序）
• 签署电子邮件证书

So to me the answer is: Yes, they're the same. Furthermore, why not generate your own with OpenSSL(man openssl, man x509, man req, etc. on Unix)? Do you want to just quiet down the warnings ordo you want otherpeople whom you've never met to trust your code? If you don't need other users to chain trust to the anchor CA's bundled with their browser, OS, etc., then use OpenSSL to generate your own.

所以对我来说答案是：是的，它们是一样的。此外，为什么不使用OpenSSL生成您自己的 （Unix 上的 man openssl、man x509、man req 等）？您是想让警告安静下来，还是想让您从未见过的其他人信任您的代码？如果您不需要其他用户将信任链接到与他们的浏览器、操作系统等捆绑在一起的锚点 CA，那么请使用 OpenSSL 生成您自己的。

And ask "How do I use OpenSSL to generate my own certificates?" if the latter is your choice.

并询问“我如何使用 OpenSSL 生成我自己的证书？” 如果后者是你的选择。

回答by jtimberman

Thawte offers code signing certificates here. I imagine other Certificate Authorities offer this service as well. You can also create self-signed certificates, with Java keytool.

Thawte在此处提供代码签名证书。我想其他证书颁发机构也提供此服务。您还可以使用Java keytool创建自签名证书。

回答by flup

X.509 certificates may include key usage fields(KU's) and extended key usage fields(EKU's). The Oracle tech note describing how to create sign your RIA'screates a certificate without any key usage flags, which works just fine (if you can get a trusted CA to sign it)

X.509 证书可能包括密钥使用字段(KU) 和扩展密钥使用字段(EKU)。描述如何创建 RIA 签名的Oracle 技术说明创建了一个没有任何密钥使用标志的证书，这很好用（如果您可以获得受信任的 CA 对其进行签名）

But more and more, CA's issue certificates with these key usage fields. When present, these fields restrictthe usage of the certificate. The java plugin checks for the presence of these fields in the EndEntityChecker:

但是，CA 越来越多地使用这些关键使用字段颁发证书。如果存在，这些字段会限制证书的使用。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);
}

The check methods look as follows:

检查方法如下所示：

/**
 * 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);
}

So if no KU or EKU is specified, the KU or EKU checker happily returns true.

因此，如果未指定 KU 或 EKU，则 KU 或 EKU 检查器会很高兴地返回 true。

But

但

• if KU's are specified, the digital signatureKU should be one of them.
• if any EKU's are specified, either the EKU code signing(identified by oid 1.3.6.1.5.5.7.3.3) or the EKU any usage(identified by oid 2.5.29.37.0) should be specified as well.

• 如果指定了KU ，则数字签名KU 应该是其中之一。
• 如果指定了任何 EKU，则还应指定EKU代码签名（由 oid 1.3.6.1.5.5.7.3.3 标识）或 EKU任何用法（由 oid 2.5.29.37.0 标识）。

Finally, the checkRemainingExtensionsmethod checks the remaining critical EKU's. The only other critical EKU's allowed to be present are

最后，该checkRemainingExtensions方法检查剩余的关键 EKU。唯一允许出现的其他关键 EKU 是

• basic constraints(oid "2.5.29.19") and
• subject alt name(oid 2.5.29.17)

• 基本约束（oid "2.5.29.19"）和
• 主题替代名称（oid 2.5.29.17）

If it finds any other critical EKU, it returns false.

如果它发现任何其他关键 EKU，则返回 false。