• Active Directory
    • AD Consulting
    • AD Design
      • Domain Name festlegen
      • Domain Struktur einrichten
      • Forest Struktur definieren
    • AD Management
    • AD Automation
      • Dynamic Access Control (DAC)
    • AD Federation Services
      • ADFS Betrieb
      • ADFS und Office365
      • ADFS und Cisco Unified Communications Manager
      • SAML und ADFS 2.0
  • Azure / M365
    • Azure AD
    • Microsoft 365 (O365)
  • Migration
    • Active Directory Migration
    • Exchange Migration
    • File Server Migration
    • Lotus Notes Migration
    • Novell Migration
  • Wissen
    • Alle Beiträge
    • Administration
    • PowerShell
    • Migration
    • Exchange
    • Tools
  • Kontakt
    • Wir über uns
    • Kontakt
  • EN
info@firstattribute.com
by FirstAttribute
Active Directory FAQActive Directory FAQ
  • Active Directory
    • AD Consulting
    • AD Design
      • Domain Name festlegen
      • Domain Struktur einrichten
      • Forest Struktur definieren
    • AD Management
    • AD Automation
      • Dynamic Access Control (DAC)
    • AD Federation Services
      • ADFS Betrieb
      • ADFS und Office365
      • ADFS und Cisco Unified Communications Manager
      • SAML und ADFS 2.0
  • Azure / M365
    • Azure AD
    • Microsoft 365 (O365)
  • Migration
    • Active Directory Migration
    • Exchange Migration
    • File Server Migration
    • Lotus Notes Migration
    • Novell Migration
  • Wissen
    • Alle Beiträge
    • Administration
    • PowerShell
    • Migration
    • Exchange
    • Tools
  • Kontakt
    • Wir über uns
    • Kontakt
  • EN

Grundlagen zu Zertifikaten

Aug 27, 2014 (Letztes Update) | Posted by Jens Fiedler Administration, KnowHow |

 

Die Verwendung von Zertifikaten zur verschlüsselten Kommunikation und Signierung von Daten wie E-Mails steht bei vielen Unternehmen ganz oben auf der Wunschliste. Dafür ist es aber in erstaunlich vielen Fällen noch nicht umgesetzt.

Ich möchte daher einen kurzen Überblick zum technischen Verfahren bieten das beim Einsatz von Zertifikaten zum Tragen kommt. Als Beispiel soll der gesicherte, verschlüsselte Zugriff auf eine Web-Site „webmail.company.de“ über das HTTPS-Protokoll dienen.

Das Zertifikatsverfahren basiert auf drei Säulen:

  • Eine allgemein anerkannte und vertrauenswürdige Autorität: Die zentrale Zertifikatsausgabestelle
  • Dem Private-Public-Key Verschlüsselungsverfahren
  • Dem Zertifikat, was die Eigenschaft eines Subjektes oder Objektes bestätigt

 

Gesicherter und verschlüsselter Zugriff auf eine Web-Site

Zusammenspiel der drei Säulen am Beispiel

Um die Grundlagen zu Zertifikaten besser zu verstehen, wollen wir eine WebMail-Site für unsere Mitarbeiter im Internet mit verschlüsselter Kommunikation zur Verfügung stellen. Ein öffentlicher DNS-Eintrag für die Adresse webmail.company.de ist registriert und jetzt fehlt uns noch ein Zertifikat was die Echtheit dieser Adresse bestätigt. An diesem Punkt kommt die zentrale Zertifikatsausgabestelle ins Spiel. Denn bei dieser Stelle lassen wir unser ein Zertifikat für unseren Web-Server ausstellen. Bekanntere Stammzertifizierungsstellen sind zum Beispiel GlobalSign, VeriSign oder Thawte.

Und schon sind wir bei der zweiten Säule des Zertifikatsverfahrens: Der Private-Public-Key Verschlüsselung. Da das Verfahren hier nur Mittel zum Zweck ist will ich nur kurz seine besondere Eignung für die Zertifikate erläutern. Es gibt darüber hinaus mehrere Bücher die sich ausschließlich mit diesem Verschlüsselungsverfahren beschäftigen da es eine zentrale Stellung in der Kryptografie einnimmt. Wie der Name „Private-Public-Key“ schon sagt gibt es hier nicht einen einzelnen Schlüssen für die Verschlüsselung von Nachrichten sondern derer zwei. Ein Schlüssel ist privat und geheim, er wird niemals nach außen gegeben. Der andere Schlüssel ist dagegen sozusagen der extrovertierte Zwilling, er ist geradezu dafür gemacht unter die Menge geschleudert zu werden. Und warum kann man so sorglos mit dem öffentlichen Schlüssel umgehen? Weil er nichts über den privaten Schlüssel verraten wird.

Das führt zu zwei ganz besonderen Möglichkeiten:

  1. Nachrichten die mit dem öffentlichen Schlüssel verschlüsselt wurden können nur vom privaten Schlüssel wieder entschlüsselt werden. Das bedeutet nur der Empfänger kann die für ihn verschlüsselte Nachricht lesen.
  2. Nachrichten die mit dem privaten Schlüssel verschlüsselt wurden können nur vom öffentlichen Schlüssel wieder entschlüsselt werden. Da man davon ausgehen kann dass der private Schlüssel nur an einer Stelle existiert kann der Absender der Nachricht sicher bestätigt werden. Damit kann ein Signaturverfahren aufgebaut werden.

Die dritte Säule, die mit dem Zertifikat zu bestätigende Eigenschaft, ist in unserem Beispiel die DNS-Adresse „webmail.company.de“ für unsere WebMail-Site.

 

Das Zertifizierungsverfahren – so werden alle notwendigen Bestandteile eingesetzt

  1. Für unseren Web-Server wird ein Zertifikatsantrag erzeugt. Mit diesem Zertifikatsantrag wird das Private-Public-Key Paar für unsere WebMail-Site erzeugt. Der private Schlüssel verbleibt bei uns. Das Antragsformular enthält neben dem öffentlichen Schlüssel unsere DNS Web-Adresse und einige weitere Informationen wie zum Beispiel den Standort unseres Servers.
     
  2. Der fertig ausgefüllte Zertifikatsantrag wird an die Stammzertifizierungsstelle unserer Wahl geschickt um für uns ein Zertifikat auszustellen.
     
  3. Die Stammzertifizierungsstelle erzeugt mit unseren Informationen ein Zertifikat und signiert es mit ihrem privaten Schlüssel. Außerdem enthält das Zertifikat noch eine Gültigkeitsdauer und Informationen wo das Stammzertifikat sowie die Zertifikatssperrliste (Certificate Revocation List) zu finden ist.
     
  4. Das fertige Zertifikat kommt zu uns zurück und wir spielen es auf unseren Web-Server ein. Jetzt ist die verschlüsselte Kommunikation mit unserer WebMail-Site möglich.

Wir der aufmerksame Leser gemerkt hat wurde in dem ganzen Prozess niemals der private Schlüssel nach außen gegeben. Das ist auch essentiell denn das ganze Verfahren beruht auf der Vertrauenswürdigkeit des privaten Schlüssels. Wenn sein Geheimnis nicht mehr sicher ist kann auch nicht mehr sichergestellt werden das Nachrichten nur von dem für sie bestimmten Empfänger entschlüsselt werden können bzw. von dem bekannten Absender signiert wurden.

Der Aufbau eines verschlüsselten Kommunikationskanals mit unserer Site webmail.company.de erfolgt nun nach einem festgelegten Zertifikatsprüfung- und Schlüsselaustauschverfahren.

Aufbau einer HTTPS-Verbindung

1. Echtheit des Zertifikats prüfen

  1. Der Internet-Browser macht eine erste Anfrage zu unserem Web-Server auf der Adresse: https://webmail.company.de. Mittels https geben wir an das wir eine verschlüsselte Kommunikation zum Web-Server aufbauen werden.
     
  2. Der Web-Server übermittelt dem Internet-Browser unser Zertifikat was die Echtheit der Adresse webmail.company.de bestätigt.
     
  3. Der Internet-Browser prüft nun die Echtheit unseres Zertifikates. Dazu werden alle ausstellenden Zertifikate in der Zertifikatskette bis zum Stammzertifikat ermittelt. In unserem Fall ist das nur eins. Üblicherweise werden Zertifikate aber von untergeordneten Zertifikatsausgabestellen erstellt und nicht von der Stammzertifizierungsstelle. Die Zertifikate der Ausgabestellen und der Stammzertifizierungsstelle sind meistens im CryptoAPI-Cache des Rechners enthalten und können vom Internet-Browser abgerufen werden. Ist das nicht der Fall können sie über die Authority Information Access (AIA) URL, welche im Web-Server Zertifikat hinterlegt ist, nachgeladen werden.
     
  4. Wenn alle Zertifikate der Kette ermittelt sind wird bei jedem Zertifikat geprüft ob es sich noch im Gültigkeitszeitraum befindet.
     
  5. Danach wird für jedes Zertifikat die Certificate Revocation List (CRL) abgerufen. Die URL dafür ist ebenfalls im Zertifikat hinterlegt. Damit wird geprüft ob unser Web-Server Zertifikat gesperrt wurde. Ab Windows Server 2008 wird auch das Online Certificate Status Protocol (OCSP) unterstützt. Mit einem OCSP-Responder kann der Zertifikatsstatus zeitnah abgefragt werden denn eine CRL wird nur in einem bestimmten Zeitraum aktualisiert.
     
  6. Stimmt auch noch die Adresse im Zertifikat mit der aufgerufenen Web-Adresse sowie der Verwendungszweck, in unserem Fall „Web-Server“, und werden die Informationen durch die Zertifikatssignatur bestätigt wird das Zertifikat als gültig akzeptiert und der verschlüsselte Kanal kann etabliert werden.

 

2. Austausch der Schlüssel:

  1. Der Internet-Browser erzeugt einen symmetrischen Schlüssel mit dem für die Dauer der Sitzung der Datenverkehr zwischen Web-Server und Internet-Browser verschlüsselt wird. Das Private-Public-Key Verfahren ist sehr rechenintensiv, daher wird es nur für den Austausch des eigentlichen Datenschlüssels verwendet. Der Datenschlüssel ist ein symmetrischer Schlüssel, d.h. er wird für die Verschlüsselung als auch für die Entschlüsselung verwendet was wesentlich weniger Rechenleistung benötigt. Da er nur für die aktuelle Sitzung verwendet wird ist er sehr kurzlebig und die Gefahr dass er ausspioniert wird gering.
     
  2. Der Internet-Browser verschlüsselt den Datenschlüssel mit dem öffentlichen Schlüssel unseres Web-Servers aus dem Zertifikat. Dieses Paket wird dann an den Web-Server zurückgeschickt.
     
  3. Nur unser Web-Server ist in der Lage mit dem passenden privaten Zertifikatschlüssel den Datenschlüssel wieder zu entschlüsseln. Alle weiter Kommunikation mit dem Internet-Browser erfolgt dann mit dem ausgetauschten Datenschlüssel.
     
  4. Da sich der Internet-Browser sicher sein kann das nur der Web-Server den Datenschlüssel verwendet ist die Kommunikation zum Web-Server nun gesichert.

 

Ich hoffe Ihr habe nun einen ersten, vielleicht etwas ausfühtlicheren Einblick in die Grundlagen zu Zertifikaten erhalten. Anmerkungen und Ergänzungen sind natürlich jederzeit willkommen. Bitte einfach einen Kommentar hinterlassen.

 

Artikel weiterempfehlen:
  • teilen
  • tweeten
  • sharen
  • xingen
  • mailen
Artikel erstellt am: 02.08.2013
Tags: AIAAuthority Information AccessCACertificateCertificate AuthorityCertificate Revocation ListCRLOCSPOnline Certificate Status ProtocolRoot CertificateSSLStammzertifikatZertifikate
3

Leave a Reply

<p>Danke für Ihre Anregungen, Fragen und Hinweise.<br/>Infos zum <a href="https://www.active-directory-faq.dekontakt/">Datenschutz</a></p>
Cancel Reply

FirstWare IDM-Portal im Test: IT-Administrator 08-2022

 

ADFAQ-FirstAttribute

Wer schreibt ?

Team der FirstAttribute AG

Consultants und Entwickler der FirstAttribute arbeiten seit mehr als 20 Jahren in IAM- und Cloud-Transition-Projekten.
Zusammen verfügen Sie über einen wertvollen Erfahrungsschatz im Bereich Active Directory und Azure AD und teilen diesen auf Active Directory FAQ.

Neueste Artikel

  • 8 Tipps für mehr Sicherheit in Active Directory und Backups von AD
  • Azure AD Custom Security Attributes ermöglichen flexible Berechtigungsstrukturen
  • Dateiberechtigungen in MS Teams und SharePoint Online verwalten – So funktioniert es
  • AD-Gruppen in Microsoft Teams verwenden – Dynamische Gruppen in der Praxis
  • Verbindung zwischen Microsoft 365 und SharePoint Online zu Azure AD

Unsere IAM-Lösungen

Ihre IAM-Lösung: FirstWare IDM-Portal

 

my-IAM für Cloud Identity Management in Microsoft Teams

Kontakt aufnehmen

Sie haben eine Frage oder Anmerkung? Schicken Sie uns schnell eine Nachricht.

Nachricht senden
Jetzt AD Tasks vereinfachen und delegieren: FirstWare IDM-Portal

Folgen Sie uns

Kontakt

  • FirstAttribute AG
  • Am Büchele 18, 86928 Hofstetten, Germany
  • +49 89 215 442 400
  • https://www.firstattribute.com

Schlagwörter

.Net ACL Active Directory AD LDS AD Objekt Azure AD Berechtigung Cloud cmdlets Delegation Domain Controller dynamicgroup dynamische Gruppen Exchange Exchange-Ordner Exchange-Postfach Exchange Migration Federation FirstWare Get-Mailbox Global Catalog Group Policy Gruppen Gruppenmitgliedschaft IDM-Portal LDAP m365 Microsoft Azure Migration New-ADUser Novell NTFS Office 365 PowerShell QMM QMM AD QMM Exchange Quest Migration Manager Schema Set-ADUser SID SID History Update Windows 10 Windows Server 2012 R2

Neueste Kommentare

  • activedirectoryfaq.com sharepoint login - infoslist bei Windows 365 und Azure AD verstehen in Theorie und Praxis
  • Domäne Letzte Anmeldung - ObenGesichert.com bei LastLogon vs. LastLogonTimestamp
  • Teams Code Zur Anmeldung - ObenGesichert.com bei Authentifizierung für MS Teams in hybriden Netzwerken
Login
Impressum
Datenschutzerklärung

© 2023 · Active-Directory-FAQ by firstattribute.com

Prev Next