Falsche Warnung erhalten: handshake_failure durch SSLHandshakeException

Ich habe ein problem mit autorisierten SSL-Verbindung. Erstellt habe ich die Struts-Aktion, die die Verbindung mit einem externen server-mit-Client-Autorisierten SSL-Zertifikat. In meinem Handeln bin ich zu senden versuchen, einige Daten zu bank-server aber ohne Glück, denn ich habe als Ergebnis vom server die folgende Fehlermeldung:

error: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Meine Methode aus meinem Action-Klasse sendet Daten an server

//Getting external IP from host
    URL whatismyip = new URL("http://automation.whatismyip.com/n09230945.asp");
    BufferedReader inIP = new BufferedReader(new InputStreamReader(whatismyip.openStream()));

    String IPStr = inIP.readLine(); //IP as a String

    Merchant merchant;

    System.out.println("amount: " + amount + ", currency: " + currency + ", clientIp: " + IPStr + ", description: " + description);

    try {

        merchant = new Merchant(context.getRealPath("/") + "merchant.properties");

    } catch (ConfigurationException e) {

        Logger.getLogger(HomeAction.class.getName()).log(Level.INFO, "message", e);
        System.err.println("error: " + e.getMessage());
        return ERROR;
    }

    String result = merchant.sendTransData(amount, currency, IPStr, description);

    System.out.println("result: " + result);

    return SUCCESS;

Meinem Händler.Eigenschaften Datei:

bank.server.url=https://-servernameandport-/
https.cipher=-cipher-

keystore.file=-key-.jks
keystore.type=JKS
keystore.password=-password-
ecomm.server.version=2.0

encoding.source=UTF-8
encoding.native=UTF-8

Für die erste Zeit dachte ich, das ist ein problem mit dem Zertifikat, ich baute es aus .pfx .jks, aber ich habe den selben Fehler, ohne änderungen.

InformationsquelleAutor der Frage Denees | 2011-06-15

188

Den handshake-Fehler entstanden sein könnte, aus verschiedenen Gründen:
- Unvereinbar cipher-suites in die Verwendung durch den client und den server. Dies würde erfordern, dass die Kunden zu bedienen (oder zu aktivieren) eine cipher-suite, die vom server unterstützt wird.
- Inkompatible Versionen von SSL im Einsatz (könnte der server akzeptieren nur TLS v1, während der client ist in der Lage nur mittels SSL v3). Wieder, die Kunden haben könnten, um sicherzustellen, dass es verwendet eine kompatible version des SSL/TLS-Protokoll.
- Unvollständig Vertrauen Pfad für das server-Zertifikat; das Zertifikat des Servers ist wahrscheinlich nicht der der client vertraut. Dies würde in der Regel das Ergebnis in einer ausführlicheren Fehler, aber es ist durchaus möglich. In der Regel fix ist, importieren Sie das server-CA-Zertifikat in das Vertrauen der Kunden zu speichern.
- Das Zertifikat ist ausgestellt für eine andere domain. Wieder, dies hätte zu einer ausführlicheren Nachricht, aber ich werde Zustand, die fix hier im Fall ist dies die Ursache. Die Auflösung wäre in diesem Fall die server (es scheint nicht zu verkaufen) , verwenden Sie das richtige Zertifikat.
Da die zugrunde liegenden Fehler nicht lokalisiert, ist es besser, schalten Sie die -Djavax.net.debug=all - flag, um das debugging zu aktivieren der SSL-Verbindung hergestellt. Mit der debug eingeschaltet ist, können Sie erkennen, welche Aktivitäten in der handshake ist fehlgeschlagen.

Update

Basierend auf den details, die jetzt verfügbar sind, scheint es, dass das problem durch ein unvollständiges Vertrauen Pfad zwischen den ausgestellten Zertifikat an den server, und root-CA. In den meisten Fällen ist dies, weil das root CA Zertifikat nicht vorhanden ist, die in der trust store -, führt zu der situation, wo ein Zertifikat Vertrauen Pfad nicht existieren kann; das Zertifikat ist im wesentlichen von den nicht vertrauenswürdigen client. Browser eine Warnung, so dass Benutzer können dies ignorieren, aber das ist nicht der Fall für SSL-clients (wie die HttpsURLConnection Klasse, oder ein HTTP-Client-Bibliothek wie Apache HttpComponents-Client).

Meisten dieser client-Klassen/Bibliotheken, die sich darauf verlassen, dass der trust store verwendet, die von der JVM für die Zertifikatsprüfung. In den meisten Fällen wird dies die cacerts Datei in die JRE_HOME/lib/security Verzeichnis. Wenn die Lage der trust store angegeben wurde, mit dem JVM-Systemeigenschaft javax.net.ssl.trustStoredann ist das speichern in diesem Pfad ist in der Regel die von der client-Bibliothek. Wenn Sie im Zweifel sind, werfen Sie einen Blick auf Ihre Merchant Klasse, und die Abbildung aus der Klasse/Bibliothek wird es verwenden, um die Verbindung zu machen.

Hinzufügen des server-Zertifikats der ausstellenden CA zu dieser trust store sollte das problem beheben. Sie können sich auf meine Antwort auf einer ähnlichen Frage auf erste tools für diesen Zweck, aber die Das Java-keytool-Dienstprogramm ist ausreichend für diesen Zweck.

Warnung: Die trust store-ist im wesentlichen eine Liste aller Zertifizierungsstellen, denen Sie Vertrauen. Wenn Sie in ein Zertifikat, das gehört nicht zu einer CA, die Sie nicht Vertrauen, dann SSL/TLS-verbindungen zu Websites, die Zertifikate, ausgestellt von einer Person entschlüsselt werden können, wenn der private Schlüssel verfügbar ist.

Update #2: das Verständnis der Leistung von der JSSE trace

Den keystore und den truststores verwendet, die von der JVM sind in der Regel am Anfang, etwas wie die folgenden:
```
keyStore is : 
keyStore type is : jks
keyStore provider is : 
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.6.0_21\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is : 
```
Wenn die falschen truststore verwendet wird, dann werden Sie brauchen, um re-importieren Sie das Serverzertifikat auf der rechten Seite ein, oder konfigurieren Sie den server für die Verwendung der aufgeführten (nicht empfohlen, wenn Sie mehrere JVMs, und alle von Ihnen sind für unterschiedliche Bedürfnisse verwendet).

Wenn Sie möchten, um zu überprüfen, ob die Liste von trust certs enthält die erforderlichen APZ, dann gibt es einen Abschnitt für die gleiche, die beginnt so:
```
adding as trusted cert:
  Subject: CN=blah, O=blah, C=blah
  Issuer:  CN=biggerblah, O=biggerblah, C=biggerblah
  Algorithm: RSA; Serial number: yadda
  Valid from SomeDate until SomeDate
```
Müssen Sie Aussehen, wenn die server-CA ist ein Thema.

Den handshake-Prozess wird ein paar auffällige Einträge (Sie müssen wissen, über SSL zu verstehen Sie im detail, aber für die Zwecke der Fehlerbeseitigung das aktuelle problem, es wird genügen, zu wissen, dass ein handshake_failure ist in der Regel berichtet in der ServerHello.

1. ClientHello

Einer Reihe von Einträgen berichtet werden wird, wenn die Verbindung wird initialisiert. Die erste Nachricht, die vom client gesendet wird, in eine SSL/TLS-Verbindungsaufbau ist die ClientHello-Nachricht, in der Regel berichtet in den Protokollen als:
```
*** ClientHello, TLSv1
RandomCookie:  GMT: 1291302508 bytes = { some byte array }
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods:  { 0 }
***
```
Hinweis: cipher suites verwendet. Diese haben könnte, um Stimmen zu mit dem Eintrag in Ihrem Google merchant.properties-Datei, die für die gleiche Konvention möglicherweise eingesetzt werden, durch die bank, Bibliothek. Wenn die Konvention verwendet wird, unterschiedlich sind, gibt es keinen Grund der Sorge, für die ServerHello Staat wird also, wenn der cipher suite nicht kompatibel ist.

2. ServerHello

Antwortet der server mit einem ServerHello, die angibt, ob die Verbindung das Setupprogramm fortgesetzt werden kann. Einträge in den logs sind in der Regel der folgenden Art:
```
*** ServerHello, TLSv1
RandomCookie:  GMT: 1291302499 bytes = { some byte array}
Cipher Suite: SSL_RSA_WITH_RC4_128_SHA
Compression Method: 0
***
```
Beachten Sie die cipher suite, die es gewählt hat; ist dies beste suite zur Verfügung, um sowohl den server und den client. In der Regel wird die cipher-suite ist nicht angegeben, ob es ein Fehler ist. Das Zertifikat des Servers (und Optional der gesamten Kette), die vom server gesendet, und würde gefunden werden, in der Einträge wie:
```
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=server, O=server's org, L=server's location, ST =Server's state, C=Server's country
  Signature Algorithm: SHA1withRSA, OID = some identifer

.... the rest of the certificate
***
```
Wenn die Prüfung des Zertifikats erfolgreich war, finden Sie einen Eintrag ähnlich:
```
Found trusted certificate:
[
[
  Version: V1
  Subject: OU=Server's CA, O="Server's CA's company name", C=CA's country
  Signature Algorithm: SHA1withRSA, OID = some identifier
```
Einer der oben genannten Schritte nicht zum Erfolg geführt hätten, was in der handshake_failure, der händedruck ist in der Regel abgeschlossen zu diesem Zeitpunkt (eigentlich nicht, aber die nachfolgenden Phasen der Handschlag in der Regel nicht bewirken, dass ein handshake-Fehler). Sie müssen herausfinden, welche Schritt fehlgeschlagen, und posten Sie die entsprechende Nachricht als update an die Frage (es sei denn du hast bereits verstanden die Botschaft, und Sie wissen, was zu tun ist, um es zu beheben).

InformationsquelleAutor der Antwort Vineet Reynolds

Ich glaube nicht, dass dies das problem löst der erste Fragesteller, sondern auch für Google-Mitarbeiter, die kommen hier für Antworten:

On update 51 java 1.8 verboten[1] RC4-Verschlüsselungen standardmäßig, wie wir sehen auf der Release Notes Seite:

Bug-Fix: Verbieten RC4 cipher suites

RC4 ist mittlerweile als gefährdet Chiffre.

RC4 cipher suites entfernt wurden sowohl client als auch server standardmäßig aktivierten cipher-suite-Liste in Oracle JSSE-Implementierung. Diese cipher-suites können noch aktiviert werden, indem SSLEngine.setEnabledCipherSuites() und SSLSocket.setEnabledCipherSuites() Methoden. Siehe JDK-8077109 (nicht öffentlich).

Wenn Ihr server hat eine starke Präferenz für dieses Verfahren (und die Nutzung dieser Chiffre) kann dies trigger a handshake_failure auf java.

Test können Sie die Verbindung zum server aktivieren RC4-Verschlüsselungen (versuchen Sie zunächst, ohne enabled argument, um zu sehen, wenn die Trigger eine handshake_failure einstellen und dann enabled:

import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import java.io.*;

import java.util.Arrays;

/** Establish a SSL connection to a host and port, writes a byte and
 * prints the response. See
 * http://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services
 */
public class SSLRC4Poke {
    public static void main(String[] args) {
        String[] cyphers;
        if (args.length < 2) {
            System.out.println("Usage: "+SSLRC4Poke.class.getName()+" <host> <port> enable");
            System.exit(1);
        }
        try {
            SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
            SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket(args[0], Integer.parseInt(args[1]));

            cyphers = sslsocketfactory.getSupportedCipherSuites();
            if (args.length ==3){
                sslsocket.setEnabledCipherSuites(new String[]{
                    "SSL_DH_anon_EXPORT_WITH_RC4_40_MD5",
                    "SSL_DH_anon_WITH_RC4_128_MD5",
                    "SSL_RSA_EXPORT_WITH_RC4_40_MD5",
                    "SSL_RSA_WITH_RC4_128_MD5",
                    "SSL_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
                    "TLS_ECDHE_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_ECDSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_anon_WITH_RC4_128_SHA",
                    "TLS_KRB5_EXPORT_WITH_RC4_40_MD5",
                    "TLS_KRB5_EXPORT_WITH_RC4_40_SHA",
                    "TLS_KRB5_WITH_RC4_128_MD5",
                    "TLS_KRB5_WITH_RC4_128_SHA"
                });     
            }

            InputStream in = sslsocket.getInputStream();
            OutputStream out = sslsocket.getOutputStream();

            //Write a test byte to get a reaction :)
            out.write(1);

            while (in.available() > 0) {
                System.out.print(in.read());
            }
            System.out.println("Successfully connected");

        } catch (Exception exception) {
            exception.printStackTrace();
        }
    }
}

1 - https://www.java.com/en/download/faq/release_changes.xml

InformationsquelleAutor der Antwort motobói

17

Installieren der Java Cryptography Extension (JCE) Unlimited Strength (für JDK7 | für JDK8) diesen Fehler beheben wird. Entpacken Sie die Datei, und befolgen Sie die readme-Datei um es zu installieren.

InformationsquelleAutor der Antwort Simon Yu
14

Dies kann auch geschehen, wenn der client muss ein Zertifikat. Nach der server-Listen die Zertifikat-Kette, kann Folgendes passieren:

3. Zertifikat-Anfrage
Der server wird ein Zertifikat ausstellen Anfrage vom client. Die Anfrage mit einer Liste aller Zertifikate, die der server akzeptiert.
```
*** CertificateRequest
Cert Types: RSA
Cert Authorities:
<CN=blah, OU=blah, O=blah, L=blah, ST=blah, C=blah>
<CN=yadda, DC=yadda, DC=yadda>
<CN=moreblah, OU=moreblah, O=moreblah, C=moreblah>
<CN=moreyada, OU=moreyada, O=moreyada, C=moreyada>
... the rest of the request
*** ServerHelloDone
```
4. Client-Zertifikat-Kette
Dies ist das Zertifikat, das der client an den server senden.
```
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: EMAILADDRESS=client's email, CN=client, OU=client's ou, O=client's Org, L=client's location, ST=client's state, C=client's Country
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
  ... the rest of the certificate
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1    
... key exchange info 
```
Wenn es nicht ein Zertifikat in der Kette, und der server erfordert, erhalten Sie die handshake-Fehler hier. Eine wahrscheinliche Ursache ist der Pfad zu Ihrem Zertifikat wurde nicht gefunden.

5. Zertifikat Überprüfen,
Der client fragt den server, um das Zertifikat zu überprüfen
```
*** CertificateVerify
... payload of verify check
```
Dieser Schritt wird nur geschehen, wenn Sie senden ein Zertifikat.

6. Fertig
Der server antwortet mit einer überprüfe die Antwort
```
*** Finished
verify_data:  { 345, ... }
```
InformationsquelleAutor der Antwort Brig
7

Den handshake-Fehler könnte einen buggy TLSv1-Protokoll-Implementierung.

In unserem Fall half mit java 7:
```
java -Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1 
```
Jvm aushandeln, in dieser Reihenfolge. Die Server mit dem neuesten update zu tun, 1.2, der buggy wird nach unten gehen, um v1 und das funktioniert mit dem ähnlichen v1 in java 7.

InformationsquelleAutor der Antwort Bela Vizy
6

Habe ich diesen Fehler, während ich versuchte mit JDK 1.7.
Wenn ich aktualisiert mein JDK zu jdk1.8.0_66 begann alles zu funktionieren.

Also die einfachste Lösung für dieses problem könnte sein, - aktualisieren Sie Ihre JDK und es konnte anfangen zu arbeiten.

InformationsquelleAutor der Antwort Maxim Votyakov
3

Vorausgesetzt Sie verwenden die richtige SSL - /TLS-Protokolle, richtig konfiguriert keyStore und trustStoreund bestätigt, dass es nicht vorhanden ist keine Probleme mit den Zertifikaten selbst, Sie müssen möglicherweise stärken Sie Ihre Sicherheits-algorithmen.

Wie bereits in Vineet Antwortein möglicher Grund, warum Sie diese Fehlermeldung erhalten, ist aufgrund inkompatibler cipher suites verwendet wird. Durch die Aktualisierung meiner local_policy und US_export_policy Gläser in mein JDK ist security Ordner mit den in der Java Cryptography Extension (JCE)ich war in der Lage, um das handshake erfolgreich.

InformationsquelleAutor der Antwort heez
1

Mir war ein TLS version nicht kompatibel Fehler.

Früher war es TLSv1 ich habe es TLSV1.2 dies mein problem gelöst.

InformationsquelleAutor der Antwort Ali786
1

Ich hatte ein ähnliches Problem; ein Upgrade auf Apache-HTTPClient 4.5.3 behoben.

InformationsquelleAutor der Antwort Hazel Troost

Ich das gleiche problem heute mit OkHttp-client, um eine https-basierte url sein. Es war verursacht durch Https-Protokoll-version und Cipher-Methode Missverhältnis zwischen der server-Seite und client-Seite.

1) überprüfen Sie Ihre website https-Protokoll version und Cipher-Methode.

openssl>s_client -connect your_website.com:443 -showcerts

Erhalten Sie viele detail-info, die key-info ist wie folgt aufgelistet:

SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA

2) config-http-client, zum Beispiel, in Client OkHttp Fall:

@Test()
public void testHttpsByOkHttp() {
    ConnectionSpec spec = new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
            .tlsVersions(TlsVersion.TLS_1_0) //protocol version
            .cipherSuites(
                    CipherSuite.TLS_RSA_WITH_RC4_128_SHA, //cipher method
                    CipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
                    CipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
                    CipherSuite.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256)
            .build();

    OkHttpClient client = new OkHttpClient();
    client.setConnectionSpecs(Collections.singletonList(spec));
    Request request = new Request.Builder().url("https://your_website.com/").build();
    try {
        Response response = client.newCall(request).execute();
        if(response.isSuccessful()){
            logger.debug("result= {}", response.body().string());
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}

Diese werden bekommen, was wir wollen.

InformationsquelleAutor der Antwort Armstrongya

1

Fand ich einen HTTPS-server, die nicht in dieser Weise, wenn meine Java-client-Verfahren konfiguriert wurde, mit
```
-Djsse.enableSNIExtension=false
```
Die Verbindung ist fehlgeschlagen mit handshake_failure nach der ServerHello hatte, erfolgreich abgeschlossen, aber bevor der Datenstrom gestartet.

Gab es keine klare Fehlermeldung, die das problem erkannt, der Fehler sah aus wie
```
main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, handshake_failure
%% Invalidated:  [Session-3, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
```
Ich isoliert das Problem, indem Sie versuchen mit und ohne den " -Djsse.enableSNIExtension=false " - option

InformationsquelleAutor der Antwort Rich
0

Disclaimer : ich bin nicht bewusst, wenn die Antwort hilfreich sein wird für viele Menschen,gerade teilen, weil es könnte .

War ich immer diesen Fehler bei der Verwendung von Parasoft SOATest auf Anfrage senden XML(SOAP) .

Das Problem war, dass ich hatte die falsche alias aus der dropdown-nach hinzufügen des Zertifikats und authentifizieren.

InformationsquelleAutor der Antwort user3251882

Ich bin mit com.google.api-http-client. Wenn ich kommunizieren mit einem internen Unternehmens-Website, ich habe das problem, wenn ich irrtümlich verwendet https, statt http.

main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, IOException in getSession():  javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, called close()
main, called closeInternal(true)
262 [main] DEBUG org.apache.http.impl.conn.DefaultClientConnection  - Connection shut down
main, called close()
main, called closeInternal(true)
263 [main] DEBUG org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager  - Released connection is not reusable.
263 [main] DEBUG org.apache.http.impl.conn.tsccm.ConnPoolByRoute  - Releasing connection [HttpRoute[{s}->https://<I-replaced>]][null]
263 [main] DEBUG org.apache.http.impl.conn.tsccm.ConnPoolByRoute  - Notifying no-one, there are no waiting threads
Exception in thread "main" javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
    at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
    at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
    at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
    at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:108)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
    at com.google.api.client.http.apache.ApacheHttpRequest.execute(ApacheHttpRequest.java:67)
    at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:960)

InformationsquelleAutor der Antwort thebiggestlebowski

0

In meinem Fall, cert importiert, der Fehler bleibt, löste dies durch hinzufügen System.setProperty("https.protocols", "TLSv1.2,TLSv1.1,SSLv3"); vor dem schließen

InformationsquelleAutor der Antwort molly gu

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.