ALLOWCERTIFICATEERROR - Detailbeschreibung

Open

Überblick

Parameter:ALLOWCERTIFICATEERROR
Kategorie: Default (Allgemein)
Standardwert: 0 (deaktiviert)
Produkt: eTASK.Sonstige (Default)

Was macht dieser Parameter?

Dieser Parameter steuert, ob das eTASK.FM-Portal SSL-Zertifikatfehler bei HTTPS-Verbindungen ignoriert oder strikt prüft. Wenn aktiviert, werden Verbindungen zu Servern mit ungültigen, abgelaufenen oder selbstsignierten SSL-Zertifikaten trotzdem zugelassen.

Das System protokolliert erkannte Zertifikatfehler im Application-Log – bei aktiviertem Parameter als Information, bei deaktiviertem Parameter als Fehler.

Wofür wird dieser Parameter verwendet?

• Umgehung von SSL-Zertifikatproblemen in Entwicklungs- und Testumgebungen

• Ermöglichung von HTTPS-Verbindungen zu Servern mit selbstsignierten Zertifikaten

• Temporäre Lösung bei abgelaufenen Zertifikaten während der Erneuerungsphase

• Session-Transfer-Funktionalität (STUtils.cs) zwischen Portal-Instanzen

• Integration mit externen Systemen, die keine gültigen Zertifikate besitzen

• Vermeidung von Verbindungsabbrüchen bei Zertifikatfehlern

Technische Details (für Administratoren)

Format: Ganzzahl (0 oder 1)
Standardwert: 0 (deaktiviert)

Gültige Werte:
- 0 = SSL-Zertifikatfehler werden NICHT ignoriert (Standard, sicher)
- 1 = SSL-Zertifikatfehler werden ignoriert (unsicher, nur für spezielle Fälle)

Wichtige Hinweise:

• Der Parameter wird in der Session-Transfer-Komponente (STUtils.cs) verwendet

• Betrifft alle ausgehenden HTTPS-Verbindungen des Portals

• Folgende Zertifikatfehler werden bei Aktivierung ignoriert:

• RemoteCertificateChainErrors: Probleme in der Zertifikatskette

• RemoteCertificateNameMismatch: Hostname stimmt nicht mit Zertifikat überein

• RemoteCertificateNotAvailable: Kein Zertifikat verfügbar

• Zertifikatfehler werden immer protokolliert:

• Bei ALLOWCERTIFICATEERROR = 1: Als Information (LogInfo)

• Bei ALLOWCERTIFICATEERROR = 0: Als Fehler (LogError)

• Die Änderung greift sofort ohne Neustart

• Gilt systemweit für alle SSL-Verbindungen des Portals

Log-Level-Abhängigkeit:

• Um Zertifikatfehler im Log zu sehen, muss LOGLEVEL mindestens auf 1 (Warning) stehen

• Bei LOGLEVEL = 2 (Information) werden auch ignorierte Fehler protokolliert

Wann sollten Sie diesen Wert ändern?

Wert auf 1 setzen (Zertifikatfehler ignorieren), wenn:

• Entwicklungs- oder Testumgebung: Selbstsignierte Zertifikate werden verwendet

• Übergangsphase: SSL-Zertifikat ist abgelaufen und kann nicht sofort erneuert werden

• Interne Systeme: Integration mit internen Servern ohne offizielle Zertifikate

• Proof-of-Concept: Schnelles Testen ohne Zertifikat-Setup

• Legacy-Systeme: Alte externe Systeme ohne gültige Zertifikate müssen integriert werden

WICHTIG: Dies sollte NIEMALS in Produktivumgebungen dauerhaft aktiviert sein!

Wert auf 0 belassen (Standard, sicher), wenn:

• Produktivumgebung: Maximale Sicherheit ist erforderlich

• Gültige Zertifikate: Alle verbundenen Systeme haben valide SSL-Zertifikate

• Compliance: Sicherheitsrichtlinien verlangen strikte Zertifikatprüfung

• Best Practice: Standard-Sicherheitskonfiguration wird eingehalten

• Keine akuten Probleme: System funktioniert ordnungsgemäß

Wichtige Hinweise

1. Sicherheitsrisiko bei Aktivierung
   Das Ignorieren von SSL-Zertifikatfehlern öffnet die Tür für Man-in-the-Middle-Angriffe. Angreifer können sich zwischen Portal und Server schalten, ohne dass dies erkannt wird. Verwenden Sie diese Option nur in geschützten Netzwerken!

2. Nur temporär aktivieren
   Wenn Sie den Parameter auf 1 setzen müssen, dokumentieren Sie dies und planen Sie sofort die Behebung der eigentlichen Ursache (z.B. Zertifikatserneuerung). Setzen Sie einen Reminder, um den Parameter wieder auf 0 zurückzusetzen.

3. Log-Überwachung erforderlich
   Auch wenn Fehler ignoriert werden, werden sie protokolliert. Überprüfen Sie regelmäßig das Application-Log, um zu sehen, welche Zertifikatfehler auftreten und warum.

4. Betrifft alle HTTPS-Verbindungen
   Der Parameter wirkt global auf alle ausgehenden HTTPS-Verbindungen des Portals. Sie können nicht selektiv für einzelne Verbindungen entscheiden.

5. Keine Auswirkung auf eingehende Verbindungen
   Der Parameter betrifft nur ausgehende Verbindungen vom Portal zu anderen Systemen. Die SSL-Konfiguration für eingehende Verbindungen (Benutzer → Portal) wird durch den Webserver (IIS) gesteuert.

6. Zertifikat-Arten, die betroffen sind
   Abgelaufene Zertifikate, selbstsignierte Zertifikate, Zertifikate mit falschem Hostnamen, Zertifikate von nicht vertrauenswürdigen Zertifizierungsstellen und Zertifikate mit unterbrochener Vertrauenskette.

Sicherheit

Hat eine Änderung dieses Parameters Auswirkungen auf die Sicherheit?

Ja, dieser Parameter ist HOCH sicherheitsrelevant!

Sicherheitsrisiken bei Aktivierung (ALLOWCERTIFICATEERROR = 1):

• Man-in-the-Middle-Angriffe: Angreifer können sich zwischen Portal und Zielserver schalten und Datenverkehr abfangen oder manipulieren

• Datendiebstahl: Vertrauliche Informationen können von Dritten mitgelesen werden

• Identitätsfälschung: Das Portal kann nicht sicher überprüfen, ob es wirklich mit dem gewünschten Server kommuniziert

• Compliance-Verstöße: Viele Sicherheitsstandards (ISO 27001, PCI DSS, DSGVO) verlangen strikte SSL-Prüfung

• Vertrauensverlust: Bei Bekanntwerden können rechtliche und Reputationsschäden entstehen

Sicherheitsvorteile bei Deaktivierung (ALLOWCERTIFICATEERROR = 0):

• Verschlüsselungsintegrität: Garantiert, dass nur mit vertrauenswürdigen Servern kommuniziert wird

• Authentizität: Stellt sicher, dass der Kommunikationspartner tatsächlich der ist, für den er sich ausgibt

• Compliance: Erfüllt Anforderungen von Sicherheitsstandards und Datenschutzgesetzen

• Früherkennung: Zertifikatprobleme werden sofort erkannt und können behoben werden

Empfehlung führender Sicherheitsorganisationen:

OWASP (Open Web Application Security Project): - NIEMALS SSL-Zertifikatvalidierung in Produktion deaktivieren - Verwende nur Zertifikate von vertrauenswürdigen CAs - Implementiere Certificate Pinning für zusätzliche Sicherheit

BSI (Bundesamt für Sicherheit in der Informationstechnik): - SSL/TLS-Verbindungen müssen korrekt validiert werden - Selbstsignierte Zertifikate nur in abgeschotteten Test-/Entwicklungsumgebungen - Regelmäßige Überprüfung der Zertifikatsgültigkeit

NIST (National Institute of Standards and Technology): - Zertifikatvalidierung ist essentiell für sichere Kommunikation - Ausnahmen nur in kontrollierten, isolierten Umgebungen

Datenschutzrechtliche Bewertung (DSGVO):

• Das Ignorieren von SSL-Fehlern kann als unzureichende technische Maßnahme (Art. 32 DSGVO) gewertet werden

• Bei Datenschutzverletzungen durch Man-in-the-Middle-Angriffe drohen Bußgelder

• Meldepflicht bei Datenschutzvorfällen innerhalb 72 Stunden

Fazit: EXTREM KRITISCHER SICHERHEITSPARAMETER! Die Aktivierung sollte ausschließlich in isolierten Test-/Entwicklungsumgebungen erfolgen und muss zeitlich begrenzt sein. In Produktivumgebungen ist die Aktivierung ein gravierendes Sicherheitsrisiko.

Praktisches Beispiel

Szenario 1: Abgelaufenes Zertifikat (Notfall-Workaround)

Ausgangssituation:
Am Freitagabend stellt der Administrator fest, dass das SSL-Zertifikat eines integrierten Drittsystems abgelaufen ist. Das Portal kann keine Verbindung mehr herstellen. Die Schnittstelle ist geschäftskritisch und muss sofort wieder funktionieren. Die Zertifikatserneuerung beim Drittanbieter dauert bis Montag.

Temporäre Konfiguration:

Nach der Änderung:

• Das Portal stellt trotz abgelaufenem Zertifikat Verbindungen zum Drittsystem her

• Die Schnittstelle funktioniert wieder

• Im Application-Log erscheinen Info-Meldungen über die ignorierten Zertifikatfehler

• Die Geschäftsprozesse laufen normal weiter

Am Montag (nach Zertifikatserneuerung):

Ergebnis:
Geschäftskritische Funktion wurde über das Wochenende aufrechterhalten. Die Sicherheitslücke wurde nach 3 Tagen geschlossen.

WICHTIG: Diese Lösung ist nur für absolute Notfälle akzeptabel und muss dokumentiert und zeitlich begrenzt sein!

Szenario 2: Entwicklungsumgebung mit selbstsignierten Zertifikaten

Ausgangssituation:
Ein Entwicklerteam arbeitet an einer neuen Schnittstelle zu einem externen System. Die Test-Instanz des externen Systems verwendet selbstsignierte Zertifikate. Das Portal verweigert die Verbindung.

Konfiguration (nur Entwicklungsserver):

Nach der Änderung:

• Entwickler können die Schnittstelle testen, ohne offizielle Zertifikate zu benötigen

• Integration kann schneller entwickelt und getestet werden

• Kosten für Test-Zertifikate werden gespart

• Logs zeigen alle ignorierten Zertifikatfehler

Wichtige Maßnahmen: - Parameter nur auf Entwicklungsservern aktivieren - Produktivumgebung bleibt auf 0 (sicher) - Vor Go-Live Zertifikate vom externen System anfordern - Dokumentation für Entwicklerteam erstellen

Ergebnis:
Schnellere Entwicklung ohne Kompromisse in der Produktivsicherheit.

Szenario 3: Falscher Hostname im Zertifikat

Ausgangssituation:
Ein externes System ist über api.partner.com erreichbar, das SSL-Zertifikat wurde aber auf partner.com ausgestellt. Das Portal meldet RemoteCertificateNameMismatch.

Falsche Lösung:

Richtige Lösung: 1. Beim Partner ein Zertifikat mit korrektem Subject Alternative Name (SAN) anfordern 2. Oder: DNS-Eintrag anpassen 3. Parameter auf 0 belassen

Ergebnis:
Korrekte Konfiguration statt Sicherheitsrisiko.

Empfohlene Einstellung

Für Produktivumgebungen:0(NIEMALS Zertifikatfehler ignorieren)

Begründung: - Maximale Sicherheit für Produktivdaten - Schutz vor Man-in-the-Middle-Angriffen - Einhaltung von Compliance-Vorgaben (ISO 27001, DSGVO, PCI DSS) - Best Practice nach allen Sicherheitsstandards - Vermeidung rechtlicher Risiken

Dies ist die EINZIGE akzeptable Einstellung für Produktivsysteme.

Für Test-/Entwicklungsumgebungen:0 oder 1 (kontextabhängig)

Wert 0 (empfohlen): - Auch in Test-Umgebungen sollte der Standard 0 sein - Fördert produktionsnahe Tests - Deckt Zertifikatprobleme frühzeitig auf

Wert 1 (nur wenn notwendig): - Selbstsignierte Zertifikate sind unvermeidbar - Kosten für Test-Zertifikate sollen gespart werden - Schnelle Prototypen-Entwicklung erforderlich

Voraussetzungen für 1 in Test-Umgebungen: - Netzwerk ist vom Internet isoliert - Nur Entwickler haben Zugriff - Keine produktiven oder personenbezogenen Daten - Aktivierung ist dokumentiert - Regelmäßige Überprüfung

Checkliste vor Aktivierung:

• [ ] Ist dies eine Test-/Entwicklungsumgebung (NICHT Produktion)?

• [ ] Gibt es keine Alternative (z.B. Let's Encrypt)?

• [ ] Ist das Netzwerk vom Internet isoliert?

• [ ] Sind keine produktiven Daten betroffen?

• [ ] Ist ein Enddatum festgelegt?

• [ ] Wurde die Aktivierung dokumentiert?

• [ ] Wurde ein Reminder gesetzt?

• [ ] Wurden Stakeholder informiert?

Falls Sie auch nur eine Frage mit "Nein" beantworten, aktivieren Sie den Parameter NICHT!

Zusammenfassung:

Faustregel: Im Zweifel IMMER 0 verwenden. Lieber warten und das Problem korrekt lösen, als Sicherheitsrisiken einzugehen.

IC2861