Les certificats de signature de code Java sont-ils les mêmes que les certificats SSL?

Question

Je cherche un signature de code Java afin que mes applets Java ne le soient pas. vomir de tels avertissements de sécurité effrayants. Cependant, tous les endroits où je les ai trouvés leur offrent des frais (à mon avis) beaucoup trop élevés, comme plus de 200 USD par an. Pendant les recherches, un certificat de signature de code semble presque identique à un certificat SSL .

La principale question que j'ai: est-il possible d'acheter un certificat SSL, mais l'utiliser pour signer des applets Java?

Answer 1

Réponse courte: Non, ils sont différents.

Réponse longue: il s'agit du même type de certificat et il utilise le même logiciel de cryptographie, mais le certificat comporte des indicateurs indiquant son utilisation. La signature de code et le serveur Web sont des utilisations différentes.

Answer 2

Lorsque j'importe un nouveau certificat de CA dans Firefox (etc.), j'ai la possibilité de choisir le certificat que j'utilise:

• Signer les serveurs
• Code de signature (similaire à votre applet)
• Signer des certificats de messagerie

Donc, pour moi, la réponse est: oui, ce sont les mêmes. De plus, pourquoi ne pas créer le vôtre avec OpenSSL (man openssl, man x509, man req, etc. . sur Unix)? Souhaitez-vous simplement supprimer les avertissements ou , voulez-vous que d'autres personnes que vous n'avez jamais rencontrées fassent confiance à votre code? Si vous n'avez pas besoin que d'autres utilisateurs associent la confiance à l'autorité de certification d'ancrage fournie avec leur navigateur, leur système d'exploitation, etc., utilisez OpenSSL pour générer le vôtre.

Et demandez "Comment utiliser OpenSSL pour générer mes propres certificats?" si ce dernier est votre choix.

Answer 3

Thawte propose des certificats de signature de code ici . J'imagine que d'autres autorités de certification proposent également ce service. Vous pouvez également créer des certificats auto-signés, avec le keytool Java. .

Answer 4

Les

certificats X.509 peuvent inclure des champs d'utilisation des clés (KU). et champs d'utilisation de la clé étendue (les fichiers EKU). La note technique Oracle décrivant la création de signatures de vos RIA crée un certificat sans indicateur d'utilisation de clé, ce qui fonctionne très bien (si vous pouvez le faire signer par une autorité de certification approuvée)

Mais de plus en plus, les autorités de certification émettent des certificats avec ces champs d'utilisation de clé. Lorsqu'ils sont présents, ces champs restreignent l'utilisation du certificat. Le plug-in Java vérifie la présence de ces champs dans le 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);
}

Les méthodes de vérification se présentent comme suit:

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

Donc, si aucun KU ou EKU n'est spécifié, le vérificateur KU ou EKU retourne heureusement vrai.

Mais

• si des unités de base sont spécifiées, la signature numérique KU devrait être l'une d'entre elles.
• si des unités EKU sont spécifiées, soit la signature de code EKU (identifiée par l'identifiant d'objet 1.3.6.1.5.5.7.3.3), soit la utilisation EKU (identifiée par oid 2.5.29.37.0) devrait également être spécifié.

Enfin, la méthode checkRemainingExtensions vérifie les EKU critiques restants. Les seuls autres EKU critiques autorisés à être présents sont

• contraintes de base (oid "2.5.29.19") et
• nom de l'objet alt (oid 2.5.29.17)

S'il trouve un autre EKU critique, il renvoie false.