Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Am besten eine Fachmann/frau fragen, und sich da ganze verbindlich aber vorallem schriftlich geben lassen, einfach mal alle Fragen zu dem Thema auf Tisch legen.
Dann klapt es auch mit den Gesetzten.
Unabhängig davon ob das DSGVO konform ist oder nicht (durchlesen wird dir nichts bringen, das steht so nicht da drin) macht es natürlich Sinn ein Zertifikat zu verwenden das von den Clients auch validiert werden kann. Das kann auch ein selbst erstelltes sein sofern die Clients dann entsprechend der Zertifizierungsstelle vertrauen.
Ansonsten kannst du vielleicht über das Gateway was davor hängt ein Lets Encrypt zertifikat erstellen lassen. Das geht z.B. mit einer pfsense/opnsense oder der aktuellen Sophos SG vollkommen automatisch und dann Server wäre dann von jedem Client sicher ansprechbar, nicht nur denen der eigenen Domäne.
Sehe ich wie Masamune2. Nur weil ein Client melden "könnte", dass er deinem Exchange nicht vertraut, ist das noch kein Beweis, dass du nicht verschlüsselst. Weit verbreitete Beispiele sind Zertifikate für Zugänge zu Universitätsnetzwerken, die auch manuell installiert werden. Das ist keine Rechtsberatung, aber mich würde es wundern, wenn die gegen irgendwas verstoßen würden.
Wenn eure IT ordentlich arbeitet, ist es kein Problem selbst signierte Zertifikate einzusetzen. Es sollte halt zwingend abgesichert werden das:
Der Server Verbindungen ausschließlich verschlüsselt aufbaut. Dabei sind als unsicher geltende Verfahren auszuschließen.
Clients und Server prüfen das Zertifikat. Wenn der Server sich mit Zertifikaten vorstellt die von Dritten stammen, sollten die Clients die Verbindung verweigern.
Ihr habt eine Strategie wie ihr eure Certs und privaten Schlüssel sichert und wie ihr im Verlustfall diese widerruft.
Die Punkte ändern sich mit von Dritten signierten Zertifikaten auch nicht, die Anforderungen sind die Selben.
Wenn euer System jedoch bedingt, dass Nutzer häufig Warnungen bekommen, weil nicht unterschriebene bzw. nur selbst signierte Zertifikate vorliegen, so habt ihr ein Problem. Denn Nutzer die daran gewöhnt werden solche Sicherheitshinweise einfach wegzuklicken werden nicht merken, wenn wirklich mal etwas faul ist. Solche Meldungen sollten Nutzer nur sehen, wenn wirklich etwas faul ist und die Reaktion MUSS an der Stelle sein, dass die Meldung nicht übergangen wird! Die IT gehört informiert und das Problem grundlegend abgestellt. Was aber auch heißt, dass die IT NIE Empfehlungen zum wegklicken solcher Meldungen geben darf.
Ansonsten gibt das BSI regelmäßig aktualisierte Leitfäden zur IT-Sicherheit heraus. Die Annahme ist typischerweise, dass wenn man diesen folgt, dass man den so oft geforderten "technischen Stand" einhält. Muss man halt regelmäßig neu Sichten, evaluieren, seine IT anpassen und dokumentieren.
@Kr1ller
Datenschutzbeauftragte haben meist keine Ahnung von der IT, bei Rechtsgelehrten ist der technische Hintergrund meist auch nicht da und Systemhäuser beraten all zu gern nach größt möglichem Gewinn. Also einmal voll evaluiertes, ISO/TÜV zertifiziertes Schlangenölzertifikat für 600€ p.a.
Ergänzung ()
Wilhelm14 schrieb:
Weit verbreitete Beispiele sind Zertifikate für Zugänge zu Universitätsnetzwerken, die auch manuell installiert werden.
Dann hat die Administration der Uni aber keinen blassen Schimmer was sie tun. Über das DFN ist es überhaupt kein Problem gescheite Signaturketten hinzubekommen.
Der größte Nachteil an selbst ausgestellten Zertifikaten ist, dass du die nicht einfach verwalten kannst.
Wenn das Zertifikat samt Schlüssel abhanden kommt, kannst du zwar auf dem Server ein neues verwenden, aber das hindert den mit dem alten Zertifikat nicht daran, sich als dein Server auszugeben.
Wenn du auf den Clients z.B. per GPO das alte Zertifikat sperren kannst und das neue verteilst, machst du aber vereinfacht das, was auch eine CA macht.
Damit die Clients deinem Server vertrauen und keine Warnung ausgeben, musst du vermutlich eh das Zertifikat an die Clients verteilen.
Verschlüsseln kannst du natürlich auch mit einem selbst erstellten Zertifikat.
Wenn alles richtig konfiguriert ist, dürfte das auch nicht unsicherer sein als ein Zertifikat von einer allgemein getrusteten CA zu kaufen. Du solltest dich aber darum kümmern, wie die Zertifikate verteilt und zurückgezogen werden können auf den Clients.
Vielleicht habt ihr ja im Unternehmen schon eine eigene interne CA und verteilt das RootCert an die Clients, dann kann man das ja wunderbar einbinden.
//edit:
Aber wenn wirklich ein selbst erstelltes Zertifikat nutzen willst, dann achte zumindest auf eine Schlüssellänge von mindestens 2kb und einen passenden Algorithmus (kein MD5, SHA-1, ..., zumindest SHA-256 wäre angebracht).
Selbst ausgestellte Zertifikate sind (zumindest) außerhalb deines Arbeitsgebers sicherheitstechnisch (so gut wie) nutzlos.
Kleiner leicht, verständlicher Vergleich: Ein Zertifikat hat in der Computerwelt eine ähnliche Funktion wie ein Reisepass bei Menschen. Wenn du dir den selber ausstellen würdest (entspricht dann dem selbst ausgestellten Zertifikat), dann kann ich zwar der Echtheit vertrauen, sichergestellt ist die aber nicht. Demnach braucht's einen Dritten (im Falle von Zertifikaten einen anerkannten Zertifikataussteller, im Falle des Reisepasses eine anerkannte Behörde), die das Zertifikat (den Reisepass) ausstellt und somit die Echtheit des "Dokuments" garantiert. Also wenn du ein selbst signiertes Zertifikat auf auf den OWA draufklappst bringt das nicht wirklich was. Für HTTPS schau dir einfach LetsEncrypt an, kostet nix.
DSGVO: Prinzipiell solltest du jegliche Übertragungen verschlüsseln, die personenbezogene Daten enthalten. Personenbezogene Daten sind alle Daten, mit denen eine Person identifiziert wurde oder identifiziert werden kann (Name, IP, Adresse, Geschlecht, Gesundheitsdaten,....).
Das betrifft Frontends (die von jedem Rechnern aufgerufen werden können und personenbezogene Daten anzapfen oder sammeln), Webformulare,....
