Sind Java Code Signing-Zertifikate der gleiche wie SSL-Zertifikate?

Question

Ich bin auf der Suche rund um für ein Java Codesignierung Zertifikats so meine Java-Applets nicht tun werfen so beängstigend Sicherheitswarnungen auf. Doch all die Orte, die ich gefunden habe sie gegen Bezahlung (meiner Meinung nach) viel zu viel, wie über USD200 pro Jahr. Während die Forschung zu tun, scheint ein Codesignierungszertifikat fast genau das gleiche wie ein SSL Zertifikat.

Die wichtigste Frage habe ich: ist es möglich, ein SSL-Zertifikat zu kaufen, aber es verwenden, Java-Applets zu unterschreiben

?

Answer 1

Kurze Antwort:. Nein, sie sind anders

Lange Antwort: Es ist die gleiche Art von Zertifikat und verwendet die gleiche Krypto-Software, aber das Zertifikat hat Flags, die angeben, was es erlaubt ist, für verwendet werden. Code-Signing und Web-Server sind verschiedene Verwendungen.

Answer 2

Wenn ich ein neues CA-Zertifikat in Firefox importieren (etc.) Ich habe die Möglichkeit, die Entscheidung, welches Zertifikat verwendet vertraue ich:

• Sign-Server
• Zeichen-Code (wie Ihr Applet)
• Zeichen E-Mail-Zertifikate

Also mir die Antwort lautet: Ja, sind sie gleich. Außerdem, warum nicht Ihre eigenen erzeugen mit OpenSSL (Mann openssl, Mann x509, Mann req, etc . auf Unix)? Wollen Sie beruhigen nur die Warnungen oder wollen Sie andere Menschen, die Sie noch nie getroffen haben, Ihren Code zu vertrauen? Wenn Sie an der Kette Vertrauen auf den Anker CA gebündelt mit ihrem Browser keine anderen Benutzer benötigen, OS usw., dann OpenSSL verwenden, um Ihre eigenen zu erzeugen.

Und fragen: „Wie verwende ich OpenSSL meine eigenen Zertifikate zu generieren?“ wenn dieser Ihre Wahl.

Answer 3

Thawte bietet Code-Signing-Zertifikate hier . Ich stelle mir vor anderen Zertifizierungsstellen diesen Service auch anbieten. Sie können auch selbst signierten Zertifikaten, mit Java keytool erstellen .

Answer 4

X.509-Zertifikate können Schlüsselverwendungsfelder (ku) und erweiterten Schlüsselverwendung Felder (EKU ist). Die Oracle Tech-Note beschreibt, wie Sie Ihre RIA erstellen unterzeichnen erstellt ein Zertifikat ohne Schlüsselverwendung Flaggen, die ganz gut funktioniert (wenn Sie eine vertrauenswürdige Zertifizierungsstelle bekommen können, es zu unterzeichnen)

Aber mehr und mehr, CA Zertifikate ausstellen mit diesen Schlüsselverwendungsfeldern. Wenn sie vorhanden sind, diese Felder beschränken , um die Nutzung des Zertifikats. Das Java-Plugin überprüft das Vorhandensein dieser Felder in der 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);
}

Die Kontrollmethoden wie folgt aussehen:

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

Also, wenn keine KU oder EKU angegeben, glücklich der KU oder EKU-Checker gibt true zurück.

Aber

• wenn Kus angegeben sind, die digitale Signatur KU einer von ihnen sein sollte.
• , wenn eine EKU die angegeben werden, entweder die EKU Codesignierung (von oid 1.3.6.1.5.5.7.3.3 identifiziert) oder die EKU jeder Nutzung (gekennzeichnet durch oid 2.5.29.37.0) sollten ebenfalls angegeben werden.

Schließlich prüft das checkRemainingExtensions Verfahren die verbleibenden kritischen EKU ist. Die einzige andere kritische EKU ist erlaubt anwesend sein werden

• Grund Einschränkungen (oid "2.5.29.19") und
• Alternativname (oid 2.5.29.17)

Wenn es andere kritische EKU findet, es gibt false zurück.