Являются ли сертификаты подписи кода Java одинаковыми с сертификатами SSL?

Ответ 1

Короткий ответ: Нет, они разные.

Длинный ответ: это тот же самый сертификат, и он использует одно и то же программное обеспечение криптографии, но в сертификате есть флажки, указывающие, для чего его можно использовать. Подписание кода и веб-сервер различны.

Ответ 2

Когда я импортирую новый сертификат CA в Firefox (и т.д.), я могу выбрать, какой сертификат использует, я доверяю:

• Подписать серверы
• Подписать код (например, ваш апплет)
• Подписать почтовые сертификаты

Итак, для меня ответ: Да, они одинаковы. Кроме того, почему бы не создать свой собственный OpenSSL (man openssl, man x509, man req и т.д. В Unix)? Вы хотите просто успокоить предупреждения или вы хотите, чтобы другие люди, которых вы никогда не встречали, доверяли вашему коду? Если вам не нужны другие пользователи, чтобы привязать доверие к CA-привязке в комплекте со своим браузером, ОС и т.д., Используйте OpenSSL для генерации собственных.

И спросите: "Как использовать OpenSSL для создания собственных сертификатов?" если последний ваш выбор.

Ответ 3

Thawte предлагает сертификаты подписи кода здесь. Я полагаю, что другие службы сертификации также предлагают эту услугу. Вы также можете создавать самозаверяющие сертификаты, Java keytool.

Ответ 4

Сертификаты X.509 могут включать поля использования ключа (KU) и расширенные поля использования ключа (EKU). Техническая нота Oracle, описывающая, как создать знак вашего RIA, создает сертификат без каких-либо ключевых флагов использования, который работает просто отлично (если вы можете получить доверенный CA, чтобы его подписать)

Но все больше и больше 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);
}

Методы проверки выглядят следующим образом:

/**
 * 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, также необходимо указать либо подписание кода 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" ) и
• subject alt name (oid 2.5.29.17)

Если он находит любой другой критический EKU, он возвращает false.