Kategorien
Security Server Verschlüsselung

Virtuelle Apache Hosts mit TLS/SSL Zertifikaten von StartSSL absichern

Verschlüsselung sollte einfacher nutzbar sein und Kommunikation grundsätzlich abgesichert werden um so die Massenüberwachung zu verhindern oder zumindest zu erschweren.

Nachdem ich in der letzten Woche das Thema TLS/SSL etwas ausführlicher beleuchtet habe, will ich in dieser Woche nun meine Beispielwebsites mit einem TLS Zertifikat versehen.

In meinem LAMP Stack auf dem Beispiel Root-Server läuft Ubuntu und der Apache 2 Webserver mit mehreren virtuellen Hosts.

Ein Root-Server hat „normalerweise“ (was ist schon normal in diesem Bereich 😉 ) eine IP-Adresse und einen Standard Host mit einem Domainnamen. Dieser Standard Host läuft auf Port 80. Die Apache Standard Konfiguration enthält auch einen TLS gesicherten Host, der läuft auf Port 443. In der Ubuntu Distribution ist der TLS/SSL Host vorkonfiguriert und kann mit den Befehlen.

sudo a2enmod ssl
sudo a2ensite default-ssl
sudo service apache2 reload

eingeschaltet werden. Ich hatte das im OwnCloud Artikel so gemacht und konnte daraufhin serverblogger.ch über http:// und https:// aufrufen. Der Haken bei der Sache ist, dass Ubuntu in diesem Zusammenhang in der Standardeinstellung ein selbst erstelltes Zertifikat nutzt. Dass hatte zur Folge, dass alle Browser darüber stolpern und ein PopUp Fenster mit einer Fehlermeldung anzeigen. Nach dieser Meldung werden vermutlich nicht viele Menschen die https:// Variante nicht besuchen. Wenn man die serverblogger.ch in einer Testsite wie https://www.ssllabs.com/ssltest/ aufruft, so sieht man das ganze Drama :).

In diesem Artikel will ich das Rating vom T auf ein A bringen.
In diesem Artikel will ich das Rating vom T auf ein A bringen.

Dazu erstelle ich ein kostenloses Zertifikat bei startssl.com und konfiguriere den Apache Webserver so, daß er mit mehrere Zertifikaten und mehreren virtuellen Servern mit unterschiedlichen Domainnamen zurechtkommt.

Ein kostenloses Webserver Zertifikat bei startssl.com erzeugen

Die Firma StartCom aus Israel bietet die Erstellung kostenloser Webserver-Zertifikate an und ist als Certified Authority (CA) in jedem Browser hinterlegt. Die Zertifikate sind also gültig und werden vom Browser akzeptiert. Die Schlüssel werden mittels Hardware generiert und sind laut FAQ sicher.

Achtung: StartSSL bietet an, Ihren privaten Schlüssel zur Erzeugung eines Zertifikats ebenfalls zu erstellen. Die von StartSSL erstellten privaten Schlüssel können natürlich von den üblichen Geheimdiensten mitgelesen/kopiert werden und StartSLL darf nichts sagen oder weiss es wirklich nicht. Wenn Sie Ihren privaten Schlüssel zur Erzeugung der Zertifikate selbst erzeugen UND mit einem Passwort versehen, sieht es mit der Sicherheit gar nicht so schlecht aus. Dieses grundsätzliche Problem hat man bei anderen CA’s ebenfalls.

Um Zertifikate erstellen zu können, muss man sich zunächst mit seinen persönlichen Daten registrieren.

Persönliche Daten
Persönliche Daten
Es wird eine E-Mail an die angegebene Adresse geschickt, die einen Überprüfungscode enthält.
Codeeingabe
Codeeingabe
Nachdem man den Code erfolgreich eingegeben hat, erzeugt der Browser einen privaten Schlüssel.

private key
private key
Mit diesem privaten Schlüssel wird ein Zertifikat erzeugt und in Ihrem Browser installiert. Dieses Zertifikat hat noch nichts mit den Webserver Zertifikaten zu tun. Sie authentifizieren sich damit in Zukunft gegenüber StartSSL. Ein Login mit Username und Passwort entfällt. Da dieser Schlüssel im lokalen Browser erzeugt wird, sollte es kein Problem darstellen. Ich bin da allerdings auch kein Spezialist und für Aufklärung dankbar.



Das Zertifikat wurde erzeugt und im Browser installiert. Sie können nun mit diesem Zertifikat Ihr StartSSL Konto verwalten! Sie sollten das Browserzertifikat sichern und an einem „sicheren Ort“ verwahren (z.B. USB Stick).

So sieht das bei mir im Firefox Browser aus …

StartSSL weiss nun, daß Sie es mit ein und derselben Person zu tun haben. Im nächsten Schritt muss ich die Domain, für die ich ein Webserver Zertifikat haben will, überprüfen lassen.

Domain überprüfen

Das Prinzip ist einfach. Klicken Sie auf Validation Wizard, fügen Sie Ihren Domainnamen ein, StartSSL schickt eine E-Mail an den administrativen Kontakt der Domain mit einem Code. Wenn Ihnen die Domain gehört, erhalten Sie den Code, geben ihn ein und haben dann 30 Tage das Recht Zertifikate zu erzeugen.


Die Domain ist nun überprüft und Sie können ein Webserver-Zertifikat erzeugen.

Webserver TLS/SSL Zertifikat erstellen

Als letzten Schritt erstellen Sie das eigentliche Zertifikat. Rufen Sie den Certificates Wizard auf und wählen zunächst den Typ des Zertifikats.


Beim nächsten Schritt ist es wichtig NICHT auf Continue, sondern auf Skip zu klicken und dann den privaten Schlüssel/Key selbst zu erzeugen. Der private Key wird auf Ihrem Root-Server gespeichert und der Apache Webserver liest ihn bei jedem Neustart ein und überprüft, ob die TLS Zertifikate zu diesem Key passen. Wenn Sie den Key mit einem Passwort versehen, was prinzipiell eine gute Idee ist, so müssen Sie das Passwort bei jedem Apache Neustart angeben. Alle mit diesem Key erzeugten Zertifikate sind nur gemeinsam mit Passwort gültig! Es gibt allerdings Möglichkeiten, diese Eingabe zu automatisieren.

Legen Sie sich auf dem Server mit dem folgenden Befehl einen privaten Schlüssel an:

openssl req -newkey rsa:4096 -sha256 -keyout private.key -out request.csr

Mit diesen Befehl wird ein 4096 bit langer RSA Schlüssel erzeugt. Der Algorithmus SHA-256 gilt momentan als sicher. Geben Sie ein Passwort ein (und vergessen Sie es nicht). Die dann folgenden Abfragen können mit der Enter Taste bestätigt werden, da die Daten von StartSLL ignoriert werden.

root@server1:/etc/ssl/myssl# openssl req -newkey rsa:4096 -sha256 -keyout private.key -out request.csr
Generating a 4096 bit RSA private key
....++
......................................++
writing new private key to 'private.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
root@server1:/etc/ssl/myssl#

Es entstehen zwei Dateien, eine heisst private.key und die andere request.csr. In der request.csr steht der Inhalt, den StartSSL für das Erstellen eines Zertifikats benötigt (csr = certified request).

Der Inhalt der request.csr Datei muss im nächsten Schritt in das Formularfeld kopiert werden.

StartSSL fragt die gewünschte Domain und eine Subdomain ab. Als Subdomainnamen gibt man normalerweise www ein.

Achtung: Das Zertifikat ist nur für diese eine Subdomain gültig. Weitere Subdomains sind nur kostenpflichtig möglich.

Nach der Domainauswahl erzeugt StartSSL nun das Zertifikat und zeigt es an.

Speichern Sie den Inhalt der Textbox in einer Datei (z.B. serverblogger.ch.crt) ab. Ausser diesem Zwischenzertifikat werden die intermediate und die root Zertifikate von StartCom benötigt. Auch diese Dateien im gleichen Verzeichnis speichern (der Übersicht halber). Sie finden die Dateien in der obigen Maske und in der Toolbox.

In Ihrem Verzeichnis befinden sich nun 5 Dateien

  • ca.pem
  • serverblogger.ch.crt
  • private.key
  • request.csr
  • sub.class1.server.ca.pem

Damit serverblogger.ch.crt gültig wird, muss noch der Inhalt des intermediate Zertifikats (sub.class1.server.ca.pem) in die Datei (serverblogger.ch.crt) kopiert werden.

—- BEGIN CERTIFICATE —-

… hier die Daten der serverblogger.ch.crt …

—- END CERTIFICATE —-

—- BEGIN CERTIFICATE —-

… hier die Daten der sub.class1.server.ca.pem …

—- END CERTIFICATE —-

Konfiguration des Apache Webservers

Dadurch, das ich namensbasierte virtuelle Hosts verwende (und normalerweise jeder dieser Hosts eine andere Domain hat), benötige ich für jeden virtuellen Host eine TLS/SSL Konfiguration.

Die Datei des virtuellen Servers muss entsprechend verändert werden.

<VirtualHost serverblogger.ch:80>
      ServerAdmin webmaster@serverblogger.ch
      ServerName serverblogger.ch
      ServerAlias www.serverblogger.ch
      DocumentRoot /var/www/serverblogger.ch/public_html/
      ErrorLog /var/www/serverblogger.ch/logs/error.log
      CustomLog /var/www/serverblogger.ch/logs/access.log combined
</VirtualHost>

<VirtualHost serverblogger.ch:443>
     DocumentRoot /var/www/serverblogger.ch/public_html/
     Servername serverblogger.ch
     SSLEngine On
     SSLCipherSuite AES128+EECDH:AES128+EDH
     SSLProtocol All -SSLv2 -SSLv3
     SSLHonorCipherOrder On
     SSLCertificateFile /etc/ssl/myssl/serverblogger.ch.crt
     SSLCertificateKeyFile /etc/ssl/myssl/private.key
     SSLCertificateChainFile /etc/ssl/myssl/sub.class1.server.ca.pem
     SSLCACertificateFile /etc/ssl/myssl/ca.pem
     Options -Indexes
</VirtualHost>

Wenn Sie nun den Apache neu starten, fragt er das Passwort ab

service apache2 restart
* Restarting web server apache2   Apache needs to decrypt your SSL Keys for serverblogger.ch:443 (RSA)
Please enter passphrase:

Nach Eingabe des richtigen Passwort sollte der Webserver starten und bei einer https:// Verbindung sollte im Browser folgendes zu sehen sein.

Erneuter Test

Ein erneuter Test bei ssllabs.com zeigt nun ein anderes Bild, der Server ist deutlich vertrauenswürdiger geworden.

SSL Report: serverblogger.ch

SSL Report: serverblogger.ch

Ein Konfigurationshilfe für andere Services finden Sie unter https://cipherli.st/

1. Hinweis: Die Einstellungen des SSL/TLS gesicherten Webservers sind jetzt so streng, daß sie beispielsweise dem Internet Explorer 8 verbieten auf die https:// Version der Site zuzugreifen. IE 8 betrifft etwa 1% aller Browser weltweit (oder knapp 10% aller Internet Explorer Versionen, deren gesamter Marktanteil bei etwa 8-10% liegt.

2. Hinweis: Wir bei NOVATREND verkaufen Ihnen ebenfalls Zertifikate von GeoTrust und von VeriSign/Symantec. Wir installieren Sie auch für Sie auf Ihrem Root-Server. Ich stelle das hier im Blog nochmal deutlich hervor, weil es für den professionellen Einsatz einfach eine praktische Dienstleistung ist.

3. Hinweis: Seit In ein paar Tagen ist wird unser Blog nur noch unter https://blog.novatrend.ch aufrufbar sein -> Update1 – Das Zertifikat fehlt noch.


tl;dr: Die Webserver Kommunikation auf einem Root-Server zu verschlüsseln ist gar nicht so schwer. Also los!

Kategorien
Security Verschlüsselung

Zertifikate, SSL, TLS und HTTPS – ein Crashkurs

Wir sind an dem Thema SSL, TLS, https, Zertifikate und Verschlüsselungsprotokolle nun so oft „vorbeigeschrammt“, dass ich mal näher darauf eingehen muss. Leider ist das wie so oft „nicht so einfach“ und falls Sie sich noch nie wirklich mit dem Thema beschäftigt haben, sollten Sie einen Moment innehalten und versuchen die Zusammenhänge zu verstehen. Hier ein kurzer Crashkurs mit wichtigen Begriffen und kurzen Erklärungen.

SSL/TLS

SSL ist die Abkürzung für Secure Sockets Layer und ist ein Verschlüsselungsprotokoll für die Datenübertragung im Internet. Bis zur Version 3.0 heisst es SSL, alle Versionen danach heissen TLS (Transport Layer Security). Diese Umbenennung fand schon im Jahr 1999 statt. Die Version TLS 1.0 entspricht der Version SSL 3.1. Die aktuelle Version von TLS ist 1.2.

In Zukunft und im weiteren Verlauf dieses Blogeintrags werde ich die Bezeichnung TLS verwenden.

Verschlüsselungsprotokoll und Schlüsselverteilungsproblem

Ein Verschlüsselungsprotokoll ist eine besondere Art des Netzwerkprotokolls. Eine grosse Herausforderung bei allen Verschlüsselungsverfahren ist das Schlüsselverteilungsproblem. Beide Teilnehmer müssen einen Schlüssel besitzen, um die Nachrichten zu ver- bzw. zu entschlüsseln.

Die einzige Möglichkeit verschlüsselt zu kommunizieren war lange Zeit die Übersendung des Schlüssels per Boten oder eben ihn persönlich zu überbringen!

Um diesen Aufwand zu vermeiden wurden in den siebziger Jahren des letzten Jahrhunderts symetrische und asymetrische Verschlüsselungsverfahren entwickelt.

Symmetrisches Verfahren

Beim symmetrisches Verfahren kommunizieren beide Partner mit demselben Schlüssel. Die Schlüssel müssen also sicher übertragen werden.

Asymmetrisches Verfahren

Beim asymetrischen Verfahren, auch Public-Key Verfahren genannt, erzeugt ein Benutzer ein Schlüsselpaar, das aus einem geheimen (private) und einem öffentlichen (public) Schlüssel besteht. Der öffentliche Schlüssel kann „öffentlich“ ausgetauscht werden. Er ermöglicht es jedem, Daten für den Inhaber des privaten Schlüssels zu verschlüsseln. Nur der Besitzer des geheimen Schlüssels kann diese Daten wieder entschlüsseln.

Damit entfällt die „komplizierte, geheime“ Übertragung des Schlüssels. Der öffentliche Schlüssel kann bedenkenlos geteilt werden werden und das Schlüsselverteilungsproblem ist gelöst.

Aber:

Um das Schlüsselpaar zu erzeugen, benötigt man eine zufällige Zahl. Und Zufall ist nicht ganz einfach zu erzeugen auf einem Computer. Normalerweise benutzt man dafür einen Zufallszahlengenerator (ein Stück Software). Diese Zufallszahlengenratoren können manipuliert werden (Beispiel 1, Beispiel 2). Im Artikel Ein Backup mit Duply hatten wir bereits das Problem mit der Entropie (dem Zufall).

Zweites aber:

Da der öffentliche Schlüssel jedem zur Verfügung steht, ist nicht sicher gestellt, dass genau dieser öffentliche Schlüssel auch dem gewünschten Empfänger zugeordnet werden kann. An dieser Stelle kommen digitale Zertifikate ins Spiel, die den öffentlichen Schlüssel einem privaten Schlüsselinhaber zuordnen, also gewissermassen zertifizieren, dass der öffentliche Schlüssel zu der entsprechenden Person oder Firma gehört.

Drittes aber:

Die asymetrische Verschlüsselung ist langsamer im Vergleich zur symmetrischen Verschlüsselung.

TLS kombiniert beide Verfahren

TLS ist ein hybrides Protokoll, es kombiniert symmetrische und asymmetrische Verfahren.

TLS funktioniert folgendermassen:

  1. Ein Client baut eine Verbindung zum Server auf (Aufruf von https://… im Browser)
  2. Der Server schickt dem Client sein Zertifikat
  3. Der Client überprüft ob Zertifikat und Servername zusammenpassen und schickt dem Server entweder eine mit dem öffentlichen Schlüssel des Servers verschlüsselte Zufallszahl oder beide Parteien berechnen ein gemeinsames Geheimnis (Diffie Hellman Schlüsseltausch)
  4. Aus der Zufallszahl oder dem Geheimnis wird ein Schlüssel berechnet, der dann beiden Parteien zur Verfügung steht und die dann folgende Kommunikation schützt (symmetrisches Verfahren).

Implementierungen des Protokolls finden sich in den Bibliotheken OpenSSL und GnuTLS.

Wichtige Anwendungsfälle für TLS, die auch hier im Blog immer wieder vorkommen, sind die Protokolle HTTP, POP3, SMTP, NNTP, SIP, IMAP, XMPP, IRC, LDAP, FTP und OpenVPN.

Hinweis: In diesem Zusammenhang haben Sie bestimmt schon vom Heartbleed-Bug gehört. Bei diesem „Fehler“ konnte ein „Angreifer“ über Jahre den Arbeitspeicher der beteiligten Partner auslesen und dort private Schlüssel, Benutzernamen und Passworte abgreifen. Der Web Comic xkcd erklärt Heartbleed sehr anschaulich:

HTTP und HTTPS

TLS-Verschlüsselung wird zum grössten Teil zur Absicherung des HTTP Protokolls verwendet. HTTP steht für Hypertext Transfer Protocol und ist das unverschlüselte Kommunikationsprotokoll im WWW. Wenn die Kommunikation über HTTP und TLS abgewickelt wird, spricht man vom HTTPS Protokoll (Hypertext Transfer Protocol Secure).

Wenn Sie beispielsweise Websites über das unverschlüsselte HTTP Protokoll

  • in einem ungesicherten WLAN ansehen, kann der Klartext Ihrer Kommunikation von jedem „Angreifer“ in Reichweite des WLANs mitgelesen werden.
  • in einem kabelgebundenen Netz oder verschlüsseltem WLAN ansehen, kann der Klartext von allen Teilnehmern des Netzes mitgelesen werden.

Wenn Sie Ihre Kommunikation über HTTP/TLS, also HTTPS abwickeln, so ist ein Mitlesen zwar möglich, aber der Netzwerkverkehr ist verschlüsselt und kann nicht „einfach so“ entschlüsselt werden.

Digitale Zertifikate

Ein digitales Zertifikat bestätigt bestimmte Eigenschaften von Personen und Objekten. Sie können Zertifikate selbst erzeugen oder bei einer Zertifizierungsstelle kaufen. Die technischen Vorgänge sind bei selbst zertifizierten und bei gekauften Zertifikaten die gleichen. Sie sind also „gleich sicher“. Der Unterschied besteht im Vertrauen in den Austeller des Zertifikats. Wenn Sie mit eine HTTPS Verbindung mit unserem Testserver herstellen (https://serverblogger.ch), erhalten Sie die Meldung Invalid Certificate.

Invalid Certificate
Invalid Certificate
Je nach Browsertyp erhalten Sie eine ähnliche Meldung. Der Text ist etwas irreführend. Das Zertifikat ist nicht ungültig, sondern einfach selbst zertifiziert. Die Situation ist ein vergleichbar mit einem Zertifikat über Ihren Bildungsstand. Sie könnten sich selbst zertifizieren, dass Sie einen bestimmten Kenntnisstand oder Bildungsabschluss haben. Die meisten Menschen würden dieser Bestätigung vermutlich wenig Glauben schenken (auch wenn sie wahr ist). Wenn dagegen eine dritte Instanz, wie die entsprechende Schule oder Ausbildungsstätte Ihren Kenntnisstand bestätigt, sieht die Sache schon ganz anders aus.

Wenn Sie auf die Website https://www.nsa.gov gehen, so vertraut Ihr Browser dem Zertifikat.

SSL Zertifikat
SSL Zertifikat
Es wurde von der Zertifizierungsstelle Geo Trust ausgegeben und ist gültig bis zum 02.12.2015. Ihr Browser ordnet das Zertifikat als gültig ein und stuft damit die Site als vertrauenswürdig ein. Damit ein Browser unterscheiden kann, welcher Zertifizierungsstelle er vertraut, und welcher nicht, schaut er einfach in eine Liste der Zertifizierungsstellen. Im Firefox Browser finden Sie die Liste der Authorities in den Sicherheitseinstellungen oder online hier.
BuiltInCAs Firefox
BuiltInCAs Firefox
Ihr Browser vertraut allen dort gelisteten Unternehmen! Sie können die Liste allerdings bearbeiten und einzelne Zertifizierungsstellen löschen. Das machen allerdings die wenigsten Menschen. Wenn Sie einen Root-Server betreiben und ganz normale Menschen mit ganz normalen Browsern Ihre Services nutzen, haben Sie keine echte Wahl.

Sie müssen ein Zertifikat kaufen, ansonsten gibt es den Fehlerhinweis im Browser Ihres Kunden und vermutlich wird er Ihre Site daraufhin nicht benutzen!

Die Zertifizierungsstellen sind wieder ähnlich wie beim Schulbeispiel – es gibt gute und schlechte Schulen und man kann sich natürlich auch Doktortitel kaufen. Bei den Zertifikaten ist es manchmal ebenso (Beispiele hier, hier und hier). Wegen der mangelnden Vertrauenswürdigkeit einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt (Heise: EFF zweifelt an Abhörsicherheit von SSL). Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich das Risiko jedoch weitgehend beseitigen.

Auch wenn das Zertifikatssystem weder perfekt, noch wirklich sicher ist, ist es der einzige Mechanismus, der momentan in der Masse zur Verfügung steht. Man kann es vielleicht mit dem Geschäftsmodell vieler Kreditkartenfirmen vergleichen. Es ist einfacher für diese Firmen einen finanziellen Schaden, den der Kunde im Einzelfall hatte, auszugleichen, als von Anfang an für bessere Sicherheit zu sorgen.

Damit Sie nun nicht völlig den Glauben an die Sicherheit verlieren, ein kleiner Hoffnungsschimmer.

Jede noch so nachlässig implementierte verschlüsselte Verbindung ist ein Quentchen besser als eine unverschlüsselte Verbindung.

Je nach dem Grad Ihres persönlichen Vertrauens und dem Inhalt Ihres Geldbeutels, können Sie sich bei der israelischen Firma StartCOM ein kostenloses Zertifikat ausstellen lassen oder ein Zertifikat bei einer Tochter der Schweizer Post kaufen (SwissSign).

Wir bei NOVATREND verkaufen Ihnen ebenfalls Zertifikate. Die kommen von GeoTrust (die kennen Sie ja schon 😉 ) und von VeriSign/Symantec. Und wir installieren Sie auch für Sie auf Ihrem Root-Server. Ich stelle das hier im Blog mal deutlich hervor, weil es für den professionellen Einsatz einfach eine praktische Dienstleistung ist.

Unterschiedliche Arten von Zertifikaten (blau und grün)

Um die Sache noch etwas spannender zu gestalten, gibt es unterschiedliche Arten von Zertifikaten. Ausser der Stärke der Verschlüsselung ist das in erste Linie die Domain- oder die Identitätsprüfung.

Bei der Domainprüfung gibt es Single, Wildcard und Multidomain Zertifikate. Single Zertifikate umfassen genau eine Domain, Wildcard Zertifikate die Hauptdomain und alle Subdomains, Multidomain-Zertifikate umfassen mehrere Domains. Überprüft wird von der Zertifizierungsstelle, ob der Auftraggeber der Inhaber der Domain ist. Dazu wird automatisiert eine E-Mail an den administrative Adresse im Whois Eintrag geschickt. Diese E-Mail muss auf unterschiedliche Art bestätigt werden. Der Vorgang geht innerhalb kurzer Zeit (Minuten) und man erkennt es auch im Browser (Domain Validation).

Facebook
Facebook
Hier ein Beispiel für ein wohl vergessenes Multidomain Zertifikat, dass zum Einsatz kommt, wenn ich die BMW Site über HTTPS aufrufe (https://www.bmw.com/). Das Zertifikat ist nicht für diese Domain zertifiziert.
BMW
BMW
Bei der Identitätsprüfung einer Organisation wird ausser der Domainprüfung auch ein Handelsregisterauszug verlangt und teilweise telefonisch Kontakt aufgenommen. Bei einer erweiterter Prüfung (Extended Validation Certificate) wird ausserdem eine grüne Addresszeile im Browser angezeigt .
Postbank
Postbank
Schauen Sie sich mal die Zertifikate der Websites an, mit denen Sie regelmässig Kontakt haben.


tl;dr: Jeglicher Netzwerkverkehr sollte, wenn möglich, über TLS abgewickelt werden um ein Mindestmass an Abhörsicherheit zu gewährleisten. Als Betreiber eines Root-Servers sollten Sie sich ein Zertifikat von einer Zertifizierungsstelle installieren oder installieren lassen, der die gängigen Browser und damit auch Ihre Kunden vertrauen.