Pregunta

Estoy buscando un Java firma de código certificado para que mis subprogramas de Java no muestren advertencias de seguridad tan aterradoras.Sin embargo, todos los lugares que he encontrado que los ofrecen cobran (en mi opinión) demasiado, como más de 200 dólares al año.Al investigar, un certificado de firma de código parece casi exactamente igual a un SSL certificado.

La pregunta principal que tengo:¿Es posible comprar un certificado SSL, pero utilizarlo para firmar subprogramas de Java?

¿Fue útil?

Solución

Respuesta corta:No, son diferentes.

Respuesta larga:Es el mismo tipo de certificado y utiliza el mismo software criptográfico, pero el certificado tiene indicadores que indican para qué se permite su uso.La firma de código y el servidor web son usos diferentes.

Otros consejos

Cuando importo un nuevo certificado de CA en Firefox (etc.), tengo la opción de elegir en qué usos de certificado confío:

  • Servidores de firmas
  • Código de firma (como su subprograma)
  • Firmar certificados de correo electrónico

Entonces para mí la respuesta es:Sí, son iguales.Además, ¿por qué no generar el tuyo propio con AbiertoSSL (hombre openssl, hombre x509, hombre req, etc.en Unix)?¿Quieres simplemente silenciar las advertencias? o Quieres otro ¿Personas que nunca has conocido confían en tu código?Si no necesita que otros usuarios encadenen la confianza a las CA ancla incluidas con su navegador, sistema operativo, etc., utilice OpenSSL para generar el suyo propio.

Y pregunte "¿Cómo uso OpenSSL para generar mis propios certificados?" Si este último es su elección.

Thawte ofrece certificados de firma de código aquí.Me imagino que otras autoridades certificadoras también ofrecen este servicio.También puede crear certificados autofirmados, con herramienta clave de Java.

Los certificados X.509 pueden incluir campos de uso clave (KU) y campos de uso de claves extendidos (EKU).El Nota técnica de Oracle que describe cómo crear signos de su RIA crea un certificado sin ningún indicador de uso de clave, lo que funciona bien (si puede conseguir que una CA confiable lo firme)

Pero cada vez más, las CA emiten certificados con estos campos de uso clave.Cuando están presentes, estos campos restringir el uso del certificado.El complemento de Java comprueba la presencia de estos campos en el 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);
}

Los métodos de verificación son los siguientes:

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

Entonces, si no se especifica KU o EKU, el verificador de KU o EKU felizmente devuelve verdadero.

Pero

  • si se especifican KU, el firma digital KU debería ser uno de ellos.
  • si se especifica algún EKU, ya sea el EKU firma de código (identificado por oid 1.3.6.1.5.5.7.3.3) o el EKU cualquier uso (identificado por oid 2.5.29.37.0) también debe especificarse.

Finalmente, el checkRemainingExtensions El método comprueba los EKU críticos restantes.Los únicos otros EKU críticos permitidos que estén presentes son

  • restricciones básicas (oid "2.5.29.19") y
  • nombre alternativo del sujeto (oideo 2.5.29.17)

Si encuentra cualquier otro EKU crítico, devuelve falso.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top