Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was ist .NET?
6 Installation
7 Die Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint Foundation und SharePoint Server
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Windows Server 2012 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2012 R2

Windows Server 2012 R2
Rheinwerk Computing
1392 S., 4., aktualisierte Auflage 2014, geb.
59,90 Euro, ISBN 978-3-8362-2013-2
Pfeil 12 Active Directory-Zertifikatdienste
Pfeil 12.1 Einige Anwendungsszenarien
Pfeil 12.1.1 Internet-Authentifizierung und Verschlüsselung
Pfeil 12.1.2 Sichere E-Mail
Pfeil 12.1.3 Codesignatur
Pfeil 12.1.4 IP-Verschlüsselung
Pfeil 12.1.5 Anmeldung mit Smartcard
Pfeil 12.1.6 Wireless Authentification (802.1X)
Pfeil 12.1.7 Fazit
Pfeil 12.2 Zertifikatdienste installieren und Migration (einstufige Architektur)
Pfeil 12.3 Zertifikate aus Sicht des Clients
Pfeil 12.4 Zertifizierungspfad
Pfeil 12.5 Zertifikatvorlagen
Pfeil 12.6 Weboberfläche
Pfeil 12.7 Mehrstufige Architekturen
Pfeil 12.7.1 Rollen
Pfeil 12.7.2 Architekturen
Pfeil 12.8 Autoenrollment und automatische Zertifikatanforderung
Pfeil 12.8.1 Automatische Zertifikatanforderung
Pfeil 12.8.2 Autoenrollment
Pfeil 12.9 Zertifikate für Websites
Pfeil 12.10 Zertifikatsperrlisten
Pfeil 12.10.1 Funktionsweise – ganz grob
Pfeil 12.10.2 Sperrlisteneinträge
Pfeil 12.10.3 Gültigkeit einer Sperrliste
Pfeil 12.10.4 Zertifikatgültigkeit überprüfen
Pfeil 12.10.5 Der Cache
Pfeil 12.10.6 ISA Server zum Veröffentlichen des Speicherortes verwenden
Pfeil 12.11 Das Online Certificate Status Protocol (OCSP)
Pfeil 12.11.1 Konfiguration des Online-Responders
Pfeil 12.11.2 Anpassung der Zertifizierungsstelle
Pfeil 12.11.3 Testen
Pfeil 12.11.4 ISA Server-Veröffentlichung
Pfeil 12.12 Zweistufige Architektur implementieren
Pfeil 12.12.1 Offline-CA installieren und konfigurieren
Pfeil 12.12.2 Zertifikat und Sperrliste dem Unternehmenszertifikatserver und dem Active Directory hinzufügen
Pfeil 12.12.3 Unternehmens-CA installieren
Pfeil 12.12.4 Sperrlisten-Verteilungspunkt mit ISA Server veröffentlichen
Pfeil 12.13 Zertifikate und Windows Mobile
Pfeil 12.13.1 Pocket PC und Pocket PC Phone Edition
Pfeil 12.13.2 Smartphone
Pfeil 12.14 Zertifikate und das iPhone

12Active Directory-Zertifikatdienste Zur nächsten Überschrift

Ob versäumte Gelübd’ ihn erzürneten, ob Hekatomben:
Wenn vielleicht der Lämmer Gedüft und erlesener Ziegen
Er zum Opfer begehrt, von uns die Plage zu wenden.
Also redete jener, und setzte sich. Wieder erhub sich
Kalchas der Thestoride, der weiseste Vogelschauer

Die zu Zeiten von Windows Server 2003 Zertifikatsdienste genannte Funktionalität ist jetzt in die Active Directory-Familie aufgenommen worden und heißt Active Directory-Zertifikatdienste, in englischen Versionen Active Directory Certificate Server (AD CS).

Diese namensmäßige Anpassung erscheint mir durchaus sinnvoll zu sein, da nun alles, was im weitesten Sinne mit Authentifizierung zu tun hat, beim Active Directory angesiedelt ist.

AD CS

Aus Gründen der besseren Lesbarkeit verwende ich im weiteren Verlauf häufig die englische Abkürzung AD CS, anstatt jedes Mal lang und breit »Active Directory-Zertifikatdienste« zu schreiben.


Rheinwerk Computing - Zum Seitenanfang

12.1 Einige Anwendungsszenarien Zur nächsten ÜberschriftZur vorigen Überschrift

Wenn Sie sich nicht ganz sicher sind, ob Sie in Ihrem Unternehmen bzw. in Ihrer Organisation ein Zertifikatswesen einführen sollen, möchte ich Ihnen zunächst einige Anwendungsszenarien nennen. Sie werden höchstwahrscheinlich feststellen, dass Sie um AD CS – zumindest mittelfristig – nicht herumkommen werden.


Rheinwerk Computing - Zum Seitenanfang

12.1.1 Internet-Authentifizierung und Verschlüsselung Zur nächsten ÜberschriftZur vorigen Überschrift

Der bekannteste Anwendungsfall ist die Authentifizierung eines Servers im Internet. Wenn ein Benutzer einen Server im Internet anwählt, d. h., den Namen im Browser angibt, möchte er sicher sein, dass der erreichte Server auch tatsächlich der ist, als der er sich ausgibt. Etwas »praktischer« formuliert: Wenn der Benutzer www.dasIstMeineBank.de anwählt, möchte er sicher sein, dass nicht irgendein »Hacker« (bzw. Phisher) den DNS-Eintrag gekapert und auf seinen Server umgeleitet hat und sich nun eine gefälschte Website der Kombination aus Kontonummer, PIN und TAN bemächtigt.

Greift ein Benutzer auf https://www.dasIstMeineBank.de zu und stimmt irgendetwas nicht mit dem Zertifikat, gibt es eine entsprechende Warnung im Browser. Eine Warnung kann es aus drei Gründen geben:

  • Das Zertifikat ist zeitlich nicht gültig.
  • Das Zertifikat passt nicht zum angewählten Namen. Wenn der Benutzer https://www.dasIstMeineBank.de angewählt hat, das Zertifikat aber für https://www.nichtMeineBank.com ausgestellt ist, gibt es eine Warnung.
  • Das Zertifikat ist von einer Zertifizierungsstelle ausgestellt worden, der nicht vertraut wird – bzw. technischer gesprochen: deren Stammzertifikat nicht im Zertifikatsspeicher des PCs vorhanden ist.

Wenn ein Benutzer über einen sicheren Kanal (https://) eine Verbindung zu einer Website aufbaut, deren Zertifikat nicht in Ordnung ist, wird er vom Internet Explorer-Browser gewarnt. Abbildung 12.1 zeigt die Warnung des Internet Explorer 7. Auch die Vorgängerversionen haben bei Zertifikatsfehlern gewarnt, wenn auch nicht so deutlich. Solche Meldungen machen natürlich nur Sinn, wenn die Anwender daraus auch die richtigen Schlüsse ziehen und sie nicht einfach nur wegklicken.

Abbildung

Abbildung 12.1 Der Internet Explorer warnt, wenn das Zertifikat einer Website nicht in Ordnung ist. Die Benutzer müssen lernen, dass eine solche Meldung ernst genommen werden muss.

Beim Zugriff auf Webserver dienen die Zertifikate weiterhin zur Verschlüsselung des Datenstroms. Abbildung 12.2 zeigt, wie HTTP mit SSL-Verschlüsselung funktioniert:

  1. Zunächst baut der Client eine Verbindung zum Webserver auf. Da er eine sichere Verbindung aufbauen möchte, greift er auf den Port für HTTP über SSL zu. Dies ist im Allgemeinen Port 443.
  2. Der Server »antwortet« mit einer Kopie seines öffentlichen Zertifikatsschlüssels.
  3. Im nächsten Schritt überprüft der Client, ob dieser Zertifikatsschlüssel von einem Herausgeber (d. h. einer Stammzertifizierungsstelle) stammt, dem er vertraut. Diese Prüfung endet nur dann positiv, wenn das Zertifikat der Stammzertifizierungsstelle im Zertifikatsspeicher für »vertauenswürdige Stammzertifizierungsstellen« des Clients hinterlegt ist.

    Die Logik dahinter ist also folgende: »Ich vertraue der Stammzertifizierungsstelle, also traue ich auch allen Zertifikaten, die diese nachweisbar herausgegeben hat.« Der Nachweis, dass ein Zertifikat wirklich von einer Stammzertifizierungsstelle kommt, funktioniert über kryptografische Methoden.

    Abbildung

    Abbildung 12.2 Die Funktionsweise von HTTP über SSL (HTTPS)

  4. Nun handeln Client und Server einen Sitzungsschlüssel aus. Da der Client über den öffentlichen Schlüssel des Servers verfügt, kann er den Sitzungsschlüssel so verschlüsseln, dass dieser nur vom Server mit dessen privatem Schlüssel decodiert werden kann.
  5. Mit dem (übrigens symmetrischen) Sitzungsschlüssel können nun die Daten verschlüsselt werden, die ausgetauscht werden sollen.

Mit Zertifikaten kann übrigens nicht nur der Server gegenüber dem Benutzer seine Identität beweisen, es geht auch umgekehrt. Mit einem Benutzerzertifikat kann sich der Anwender am Webserver authentifizieren, ohne dass er seinen Benutzernamen und sein Kennwort eingeben muss.


Rheinwerk Computing - Zum Seitenanfang

12.1.2 Sichere E-Mail Zur nächsten ÜberschriftZur vorigen Überschrift

Es ist kein Geheimnis mehr, dass Mails unverschlüsselt durch das Internet reisen, was insbesondere diese beiden Probleme nach sich zieht: Jemand, der sich an irgendeiner Stelle des Transportwegs Zugriff auf die Mails verschaffen kann, ist in der Lage

  • die Mails zu lesen und/oder
  • die Mails zu manipulieren.

Das »Sich-Zugriff-Verschaffen« ist zwar nicht ganz trivial, wo ein Interesse ist, ist aber auch ein Weg. Abhilfe schafft das Signieren und Verschlüsseln von E-Mails. Das Signieren schützt eine Nachricht vor Manipulation, und das Verschlüsseln verhindert einen unautorisierten Zugriff.

Wenn zwei Personen geheime Mails austauschen möchten, könnten sie einen Geheimcode vereinbaren, mit dem die Inhalte codiert werden. Beide Personen kennen den Schlüssel, und dieser wird sowohl zum Verschlüsseln als auch zum Entschlüsseln verwendet. So weit ist alles gut.

Das Verfahren wird dann ausgesprochen »unhandlich«, wenn potenziell jeder Mitarbeiter einer Firma mit jedem anderen kommunizieren möchte. Jeder müsste einen geheimen Schlüssel mit jedem anderen Mitarbeiter vereinbaren, um Nachrichten auszutauschen. Bei 1.000 Mitarbeitern ergibt das die bescheidene Anzahl von 1.0002 = 1.000.000 Schlüsseln. Wenn in Zukunft alle 8.000.000.000 Einwohner der Welt miteinander in E-Mail-Kontakt treten können, müssten in der Endausbaustufe insgesamt 64.000.000.000.000.000.000 Schlüssel vorhanden sein. Die symmetrische Verschlüsselung (beim Verschlüsseln und Entschlüsseln wird derselbe Schlüssel verwendet) führt also in eine Sackgasse. Aus diesem Grund wird für die E-Mail-Verschlüsselung und -Signatur ein asymmetrisches Verfahren verwendet, das – Sie ahnen es bereits – auf Zertifikaten basiert.

Nachfolgend stelle ich das Verschlüsseln und das Signieren von E-Mails kurz vor. Wenn Sie die Abläufe verstanden haben, hilft Ihnen das, auch alle anderen asymmetrischen Vorgänge zu begreifen.

Verschlüsseln

Für die Verschlüsselung von Mails wird ein PKI-basiertes Verfahren verwendet. PKI ist die Abkürzung für Public Key Infrastructure, d. h., es wird ein Verfahren verwendet, bei dem jeder Benutzer über ein Schlüsselpaar verfügt, das aus einem privaten und einem öffentlichen Schlüssel besteht. In einer Exchange-Umgebung werden die Schlüssel im Active Directory gespeichert.

Das Verfahren ist stark vereinfacht in Abbildung 12.3 dargestellt:

  • Der Sender fordert den öffentlichen Schlüssel des Empfängers an. Diesen erhält er beispielsweise aus dem Active Directory. Im Active Directory wird der Schlüssel übrigens in den globalen Katalog repliziert, sodass auch in sehr großen Organisationen ein schneller Zugriff gewährleistet ist.
  • Der Sender verschlüsselt die Mail mit dem öffentlichen Schlüssel des Empfängers.
  • Die verschlüsselte Mail wird übertragen.
  • Der Empfänger kann mit seinem privaten Schlüssel die mit dem zugehörigen öffentlichen Schlüssel verschlüsselte Mail entschlüsseln.

In der Praxis

Leider ist die asymmetrische Verschlüsselung kein besonders performantes Verfahren. Aus diesem Grund wird das oben beschriebene Verfahren in der Praxis leicht abgewandelt: Der Sender erzeugt einen Schlüssel für eine symmetrische Verschlüsselung, mit dem dann der Mail-Inhalt und gegebenenfalls Anhänge codiert werden. Dieser symmetrische Schlüssel wird mit dem öffentlichen Schlüssel des Empfängers asymmetrisch verschlüsselt und ebenfalls in der Mail mitgesendet. Der Empfänger decodiert nun zunächst den vom Sender erzeugten symmetrischen Schlüssel mit seinem privaten Schlüssel. Daraufhin entschlüsselt er mit dem symmetrischen Schlüssel den Mail-Inhalt und die Anhänge. (Eigentlich ist es ganz einfach, man muss es aber vermutlich zweimal lesen.)

Abbildung

Abbildung 12.3 Asymmetrische Verschlüsselung von E-Mails

Signieren

Das im vorigen Abschnitt besprochene Verfahren bezog sich auf die Verschlüsselung der auszutauschenden Informationen. In vielen Fällen ist es ebenfalls wichtig, dass die Echtheit einer Mail überprüft werden kann. Auch diese Aufgabenstellung kann mit einer Public Key Infrastructure realisiert werden.

Die Vorgehensweise ist in Abbildung 12.4 vereinfacht dargestellt:

  • Der Sender ermittelt einen Hash-Wert über die Mailinhalte nebst eventuellen Anlagen. Das resultierende »Datenpaket« wird übrigens als Digest bezeichnet. Dieser Digest wird mit der Mail übermittelt.
  • Wenn der Empfänger die Echtheit der E-Mail überprüfen will, um sicherzustellen, dass diese nicht unautorisiert verändert worden ist, fordert er den öffentlichen Schlüssel des Senders an. Diesen erhält er beispielsweise aus dem Active Directory.
  • Mit dem öffentlichen Schlüssel kann er testen, ob der übermittelte Digest zu dem Mailinhalt (gegebenenfalls nebst Anlagen) passt. Passt der Inhalt nicht, ist entweder an der Mail oder am Digest manipuliert worden.

In der Praxis

Die Überprüfung der Signatur wird in der Praxis etwas anders vorgenommen, als zuvor beschrieben. Zur Überprüfung von Mail-Signaturen benötigen Sie nicht den öffentlichen Schlüssel des Absenders, sondern es genügt, wenn Sie der ausgebenden Zertifizierungsstelle vertrauen – und dementsprechend deren Zertifikat installiert haben.

Abbildung

Abbildung 12.4 Signieren von E-Mails


Rheinwerk Computing - Zum Seitenanfang

12.1.3 Codesignatur Zur nächsten ÜberschriftZur vorigen Überschrift

Die Codesignatur ist in etwa mit dem Signieren von E-Mails zu vergleichen. Hierbei geht es darum, einwandfrei festzustellen, wer ein Stück Code entwickelt und in Umlauf gebracht hat. Ohne Codesignatur kann jeder »Dunkelmann« (oder natürlich auch eine »Dunkelfrau«) ein Stück Code entwickeln, in Umlauf bringen und behaupten, dass es von Microsoft sei – in Wahrheit ist es aber ein Trojaner, der E-Mail-Adressen oder Bankdaten ausspäht.

Bei der Codesignatur wird, genauso wie bei der E-Mail-Signatur, eine Prüfsumme gebildet, die mit dem privaten Schlüssel des Herausgebers signiert wird. Mit dem öffentlichen Schlüssel des Herausgebers (bzw. dem öffentlichen Schlüssel der Stammzertifizierungsstelle, die den Schlüssel des Herausgebers erzeugt hat) kann geprüft werden, ob die Prüfsumme nicht manipuliert worden ist. Dann kann noch kontrolliert werden, ob die zu installierende Datei zu der Prüfsumme passt. Ist irgendwo manipuliert worden, schlägt die Überprüfung fehl, und Sie wissen auf jeden Fall, dass etwas nicht in Ordnung ist.

Auch wenn Ihr Unternehmen nicht selbst Software entwickelt, könnten Sie mit der Codesignatur in Berührung kommen: Bei Office-Makros, die in fast jedem Unternehmen existieren, könnte die Signatur ebenfalls interessant sein. Makros werden definitiv für viele Aufgaben benötigt und sind ja auch durchaus sinnvoll und hilfreich. Bösartige Makros können aber genauso viel Schaden anrichten wie »normaler Code«.

Ein guter Kompromiss zwischen »niemals Makros ausführen« und »alle Makros ausführen« besteht darin, nur von einem vertrauenswürdigen Herausgeber signierte Makros zuzulassen. Dies ist in den Office-Applikationen konfigurierbar: Abbildung 12.5 zeigt den Konfigurationsdialog aus Word.

Abbildung

Abbildung 12.5 Die Ausführung von Makros kann auf solche Makros beschränkt werden, die von vertrauenswürdigen Herausgebern signiert worden sind.

Abbildung 12.6 zeigt, wie ein Makro im VBA-Editor von Word 2003 signiert wird. Der Menüpunkt Digitale Signatur führt zu einem Dialog, der die auf dem lokalen System zur Codesignierung zugelassenen Zertifikate zeigt. Das gewünschte Zertifikat kann ausgewählt werden – und das Makro ist signiert. In der heutigen Zeit, in der schädlicher bzw. bösartiger Code zu einem wirklich ernsten Problem geworden ist, spielt die Codesignatur bereits eine wichtige Rolle – und zwar mit steigender Tendenz. Wenn Sie eigenen Code, der eben auch aus Makros, Skripts oder dergleichen bestehen kann, signieren möchten, benötigen Sie entsprechende Zertifikate.

Abbildung

Abbildung 12.6 Konfigurieren der Signatur im VBA-Editor von Word 2003

Momentan sind wir als IT-Gesellschaft leider noch weit davon entfernt, dass jeder Code, der zum Einsatz kommen soll, signiert ist. Daher ist es nicht möglich, die Ausführung von nicht signiertem Code zu verbieten (bzw. die Ausführung von Code, der nicht mit einem Zertifikat einer vertrauenswürdigen Stamm-Zertifizierungsstelle signiert ist). In absehbarer Zeit dürfte diese Vision aber Realität werden, was ein großer Schritt in Richtung »sichere Systeme« wäre.


Rheinwerk Computing - Zum Seitenanfang

12.1.4 IP-Verschlüsselung Zur nächsten ÜberschriftZur vorigen Überschrift

Auch bei der IP-Kommunikation spielen Verschlüsselung und Signatur eine wichtige Rolle. Auch hier geht es darum, dass die Vertraulichkeit und die Integrität des Datenverkehrs geschützt werden müssen, sprich: Niemand soll die Kommunikation unbefugt mitlesen können, und niemand soll sie verfälschen können. Die IPSec-Technologie hilft bei der Umsetzung dieser Anforderungen, benötigt aber hierbei Zertifikate.


Rheinwerk Computing - Zum Seitenanfang

12.1.5 Anmeldung mit Smartcard Zur nächsten ÜberschriftZur vorigen Überschrift

Es ist bekannt, dass die klassische Anmeldung mit Benutzername und Passwort nicht höchsten Sicherheitsanforderungen genügt. Die Anmeldung mit Smartcards ist eine häufig verwendete Alternative. Hierbei handelt es sich um eine Zwei-Faktor-Authentifizierung, was bedeutet, dass für die Anmeldung zwei Voraussetzungen erfüllt sein müssen:

  • Haben: Man muss im Besitz der Smartcard bzw. des darauf gespeicherten Zertifikats sein.
  • Wissen: Man muss wissen, wie das zugehörige Kennwort heißt.

Ein bekanntes Beispiel für eine Zwei-Faktor-Authentifizierung ist das Abheben von Bargeld mittels EC-Karte: Sie müssen im Besitz der EC-Karte sein und diese in den Automaten schieben, und Sie müssen die PIN kennen. Wenn nicht beide Anforderungen erfüllt werden, bekommen Sie nur Geld, indem Sie den Automaten aufbrechen oder Ähnliches anstellen. Auf den Smartcards ist ein Benutzerzertifikat gespeichert, das prinzipiell neben der Anmeldung auch für andere Zwecke verwendet werden könnte.

EFS

Encrypting File System (EFS) bezeichnet die Fähigkeit des NTFS-Dateisystems, Dateien zu verschlüsseln. Wenn Sie in den Eigenschaften einer Datei oder eines Ordners die Verschlüsselung aktivieren, wird zunächst geprüft, ob ein passendes Zertifikat im Zertifikatsspeicher des Benutzers vorhanden ist. Ist dies nicht der Fall, wird eines generiert, wobei es zwei Varianten gibt:

  • Wenn im Active Directory eine Unternehmenszertifizierungsstelle vorhanden ist, wird dort automatisch (ohne dass der Benutzer es merkt) ein Zertifikat angefordert und installiert. (Das funktioniert, wenn die Zertifizierungsstelle Zertifikatsanforderungen automatisch verarbeitet.)
  • Ist keine Unternehmenszertifizierungsstelle vorhanden, wird auf der lokalen Maschine ein Zertifikat erzeugt.

Zertifikate werden also für EFS auf jeden Fall benötigt. Nun ist es einleuchtend, dass es unbedingt zu bevorzugen ist, dass die EFS-Zertifikate von einer zentralen Zertifizierungsstelle erzeugt werden, anstatt dass jeder Server für jeden Benutzer separate Zertifikate erzeugt; denken Sie vor allem an den Wiederherstellungs-Agenten.

Abbildung 12.7 zeigt ein für die Verwendung mit dem »verschlüsselnden Dateisystem« vorgesehenes Zertifikat im Zertifikatsspeicher des Benutzers.

Abbildung

Abbildung 12.7 Das Zertifikat für die Verschlüsselung von Dateien im Zertifikatsspeicher des Benutzers


Rheinwerk Computing - Zum Seitenanfang

12.1.6 Wireless Authentification (802.1X) Zur nächsten ÜberschriftZur vorigen Überschrift

Soll WLAN, also drahtloses Ethernet, genutzt werden, wird man – wenn man nicht gerade grob fahrlässig handeln möchte – eine Authentifizierung der Benutzer fordern. Erst korrekt authentifizierte Benutzer dürfen Zugriff auf das LAN bekommen.

Um eine optimale Authentifizierung zu gewährleisten, greift man auch bei diesem Anwendungsfall auf Zertifikate zurück, wobei ein entsprechendes Benutzerzertifikat im Zertifikatsspeicher des Anwenders auf dem drahtlos verbundenen Computer vorhanden sein muss.


Rheinwerk Computing - Zum Seitenanfang

12.1.7 FazitZur vorigen Überschrift

Das Verschlüsseln und Signieren von Informationen oder Kommunikation ist ein wesentlicher Bestandteil von modernen Informationssystemen. Die Anwendungsfälle sind außerordentlich vielfältig und basieren zumeist auf Zertifikaten, die nur sinnvoll zu nutzen sind, wenn sozusagen im Hintergrund eine PKI, eine Public Key Infrastructure, arbeitet.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern


  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Windows Server 2012 R2






Windows Server 2012 R2
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Office 365






 Office 365


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Linux-Server






 Linux-Server


Zum Rheinwerk-Shop: Vmware vSphere 5






 Vmware vSphere 5


Zum Rheinwerk-Shop: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo