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

Question

Я оглядываюсь на сертификат Java code signing, поэтому мои Java-апплеты не вызывают таких страшных предупреждений о безопасности. Тем не менее, все места, которые я нашел, предлагают им взимать плату (на мой взгляд) слишком много, например, более 200 долларов США в год. При проведении исследований сертификат подписи кода кажется почти таким же, как и сертификат SSL.

Главный вопрос, который у меня есть: можно ли купить сертификат SSL, но использовать его для подписи Java-апплетов?

Answer 1

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

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

Answer 2

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

• Войдите серверы
• Зарегистрировать код (как ваш апплет)
• Знак почтовых сертификатов

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

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

Answer 3

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

Answer 4

Сертификаты X.509 могут включать key usage fields (KU) и extended key usage fields (EKU's). Oracle tech note describing how to create sign your RIA's создает сертификат без каких-либо ключевых флагов использования, который работает очень хорошо (если вы можете получить доверенный ЦС для его подписания)

Но все больше сертификатов выпуска CA с этими ключевыми полями использования. Когда они присутствуют, эти поля ограничивают использование сертификатов. Проверки Java Plugin на наличие этих полей в 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 или ЭК не указан, KU или ЭК проверки счастливо возвращает true.

Но

• если указаны KU-х, цифровая подпись KU должен быть один из них.
• если ЭКУ-х указаны, либо ЭКУ код подписания (идентифицированный OID 1.3.6.1.5.5.7.3.3) или EKU любое использование (идентифицируется OID 2.5.29.37.0) должны быть указаны также.

Наконец, метод checkRemainingExtensions проверяет оставшиеся критические EKU. Единственный критический ЭКУ позволено присутствовать в

• основные ограничения (подъязычная "2.5.29.19") и
• имя субъекта альт (подъязычная 2.5.29.17)

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