Os certificados de assinatura de código Java são iguais aos certificados SSL?

Question

Estou procurando por um Java assinatura de código certificado para que meus miniaplicativos Java não emitam avisos de segurança tão assustadores.No entanto, todos os lugares que encontrei que os oferecem cobram (na minha opinião) muito caro, como mais de US$ 200 por ano.Ao fazer pesquisas, um certificado de assinatura de código parece quase exatamente igual a um SSL certificado.

A principal dúvida que tenho:é possível comprar um certificado SSL, mas usá-lo para assinar miniaplicativos Java?

Answer 1

Resposta curta:Não, eles são diferentes.

Resposta longa:É o mesmo tipo de certificado e usa o mesmo software criptográfico, mas o certificado possui sinalizadores que indicam para que ele pode ser usado.Assinatura de código e servidor web são usos diferentes.

Answer 2

Quando importo um novo certificado CA no Firefox (etc.), tenho a opção de escolher em qual certificado confio:

• Servidores de assinatura
• Código de assinatura (como seu miniaplicativo)
• Assinar certificados de e-mail

Então para mim a resposta é:Sim, eles são iguais.Além disso, por que não gerar o seu próprio com OpenSSL (man openssl, man x509, man req, etc.no Unix)?Você quer apenas acalmar os avisos ou você quer outro pessoas que você nunca conheceu confiam em seu código?Se você não precisa que outros usuários encadeiem a confiança às CAs âncoras incluídas em seu navegador, sistema operacional, etc., use o OpenSSL para gerar o seu próprio.

E pergunte "Como uso o OpenSSL para gerar meus próprios certificados?" Se a última é sua escolha.

Answer 3

Thawte oferece certificados de assinatura de código aqui.Imagino que outras autoridades de certificação também ofereçam esse serviço.Você também pode criar certificados autoassinados, com Ferramenta de chave Java.

Answer 4

Os certificados X.509 podem incluir principais campos de uso (KU) e campos de uso de chave estendida (EKU).O Nota técnica da Oracle descrevendo como criar sinais de seus RIAs cria um certificado sem sinalizadores de uso de chave, o que funciona perfeitamente (se você conseguir que uma CA confiável assine)

Porém, cada vez mais, as CAs emitem certificados com esses campos de uso chave.Quando presentes, esses campos restringir o uso do certificado.O plugin java verifica a presença desses campos no 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);
}

Os métodos de verificação são os seguintes:

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

Portanto, se nenhum KU ou EKU for especificado, o verificador KU ou EKU retornará felizmente verdadeiro.

Mas

• se KUs forem especificados, o assinatura digital KU deveria ser um deles.
• se algum EKU for especificado, o EKU assinatura de código (identificado pelo oid 1.3.6.1.5.5.7.3.3) ou o EKU qualquer uso (identificado pelo oid 2.5.29.37.0) também deve ser especificado.

finalmente, o checkRemainingExtensions O método verifica os EKUs críticos restantes.Os únicos outros EKUs críticos que podem estar presentes são

• restrições básicas (oid "2.5.29.19") e
• nome alternativo do assunto (oid 2.5.29.17)

Se encontrar qualquer outro EKU crítico, retornará falso.