CapturePlugin: ssl-Fehler bei https

Antwort erstellen


Diese Frage dient dazu, das automatisierte Versenden von Formularen durch Spam-Bots zu verhindern.

BBCode ist eingeschaltet
[img] ist eingeschaltet
[url] ist eingeschaltet
Smileys sind ausgeschaltet

Die letzten Beiträge des Themas

Ich habe die Datenschutzerklärung gelesen und bin damit einverstanden.

   

Ansicht erweitern Die letzten Beiträge des Themas: CapturePlugin: ssl-Fehler bei https

Re: CapturePlugin: ssl-Fehler bei https

von llarevo_2 » 19 Mai 2014, 18:57

Hallo,

vielen Dank für die Antworten. Zum einen kann man durchaus im CapturePlugin eine URL eintragen. Das legt zumindest nahe, das auch mit HTTPS zu versuchen.

Zum Anderen scheint es ein Problem mit virtuellen Hosts zu sein. Versuchsweise habe ich eben die virtuellen Hosts serverseitig auskonfiguriert und und dann gelingt mir die Kontaktaufnahme. Das wiederum deutet m.E. darauf hin, das Server Name Indication (SNI) pluginseitig nicht implementiert ist.

Ich bin dann weiter darüber gestolpert, dass die Syntax nutzer:passwort@server zur http-Authentifizierung offenbar auch nicht richtig geht.

Da ich auch nicht vorhabe, selbst am TV-Browser rumzuprogrammieren, werde ich es tatsächlich über ein Script lösen, welches curl oder wget aufruft. Dazu herzlichen Dank für die Idee, darauf wäre ich in meiner Betriebsblindheit nicht gekommen ;-)

--
Felix

P.S. Edit: Typos

Re: CapturePlugin: ssl-Fehler bei https

von uzi » 19 Mai 2014, 13:42

da ich mich gerade selbst mit https + cert rumgeschlagen habe, poste ich hier einfach mal ohne zusätzliche kommentare die dabei herausgekommene methode:

Code: Alles auswählen

/**
     * initialisiert https. dazu wird das zertifikat aus dem keystore geholt und für https zur verfügung gestellt. der ablauf ist hier sehr schön beschrieben:
     * http://stackoverflow.com/questions/8339200/how-can-i-use-certificate-authentication-with-httpsurlconnection
     * 
     * achtung: der per https aufgerufene host muss im zertifikat hinterlegt sein. wenn es ein dns name ist, muss im cert im CN auch dieser name stehen. wenn man versucht eine ip
     * aufzurufen, obwohl im cert ein dns name steht, wirft java eine exception. ausführlich wird das hier beschrieben:
     * http://stackoverflow.com/questions/8443081/how-are-ssl-certificate-server-names-resolved-can-i-add-alternative-names-using/8444863#8444863
     * http://stackoverflow.com/questions/19540289/how-to-fix-the-java-security-cert-certificateexception-no-subject-alternative
     */
    private void setupHttps() {
        try {
            KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
            trustStore.load(new FileInputStream(keystorePath), keystorePassword.toCharArray());
            TrustManagerFactory trustFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
            trustFactory.init(trustStore);
            TrustManager[] trustManagers = trustFactory.getTrustManagers();
            SSLContext sslContext = SSLContext.getInstance("SSL");
            sslContext.init(null, trustManagers, null);
            SSLContext.setDefault(sslContext);
            
            //dieser code-schnippsel deaktiviert den identity-check, also die prüfung, ob der aufgerufene host zum verwendeten zertifikat passt. das ist nützlich, wenn das cert
            //falsch ausgestellt wurde, sollte aber AUF KEINEN FALL in einer produktiven umgebung eingesetzt werden. dort ist ein korrektes zertifikat zu benutzen!
//            HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
//                public boolean verify(String hostname, SSLSession session) {
//                    if (hostname.equals("1.1.1.1")) {
//                        return true;
//                    }
//                    return false;
//                }
//            });
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
der eigentliche verbindungsaufbau bleibt, wie gehabt:

Code: Alles auswählen

HttpURLConnection connection = (HttpURLConnection) url.openConnection();
an der stelle könnte man allerdings auch auf HttpsURLConnection casten, wenn nötig. aber normalerweise will man ja http und https gleiche behandeln, insofern macht das wenig sinn.

ob das so der weisheit letzter schluss ist, wage ich mal zu bezweifeln, aber zumindest tut es, was es soll ;). allerdings arbeitet der code mit einer expliziten config des keystores und nicht mit system properties. der weg wurde allerdings auch irgendwo in den links im code beschrieben. mit entsprechenden libs geht das ganze sicher auch einfacher - ich sach mal apache http client.

Re: CapturePlugin: ssl-Fehler bei https

von ds10 » 19 Mai 2014, 10:06

Also da bin ich auch überfragt, eine solche Möglichkeit ist vom CapturePlugin nicht vorgesehen. Vielleicht ließe sich ja ein Shellscript schreiben, was mit dem Server kommunizieren kann und dann lokal auf dem Rechner mit TV-Browser läuft.

CapturePlugin: ssl-Fehler bei https

von llarevo_2 » 18 Mai 2014, 18:05

Hallo,

ich versuche ein php-Script mittels https aus dem Capture-Plugin heraus über eine URL (kann ich nicht posten, das Board verbietet mir URL's :-) aufzurufen. Trotz einiger Versuche ohne Erfolg.

Ich habe versucht, das selbst signierte Server-Zertifikat in den Java Keystore zu importieren und tvbrowser dazu zu bewegen, den so mit meinem Zertiifikat ergänzten Keystore zu nutzen. Details dazu, s.u. Ist das überhaupt die richtige Strategie? Wenn ja, wo liegt der Fehler? Ist es überhaupt möglich ssl-Verbindungen aus dem TV-Browser heraus zu Servern, die mit selbst signierten Zertifikaten betrieben werden aufzubauen?

Der Fehler, den CapturePlugin meldet ist (verkürzt):

javax.net.ssl.SSLHandshakeException java.security.cert.CertificateException: No name matching media-server found
(...)
java.security.cert.CertificateException No name matching media-server found
(...)

Das Server-Zertifikat besitzt die richtigen Hostname-Angaben sowohl im CN als auch den DNS-Einträgen:

Ich habe dieses Zertifikat sowohl in den systemweiten Keystore unter cacerts als auch in einen separaten, eigenen Keystore im tvbrowser Programm-Verzeichnis importiert.

Beide Versuche gelangen offensichtlich. Ich wurde nach dem Keystorepasswort gefragt, das Zertifikat wurde erkannt, ich wurde gefragt, ob ich dem Zertifikat vertraute, nach Beantwortung mit "Ja" wurde das Zertifikat ohne Probleme importiert. Es lässt sich auflisten und sogar erfolgreich wieder exportieren.

Danach habe ich ohne Erfolg auf verschiedenen Wegen versucht, mittels Ergänzung des Aufrufs von tvbrowser.jar den ergänzten Keystore zu nutzen:

${JAVA_PROGRAM_DIR}java -Xms16m -Xmx320m -Djava.library.path="${PROGRAM_DIR}" -Dpropertiesfile=linux.properties -Djavax.net.ssl.trustStore=cacerts -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.debug -jar tvbrowser.jar "$@"

${JAVA_PROGRAM_DIR}java -Xms16m -Xmx320m -Djava.library.path="${PROGRAM_DIR}" -Dpropertiesfile=linux.properties -Djavax.net.ssl.keyStore=cacerts -Djavax.net.ssl.keyStorePassword=changeit -Djavax.net.debug -jar tvbrowser.jar "$@"

${JAVA_PROGRAM_DIR}java -Xms16m -Xmx320m -Djava.library.path="${PROGRAM_DIR}" -Dpropertiesfile=linux.properties -Djavax.net.ssl.trustStore=cacerts -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.ssl.keyStore=cacerts -Djavax.net.ssl.keyStorePassword=changeit -Djavax.net.debug -jar tvbrowser.jar "$@"

${JAVA_PROGRAM_DIR}java -Xms16m -Xmx320m -Djava.library.path="${PROGRAM_DIR}" -Dpropertiesfile=linux.properties -Djavax.net.ssl.trustStore=cacerts -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.ssl.keyStore=cacerts -Djavax.net.ssl.keyStorePassword=changeit -Djavax.net.ssl.allowLegacyHelloMessages=true -Djavax.net.ssl.allowUnsafeRenegotiation=true -Djavax.net.debug -jar tvbrowser.jar "$@"

Die Fehlermeldung bleibt immer gleich.

Was kann ich tun, um https-Aufrufe möglich zu machen?

Vielen Dank im Voraus!
--
Felix

Nach oben