SSL/TLS Zertifikate für die Nutzung im internen Netz (apache)

Um verschiedene Dienste im LAN sicher zu nutzen, werden SSL-Zertifikate benötigt. Wir verwenden dafür in manchen Fällen ein selbstsigniertes Zertifikat. Das SSL-Zertifikat enthält Informationen über den Namen des Inhabers, den öffentlichen Schlüssel, eine Gültigkeitsdauer und gegebenenfalls den Namen der Zertifizierungsstelle. Mit dem öffentlichen Schlüssel kann das Zertifikat der Zertifizierungsstelle überprüft werden.

Das SSL-Zertifikat muss zuerst als vertrauenswürdig eingestuft werden, dazu sind bestimmte Rangordnungen der Autoritäten notwendig. Der Browser verfügt über Listen mit Zertifizierungsstellen deren SSL-Zertifikate bedingungslos vertraut werden. Beim Aufrufen einer SSL-verschlüsselten Website, prüft der Browser das Zertifikat auf Gültigkeit der Referenzen und des Herausgebers der Webadresse. Kennt der PC oder Browser den Herausgeber des Zertifikates nicht, meldet er einen Zertifikatsfehler. Diesen Fehler kann man übergehen und seinen Besuch auf der Website fortsetzen.

Selbstsignierte Zertifikate geben diesen Fehler logischerweise immer, da sie nicht von einer Zertifizierungsstelle als gültig und sicher geprüft wurden. Hier signiert der Server selbst für seine Dienste, die von den jeweiligen Clients besucht werden.

Ich zeige euch, wie wir das Zertifikat erstellen und manuell in den Firefox-Browser hinterlegen.

Zuerst müssen wir einen Private-Key erstellen, der immer bei uns verbleibt. Niemand außer uns sollte Zugriff auf diese Datei haben, da der Private-Key später untrennbar von unserem Zertifikat ist. Dazu wechseln wir in das Verzeichnis, indem wir den Schlüssel gerne haben wollen:

openssl genrsa -aes256 -out ca-key.pem 2048

Mit dem Argument -aes256 (Abkürzung für „Advanced Encryption Standard“) verschlüsseln wir unsere Datei mit einer 256Bit Schlüssellänge. Der Key muss eine Länge von 2048bit haben und in unserem Beispiel nenne ich ihn ca-key.pem (nehmt einen Namen, den ihr später leicht eurer Seite hinzufügen könnt). Das pass phrase muss mindestens 4 Zeichen lang sein und darf keine Sonderzeichen enthalten.

Nun kommt die CA-Datei, die die Antragsdaten sowie den öffentlichen Schlüssel zu unserem Private-Key enthält:

openssl req -x509 -new -nodes -extensions v3_ca -key ca-key.pem -days 1024 -out ca-root.pem -sha512

Benennt eure Dateien wieder mit einem beliebigen Namen. Ich nutze hier einige Argumente: -nodes (noDES) encrypted den Private-Key nicht, -x509 gibt das Certificate Data Management an, dass uns dann auch zu -extensions v3-ca führt. Hier wird eine Cryptographie erstellt und es werden Erweiterungen für policies verwendet.

Bei der Erstellung der CA werdet ihr nach einigen Details gefragt, die ihr angeben könnt um das Zertifikat eindeutig zu machen (oder aus Testzwecken einfach leer lassen).

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) []:

Wir brauchen jetzt noch einen Zertifikats-Key…

openssl genrsa -out zertifikat-key.pem 4096

…erstellen dann unsere CSR-Datei…

openssl req -new -key zertifikat-key.pem -out zertifikat.csr -sha512

…und signieren sie mit unserem eben erstellten Key.

openssl x509 -req -in zertifikat.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out zertifikat-pub.pem -days 365 -sha512

Gleiche Vorgehensweise wie zuvor beschrieben, pass phrase eingeben und bei belieben eure Details noch eintragen.

Wir sind fertig!

Jetzt bindet ihr das Zertifikat nur noch in euren Browser mit ein, in meinem Falle nutze ich den Firefox-Browser. Öffnet die Einstellungen und geht auf den linken Reiter “Datenschutz & Sicherheit”. Nun scrollt ihr ganz nach unten bis ihr die Option “Zertifikate” seht. Klickt auf den Button “Zertifikate anzeigen…”, dort öffnet sich ein neues Fenster in dem ihr nun euer erstelltes Zertifikat einpflegen könnt.

Der Browser muss nun geschlossen werden um die Veränderungen anzunehmen. Startet ihn neu und verbindet euch mit eurer Website. Nun müsstet ihr sehen können, dass ein https:// angezeigt wird.

Aleksander Arsenovic
Aleksander Arsenovic
Junior Consultant

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

SSL leicht gemacht – Zertifikat einbinden (Apache2)

This entry is part 1 of 5 in the series SSL leicht gemacht

In meinem letzten Blogpost habe ich über die Erstellung eines Keyfiles und eines CSR geschrieben. Im zweiten Teil meiner Serie SSL leicht gemacht zeige ich den nächsten Schritt und beschreibe die Einrichtung des Zertifikates mittels der Webserversoftware Apache.
Bestandsaufnahme:
nun sollten folgende Dateien vorhanden sein

  • selbst erstellt
    • CSR (in unserem Beispiel netways.de.csr)
    • Privatekey (netways.de.key)
  • von Zertifizierungsstelle erstellt und übermittelt
    • cert.cabundle
    • certificate.crt

Diese Zertifikatsdateien können jetzt auf dem Webserver eingerichtet werden.
Als nächstes werden die Zertifikatsdateien im korrekten Verzeichnis abgelegt. Hierzu eignet sich zum Beispiel /etc/apache2/ssl/netways.de/. Hier sollte die Zusammengehörigkeit der einzelnen Dateien noch einmal überprüft werden. Der CSR wird übrigens nicht mehr benötigt und kann gelöscht werden.
Apache kann im Moment noch nichts mit den Zertifikatsdateien anfangen und noch lernen “SSL zu sprechen”. Dazu wird ein SSL-VHost eingerichtet. Als Basis hierfür kann der abzusichernde VHost vorerst kopiert werden.

cp /etc/apache2/sites-available/001-netways.de.conf /etc/apache2/sites-available/001-netways.de-ssl.conf

Diese neue SSL-Config wird nun angepasst, damit der Apache nun weiß, was er zu tun hat.
Innerhalb der nun betreffenden VHost-Definition werden nun noch ein paar Paramater für SSL angegeben

SSLEngine on
 SSLCertificateKeyFile /etc/apache2/ssl/netways.de/netways.de.key
 SSLCertificateFile /etc/apache2/ssl/netways.de/certificate.crt
 SSLCertificateChainFile /etc/apache2/ssl/netways.de/cert.cabundle

Übrigens in der Einleitung der VHost-Definition (i. d. R. ganz oben in der neuen Datei) sollte der angegebene Port 80 auf 443 geändert werden.

<VirtualHost 123.456.789.012:80> auf <VirtualHost 123.456.789.012:443>

Abschließend wird der Apache noch um ein paar Funktionalitäten erweitert (SSL und der neue VHost wird aktiviert):

a2enmod ssl
a2ensite 001-netways.de-ssl.conf
service apache2 restart

Der VHost ist nun zusätzlich mit SSL abgesichert und in unserem Beispiel via https://netways.de und http://netways.de erreichbar. Ob alles geklappt hat, sieht man nun am erfolgreichen Verbindungsaufbau via HTTPS oder kann es zum Beispiel bei SSL Labs ausführlich prüfen lassen.
Die Namensgebung der Zertifikate unterscheidet sich von Zertifizierungsstelle zu Zertifizierungsstelle und kann auch mal mit .pem bezeichnet sein usw. Dies kann “ignoriert” werden und beliebig selbst in der Config auf die neuen Endungen angepasst werden. Auch eine Umbenennung der Dateien auf das eigene Schema ist ein möglicher Lösungsansatz.
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

SSL leicht gemacht – CSR und Keyfile erstellen und Zertifikat ordern

This entry is part 2 of 5 in the series SSL leicht gemacht

Oftmals kommt trotz der breiten Verfügbarkeit von Letsencrypt der Wunsch nach kostenpflichtigen Zertifikaten auf. Die Gründe sind vielfältig: längere Gültigkeit, Wildcard-, Multidomain- oder Extended-Validation (Grüne-Leiste) Zertifikate – all das bietet Letsencrypt leider nicht und deshalb ist der Bedarf nach solchen Zertifikaten noch immer vorhanden. In den nächsten Wochen werden wir immer wieder Blogposts zum Thema SSL erstellen, alle zu finden in unserer Serie “SSL leicht gemacht”
Zu aller Anfang wird ein CSR (Certificate Signing Request) und ein Keyfile (privater Schlüssel) benötigt. Aus Sicherheitsgründen empfehlen wir prinzipiell die Erstellung gleich auf dem Zielsystem des Zertifikates vorzunehmen, so müssen die Daten nicht umgezogen werden und bleiben nicht “zufällig” irgendwo liegen.
Los geht’s mit dem Kommando

openssl req -new -nodes -keyout netways.de.key -out netways.de.csr -newkey rsa:4096

Dadurch wird im aktuellen Verzeichnis ein Privatekey mit einer Schlüssellänge von 4096 Bit (default 2048) angelegt. Der folgende Wizard sammelt nun noch die Daten für das CSR ein.
Hier wird nach dem Land, dem Staat, der Stadt, der Firma, der Abteilung, der zu sichernden Domain und der Kontaktmailadresse gefragt. Eingaben können auch leergelassen werden und mit der Eingabetaste übersprungen werden (ACHTUNG: Defaultwerte (sofern vorhanden) aus den eckigen Klammern werden übernommen).
Zur Kontrolle kann das CSR noch mit dem Kommando

openssl req -in netways.de.csr -noout -text

überprüft werden. Übrigens gibt es bei Umlauten (wie so oft) Probleme. Wir vermeiden diese gern durch die Verwendung englischer Städtenamen wie im aktuellen Beispiel zu sehen.
Abschließend kontrollieren wir das Keyfile noch (zumindest, ob es so in der Art aussieht).

Fertig, nun geht man zur Bestellung des Zertifikates über. Hierzu kann man auf jeden beliebigen Zertifikatshändler zurückgreifen. Wegen anhaltender “Unstimmigkeiten” bei Google und Symantec empfehle ich persönlich (bei der Neubestellung) auf Produkte von Comodo zurückzugreifen. Die Comodo-Zertifikate sind preislich im Mittelfeld und die Akzeptanz der Zertifikate ist hoch. Für die Bestellung wird nur der CSR benötigt. Das Keyfile sollte keinesfalls an irgendjemanden weitergegeben werden und auf dem Server verbleiben.
Bei der Bestellung werden nochmal alle möglichen Daten, gewünschte Laufzeit usw. abgefragt. Unter anderem auch die Mailadresse. Die Auswahlmöglichkeiten dieser ist oftmals beschränkt. Die ausgewählte Mailadresse muss zwingend verfügbar sein, um die Validierung via Mail abzuschließen und ein Zertifikat zu erhalten. Sofern alles geklappt hat, bekommt man später in der Regel per Mail das Zertifikat und ggf. das CA-Bundle zugeschickt.
Wie das alles nun zusammen eingerichtet wird, schreibe ich im Artikel Zertifikat einbinden (Apache2).
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Icinga 2 Best Practice Teil 5: Autosign von Zertifikatsanfragen in verteilten Umgebungen

This entry is part 5 of 7 in the series Icinga 2 Best Practice

Ein jeder kennt das Problem, im Unternehmensnetz gibt es unterschiedliche netzwerkbezogene Sicherheitszonen, die mittels Perimeter voneinander getrennt sind. Für das Monitoring bedeutet dies im Idealfall, man stellt in jeder dieser Zonen einen Icinga-Satelliten bereit, der die von ihm ermittelten Ergebnisse an eine zentrale Instanz weiter meldet, den Icinga-Master. Damit ist gewährleistet, was Firewall-Admins berechtigterweise verlangen, lediglich Punkt-zu-Punkt-Verbindungen zu erlauben. Auch die Richtung des Verbindungsaufbaus ist mit Icinga 2 wählbar.
Setzt man zusätzlich auch Icinga 2 in der Ausprägung Agent ein, benötigt dieser ein signiertes Zertifikat um mit seinem jeweiligen Satelliten oder direkt mit dem Master zu kommunizieren. Im letzten Fall entstehen hieraus keine Probleme. In der Regel wird die CA, in einer Umgebung mit mehreren Satelliten auf dem Master betrieben. Bei lediglich einem Satelliten könnte die CA auch auf genau diesem Satelliten laufen, was jedoch Sicherheitsbedenken hervorruft. Ein Zertifikat aus einer niedrigen Sicherheitszone könnte verwendet werden, um mit einer höheren zu kommunizieren. Gleiches gilt natürlich auch bei der Benutzung lediglich einer CA, aber die Netzwerksicherheit soll ja dieses Risiko Minimieren.
Bleibt das Problem auf einem neuinstallierten Agenten mittels Autosigning ein beglaubigtes Zertifikat zu erhalten. Hier kann eine eigene CA auf jedem Satelliten Abhilfe schaffen. Der jeweilige Agent benötigt nun nur eine Verbindung zu seinem Satelliten um einen Request zu senden und keine Kommunikation zum Master. Wie wird nun dieses genau bewerkstelligt?

  • Erstellen einer CA auf dem Satelliten
  • Der Satellit bekommt ein Zertifikat signiert von seiner eigene CA
  • Der Satellit benötigt sein eigenes RootCA-Zertifikat und das vom Master
  • Der Master bekommt umgekehrt ebenfalls das RootCA vom Satelliten
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Exchange SSL Error

Wir haben unsere interne Windows CA von SHA1 auf SHA256 umgestellt und alle Zertifikate erneuert. Soweit so gut, doch nach einem Neustart der Exchange Server konnten sich unsere Mailclients nicht mehr mit dem Exchange verbinden und OWA gab nach dem Login nur eine weiße Seite zurück.
In der Ereignisanzeige fanden wir folgenden Fehler:
An error occurred while using SSL configuration for endpoint
0.0.0.0:444. The error status code is contained within the returned
data.
Um dieses Problem zu lösen sind wir wie folgt vorgegangen:
netsh http show sslcert
IP:port                      : 0.0.0.0:444
Certificate Hash             :
Application ID               : {4dc34hge........}
Certificate Store Name       : (null)
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Dieser Befehl zeigt die gebundenen Zertifikate an. Das relevante hierbei ist das Zertifikat für 0.0.0.0:444.
Dieses müssen wir nun löschen und neu zuordnen. Die Ausgabe kopieren wir uns vorher in ein Textfile.
netsh http delete sslcert ipport=0.0.0.0:444
iisreset

Nun brauchen wir den Hash aus unserem neuen Zertifikat und die Application ID, die wir uns in das Textfile
kopiert haben.
netsh http add sslcert ipport=0.0.0.0:444 certhash=XXXXXX  appid=”{XXXXXXX}”
iisreset

Martin Schuster
Martin Schuster
Senior Systems Engineer

Martin gehört zu den Urgesteinen bei NETWAYS. Wenn keiner mehr weiss, warum irgendwas so ist, wie es ist, dann wird Martin gefragt. Er hat es dann eigentlich immer mal schon vor Jahren gesehen und kann Abhilfe schaffen :). Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren oder zieht einfach um und fängt von vorne...