Frage

Wir sind nicht in der Lage zu einem HTTPS-Server mit WebRequest zu verbinden, weil diese Fehlermeldung:

The request was aborted: Could not create SSL/TLS secure channel.

Wir wissen, dass der Server keine gültige HTTPS-Zertifikat hat mit dem Pfad verwendet, aber zu umgehen dieses Problem, verwenden wir den folgenden Code ein, dass wir von einem anderen Stackoverflow Post genommen haben:

private void Somewhere() {
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
   return true;
}

Das Problem ist, dass Server nie das Zertifikat validiert und schlägt mit den oben genannten Fehlern. Hat jemand eine Ahnung davon hat, was soll ich tun?


soll ich erwähnen, dass ein Kollege und ich Tests durchgeführt, vor ein paar Wochen und es funktioniert gut mit etwas ähnlich zu dem, was ich oben geschrieben hätte. Der einzige „große Unterschied“ wir gefunden haben, ist, dass ich mit Windows 7 und er wurde mit Windows XP. Wird diese Änderung etwas?

War es hilfreich?

Lösung

Ich fand schließlich die Antwort (ich habe meine Quelle nicht bemerkt, aber es war von einer Suche);

Während der Code in Windows XP arbeitet, in Windows 7, müssen Sie diese hinzufügen am Anfang:

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

Und jetzt, es funktioniert perfekt.


NACHTRAG

erwähnt Wie Robin Französisch; wenn Sie dieses Problem bekommen, während PayPal Konfiguration Bitte beachten Sie, dass sie nicht unterstützen SSL3 beginnend mit 3. Dezember 2018. Sie werden TLS verwenden müssen. Hier Paypal über sie.

Andere Tipps

Die Lösung dieses Problems in .NET 4.5 ist

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Wenn Sie .NET 4.5 verwenden Sie dann nicht über

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Stellen Sie sicher, dass die Servicepoint Einstellungen vorgenommen werden, bevor der HttpWebRequest erstellt wird, sonst wird es nicht funktionieren.

Arbeiten:

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

schlägt fehl:

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

Ich hatte dieses Problem zu schlagen versuchen, https://ct.mob0.com/Styles/Fun.png, die ein Bild von CloudFlare auf seine CDN, dass Stützen verrückte Sachen wie SPDY und seltsame Umleitung SSL-Zertifikate.

verteilt ist

Statt Angabe SSL3 wie in Simons beantworten konnte ich es beheben, indem Sie auf Tls12 wie diese going down:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

Nach vielen langen Stunden mit dem gleichen Problem fand ich, dass die ASP.NET des Client-Dienstkonto unter lief keinen Zugriff auf das Zertifikat hat. Ich es fest, indem sie in den IIS-Applikations-Pool gehen, dass die Web-App läuft unter, geht in Erweiterte Einstellungen und die Identität mit dem LocalSystem Konto von NetworkService ändern.

Eine bessere Lösung ist das Zertifikat zu erhalten, die Arbeit mit dem Standard NetworkService Konto, aber das funktioniert für die schnelle Funktionsprüfung.

Etwas die ursprüngliche Antwort nicht haben. Ich habe etwas mehr Code zu machen bullet proof.

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Ein andere Möglichkeit ist unangebrachte Zertifikat Einfuhr auf dem Feld. Stellen Sie sicher, umkreist das Kontrollkästchen. Am Anfang habe ich es nicht, so Code entweder eine Zeitüberschreitung oder werfen gleiche Ausnahme wie private Schlüssel können nicht gefunden werden sollte.

Zertifikat Einfuhr Dialog

Die "Die Anforderung wurde abgebrochen: kann nicht erstellt sicheren SSL / TLS-Kanal" Ausnahme kann auftreten, wenn der Server eine kehrt HTTP 401 Unauthorized Antwort auf die HTTP-Anforderung

.

Sie können bestimmen, ob dies durch Drehen auf Spurenebene System.Net Protokollierung für Ihre Client-Anwendung geschieht, beschrieben wie in diese Antwort .

Sobald das Protokollkonfiguration vorhanden ist, die Anwendung ausführen und den Fehler reproduzieren, dann schauen Sie in der Logging-Ausgabe für eine Zeile wie diese:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

In meiner Situation, ich versagen ein bestimmtes Cookie zu setzen, dass der Server erwartet, an den Server führte auf die Anforderung reagiert mit den 401-Fehlern, was wiederum führte zum „kann nicht erstellt sicheren SSL / TLS-Kanal“ Ausnahme.

Die Wurzel dieser Ausnahme in meinem Fall war irgendwann in Code, dass die folgenden genannt wurde:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Das ist wirklich schlecht. Nicht nur ist es anweist, .NET, um ein unsicheres Protokoll zu verwenden, aber diese Auswirkungen jedes neues WebClient (und ähnliche) Antrag später in Ihrem Appdomain. (Beachten Sie, dass eingehende Webanfragen nicht betroffen sind in Ihrer ASP.NET-Anwendung, aber neue WebClient-Anforderungen, wie zum Gespräch mit einem externen Web-Service sind).

In meinem Fall war es eigentlich nicht benötigt, so konnte ich nur die Aussage löschen und alle meine andere Web-Anfragen gestartet wieder gut arbeiten. Auf der Grundlage meiner woanders zu lesen, habe ich gelernt, ein paar Dinge:

  • Dies ist eine globale Einstellung in Ihrer Appdomain, und wenn man die gleichzeitige Aktivität haben, können Sie nicht sicher stellen Sie es auf einen Wert, tun Sie Ihre Aktion, und dann wieder eingestellt. Eine weitere Maßnahme kann in diesem kleinen Fenster statt und beeinflusst werden.
  • Die richtige Einstellung ist es standardmäßig zu verlassen. Dies ermöglicht .NET zu verwenden, um fortzufahren, was auch immer der sicherste Standardwert ist wie die Zeit vergeht und Sie Frameworks aktualisieren. Setzen auf TLS12 (die zum Zeitpunkt des Schreibens der sicherste ist) funktioniert Jetzt , aber in 5 Jahren beginnen kann mysteriöse Probleme zu verursachen.
  • Wenn Sie wirklich Wert müssen festlegen, sollten Sie tun es in einer separaten Fachanwendung betrachten oder Appdomain und einen Weg zu Gespräch zwischen ihm und Ihrem Hauptpool finden. Weil es ein einzelner globaler Wert ist, versucht es Pool innerhalb eines belebten App verwalten wird nur zu Problemen führen. Diese Antwort: https://stackoverflow.com/a/26754917/7656 bietet eine mögliche Lösung über einen benutzerdefinierten Proxyserver . (Anmerkung Ich habe nicht persönlich es implementiert.)

Dieses arbeitet für mich in MVC webclient

    public string DownloadSite(string RefinedLink)
    {
        try
        {
            Uri address = new Uri(RefinedLink);

            ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

            System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

            using (WebClient webClient = new WebClient())
            {
                var stream = webClient.OpenRead(address);
                using (StreamReader sr = new StreamReader(stream))
                {
                    var page = sr.ReadToEnd();

                    return page;
                }
            }

        }
        catch (Exception e)
        {
            log.Error("DownloadSite - error Lin = " + RefinedLink, e);
            return null;
        }
    }

Wie Sie sagen, es gibt viele Gründe, dies passieren könnte. Dachte, ich würde die Sache die ich gestoßen ...

hinzufügen

Wenn Sie den Wert von WebRequest.Timeout auf 0 gesetzt, das ist die Ausnahme, die ausgelöst wird. Im Folgenden wird der Code hatte ich ... (anstelle eines hartcodierte 0 für den Timeout-Wert Außer, ich hatte einen Parameter, der 0 versehentlich gesetzt wurde).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

Eine weitere mögliche Ursache des The request was aborted: Could not create SSL/TLS secure channel Fehlers ist eine Diskrepanz zwischen dem Client-PC konfigurierte cipher_suites Wert und die Werte, dass der Server als willens und in der Lage, so konfiguriert ist, zu akzeptieren. In diesem Fall, wenn der Client die Liste der cipher_suites Werte sendet, dass es in der Lage ist, in seiner ursprünglichen SSL-Handshake / Verhandlung „Client Hallo“ -Nachricht zu akzeptieren, sieht der Server, dass keiner der angegebenen Werte sind akzeptabel und darf zurückkehren ein „Alert "Reaktion statt auf das Vorgehen‚Server Hallo‘Schritt des SSL-Handshake.

Um diese Möglichkeit zu untersuchen, können Sie Microsoft Message Analyzer herunterladen , und es verwendet, eine Spur auf der SSL-Verhandlung auszuführen, wenn Sie (in C # app) eine HTTPS-Verbindung zu dem Server herzustellen versuchen und scheitern auftritt.

Wenn Sie sind in der Lage eine erfolgreiche HTTPS-Verbindung aus einer anderen Umgebung (zB die Windows XP-Maschine zu machen, dass Sie erwähnt - oder möglicherweise durch die Kollision mit HTTPS-URL in einem Nicht-Microsoft-Browser, der nicht das Cipher-Suite-Einstellungen des OS nicht verwendet wie Chrome oder Firefox), eine andere Message Analyzer Spur in dieser Umgebung Capture laufen, was passiert, wenn die SSL-Verhandlung erfolgreich ist.

Hoffentlich werden Sie einige Unterschiede zwischen den beiden Client-Hallo-Nachrichten sehen, die Sie identifizieren können, um genau das, was über die fehlerhafte SSL-Verhandlung verursacht es zum Scheitern verurteilt. Dann sollten Sie in der Lage sein, um Konfigurationsänderungen an Windows vornehmen, die es erlauben werden, erfolgreich zu sein. IISCrypto ist ein großes Werkzeug für diesen (auch für Client-PC zu verwenden, trotz des „IIS“ namen ).

Die folgenden zwei Windows-Registry-Schlüssel regeln den cipher_suites Wert, dass Ihr PC verwenden:

  • HKLM \ SOFTWARE \ Policies \ Microsoft \ Cryptography \ Configuration \ SSL \ 00010002
  • HKLM \ SYSTEM \ CurrentControlSet \ Control \ Cryptography \ Configuration \ Local \ SSL \ 00010002

Hier ist ein voll writeup, wie ich untersucht und gelöst eine Instanz dieser Varietät des Could not create SSL/TLS secure channel Problem: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

Ich habe mit diesem Problem der ganzen Tag zu kämpfen.

Wenn ich ein neues Projekt mit .NET 4.5 erstellt Ich habe es endlich an der Arbeit.

Wenn ich aber auf 4,0 herabgestuft habe ich das gleiche Problem wieder, und es war irreversable für dieses Projekt (auch wenn ich auf 4,5 wieder ein Upgrade versucht).

Seltsam keine andere Fehlermeldung, aber „Die Anforderung wurde abgebrochen. Könnten SSL nicht erstellen / TLS sicheren Kanal“ kam für diesen Fehler auf

Im Fall, dass der Client ist eine Windows-Maschine, ein möglicher Grund könnte sein, dass das TLS- oder SSL-Protokoll durch den Dienst nicht erforderlich aktiviert ist.

Dies kann eingestellt werden:

  

Systemsteuerung -> Netzwerk und Internet -> Internetoptionen -> Erweitert

Scroll-Einstellungen nach unten zu "Sicherheit" und wählen Sie zwischen

  • SSL 2.0 verwenden
  • SSL 3.0 verwenden
  • TLS 1.0 verwenden
  • Verwenden Sie TLS 1.1
  • Verwenden Sie TLS 1.2

 image description hier

eingeben

Ich hatte dieses Problem, weil mein web.config hatte:

<httpRuntime targetFramework="4.5.2" />

und nicht

<httpRuntime targetFramework="4.6.1" />

In meinem Fall das Dienstkonto der Ausführung der Anwendung hatte keine Erlaubnis, den privaten Schlüssel zuzugreifen. Sobald ich diese Erlaubnis gab, wird der Fehler ging weg

  1. mmc
  2. Zertifikate
  3. erweitern auf persönliche
  4. wählen cert
  5. Rechtsklick
  6. Alle Aufgaben
  7. Verwalten private Schlüssel
  8. Add

Wenn Sie Ihren Code von Visual Studio ausführen, versuchen Sie Visual Studio als Administrator ausgeführt wird. Der Fehler für mich.

Ich hatte das gleiche Problem und fand diese Antwort richtig für mich gearbeitet. Der Schlüssel ist 3072. Dieser Link die Details auf der '3072' fix bietet.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

In meinem Fall zwei Einspeisungen erforderlich das Update:

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss
  

System.Net.WebException: Die Anforderung wurde abgebrochen: kann nicht erstellt werden   SSL / TLS sichere Kanal.

In unserem Fall haben wir, wo ein Software-Anbieter mit, so dass wir keinen Zugang haben die .NET-Code zu ändern. Anscheinend verwenden TLS v .NET 4 nicht 1.2, es sei denn es eine Änderung gibt.

Die Fehlerbehebung für uns die SchUseStrongCrypto Schlüssel zur Registrierung wurde hinzugefügt. Sie können die folgenden Code in eine Textdatei mit der Erweiterung von REGEN kopieren / einfügen und ausführen. Es diente als unser "Patch" für das Problem.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Versuchen Sie diese:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Die Top-gestimmt Antwort wird wahrscheinlich für die meisten Menschen genug sein. Doch in einigen Fällen könnten Sie auch weiterhin einen „kann nicht sicheren SSL / TLS-Kanal erstellen“ Fehler immer auch nach 1.2 TLS erzwingen. Wenn ja, können Sie dies hilfreich beraten wollen Artikel für weitere Schritte zur Fehlerbehebung. Fassen wir zusammen: unabhängig von der TLS / SSL-Version Problem, muss der Client und Server auf einem zustimmen „Cipher-Suite.“ Während der „Handshake“ Phase der SSL-Verbindung, wird die Client-Liste der unterstützten Cipher-Suite für den Server gegen seine eigene Liste zu überprüfen. Aber auf einigen Windows-Rechnern, bestimmte gemeinsame Chiffre-Suiten haben deaktiviert worden (scheinbar aufgrund gut gemeinten Versuche zur Begrenzung Angriffsfläche), die Verringerung der Möglichkeit des Client & Server auf einem Cipher Suite zu vereinbaren. Wenn sie sich nicht einigen können, dann können Sie „fatal Alarmcode 40“ in der Ereignisanzeige sehen und „Kann nicht SSL erstellen / TLS sicheren Kanal“ in Ihrem .NET-Programm.

Der zuvor erwähnte Artikel beschreibt, wie die alle einer Maschine möglicherweise gestützten Chiffriersätze zur Liste und zusätzliche Chiffriersätze durch die Windows-Registrierung aktivieren. Um Hilfe Prüfung, den Chiffriersätze auf dem Client aktiviert werden, versuchen diese Diagnoseseite in MSIE Besuch . (System.Net Verfolgung verwendet, kann geben endgültigere Ergebnisse.) Um herauszufinden, welche Chiffriersätze vom Server unterstützt werden, versuchen diese Online-Tool (unter der Annahme, dass der Server Internet barrierefrei). Es gehen sollte sich, dass Registry Änderungen müssen mit Vorsicht durchgeführt werden, insbesondere dort, wo Vernetzung beteiligt ist. (Ist das Gerät eine Remote gehostete VM? Wenn Sie waren Vernetzung zu brechen, würde die VM überhaupt zugänglich sein?)

In meiner Firma Fall aktivierten wir mehr zusätzliches „ECDHE_ECDSA“ Suiten über Registry bearbeiten, ein unmittelbares Problem und Schutz gegen zukünftige Probleme zu beheben. Aber wenn Sie nicht (oder nicht) die Registrierung bearbeiten, dann zahlreiche Abhilfen (nicht unbedingt hübsch) in den Sinn kommen. Zum Beispiel:. .NET-Programm könnte seine SSL-Datenverkehr auf einem separaten Python-Programm übertragen (das kann sich aus dem gleichen Grund arbeiten, dass Chrome-Anfragen gelingen kann, wenn MSIE-Anfragen auf dem betroffenen Rechner gescheitert)

Das Problem für mich war, dass ich auf IIS als Web Service bereitstellen versuche ich das Zertifikat auf dem Server installiert, aber den Benutzer, auf dem IIS ausgeführt wird nicht die richtigen Berechtigungen für das Zertifikat hat.

Wie ASP.NET Zugriff auf einen privaten Schlüssel in einem Zertifikat im Zertifikatsspeicher?

In meinem Fall hatte ich dieses Problem, wenn ein Windows-Dienst verbunden versucht, einen Web-Service. Suchen Sie in Windows-Ereignisse schließlich fand ich einen Fehlercode an.

  

Ereignis-ID 36888 (Schannel) angehoben wird:

The following fatal alert was generated: 40. The internal error state is 808.

Schließlich wurde es mit einem Windows-Hotfix verwendet. In meinem Fall: KB3172605 und KB3177186

Die vorgeschlagene Lösung in vmware Forum war ein Registrierungseintrag in Windows hinzuzufügen. Nach dem Hinzufügen der folgenden Registrierungs alles funktioniert gut.

  

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Securityproviders \ SCHANNEL \ KeyExchangeAlgorithms \ Diffie-Hellman]

"ClientMinKeyBitLength" = dword: 00000200

es offenbar mit einem fehlenden Wert in dem https-Handshake in der Client-Seite zusammen.

Ihre Windows-HotFix:

wmic qfe list

Lösung Thema:

https://communities.vmware.com/message/2604912#2604912

Hope es hilft.

Keiner der für mich gearbeitet Antworten.

Das ist, was funktioniert hat:

Statt meine X509Certifiacte2 wie folgt initialisiert:

   var certificate = new X509Certificate2(bytes, pass);

Ich habe es wie folgt aus:

   var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

Beachten Sie die X509KeyStorageFlags.Exportable !!

Ich habe nicht den Rest des Codes ändern (die WebRequest selbst):

// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true; 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
    // etc...
}

In der Tat Ich bin nicht einmal sicher, dass die ersten beiden Zeilen notwendig sind ...

Diese Frage kann viele Antworten haben, da es über eine generische Fehlermeldung. Wir liefen in dieser Frage auf einige unserer Server, aber unsere Entwicklung Maschinen nicht. Nach dem Ziehen der meisten unserer Haare aus, wir fanden es ein Microsoft Fehler war.

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

Im Wesentlichen MS vorausgesetzt, dass Sie schwächere Verschlüsselung wollen, aber das Betriebssystem gepatcht erlaubt nur 1,2 TLS, so dass Sie die gefürchtete empfangen „die Anforderung abgebrochen wurde. Kann nicht SSL erstellen / TLS sicheren Kanal“

Es gibt drei Korrekturen.

1) Patch das Betriebssystem mit der richtigen Update: http: / /www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) eine Einstellung Ihrer app.config / web.config-Datei hinzufügen.

3) Fügen Sie eine Registrierungseinstellung, die bereits in einer anderen Antwort erwähnt wurde.

Alle diese sind in der Knowledge Base-Artikel erwähnte ich geschrieben.

Sie können versuchen, ein Demo-Zertifikat (einig ssl-Anbieter sie Angebote für einen Monat kostenlos) zu installieren, um sicher zu sein, ob das Problem auf cert Gültigkeit verwendet ist oder nicht.

Solange dies ist ein relativ „live“ link Ich dachte, ich würde eine neue Option hinzuzufügen. Diese Möglichkeit ist, dass der Dienst nicht mehr SSL unterstützt 3.0 aufgrund des Problems mit dem Pudel Angriff. Überprüfen Sie die Google-Anweisung auf diese aus. Ich habe dieses Problem mit mehrer Web-Service auf einmal und realisiert hatte etwas los werden. Ich wechselte zu TLS 1.2 und alles funktioniert wieder.

http: //googleonlinesecurity.blogspot. com / 2014/10 / this-Pudel-Bisse ausbeute-ssl-30.html

Dies geschieht für mich nur auf einer Website, und es stellt sich heraus, dass es nur die RC4-Chiffre zur Verfügung hatte. In einem früheren Versuch, den Server zu härten, hatte ich den RC4-Chiffre deaktiviert, sobald ich diese wieder aktiviert das Problem gelöst wurde.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top