# Zertifikate verstehen > Konzept: Wozu Zertifikate in OPC UA dienen, welche Speicher es gibt, wie Client und Server Zertifikate prüfen und was selbstsignierte von signierten unterscheidet. Client und Server weisen sich in OPC UA gegenseitig mit Zertifikaten aus. Diese Seite erklärt die Grundlagen, die für Client und Server gleichermaßen gelten. Wie Sie das eigene Zertifikat laden und speichern, beschreiben die Abschnitte [Anwendungszertifikat](https://www.traeger.de/docs/development/opcua/client/configuration#anwendungszertifikat) der Client-Konfiguration und [Anwendungszertifikat](https://www.traeger.de/docs/development/opcua/server/configuration#anwendungszertifikat) der Server-Konfiguration. Welche Einstellungen im Produktivbetrieb gelten, beschreiben die Seiten [Clients absichern](https://www.traeger.de/docs/development/opcua/security/client) und [Server absichern](https://www.traeger.de/docs/development/opcua/security/server). ## Zertifikate in OPC UA Zertifikate stellen die Authentizität, also die Echtheit, und die Integrität, also die Unverfälschtheit, von Client- und Serveranwendungen sicher. Sie dienen einer Client- und einer Serveranwendung damit als eine Art Personalausweis. Dieser Personalausweis liegt als Datei vor und muss irgendwo gespeichert werden. Wo die Zertifikate liegen, legen Sie selbst fest. Unter Windows lässt sich jedes Zertifikat direkt an das System übergeben, Windows verwaltet dann den Speicherort. Alternativ legen Sie benutzerdefinierte Speicherorte fest, also Verzeichnisse. Es gibt verschiedene Arten von Speicherorten für Zertifikate: - **Speicherort für Anwendungszertifikate**: Dieser Speicherort heißt auch Application Certificate Store. Er enthält ausschließlich die Zertifikate der Anwendungen, die ihn als Application Certificate Store verwenden. Hier speichert eine Client- oder Serveranwendung ihr eigenes Zertifikat. - **Speicherort für Zertifikate vertrauenswürdiger Zertifikataussteller**: Dieser Speicherort heißt auch Trusted Issuer Certificate Store. Er enthält ausschließlich Zertifikate von Zertifizierungsstellen, die weitere Zertifikate ausstellen. Hier speichert eine Client- oder Serveranwendung die Zertifikate aller Aussteller (engl. Issuer), deren Zertifikate sie standardmäßig als vertrauenswürdig (engl. trusted) einstuft. - **Speicherort für vertrauenswürdige Zertifikate**: Dieser Speicherort heißt auch Trusted Peer Store. Er enthält ausschließlich Zertifikate, die als vertrauenswürdig eingestuft sind. Hier speichert ein Client die Zertifikate vertrauenswürdiger Server und ein Server die Zertifikate vertrauenswürdiger Clients. - **Speicherort für verweigerte Zertifikate**: Dieser Speicherort heißt auch Rejected Certificate Store. Er enthält ausschließlich Zertifikate, die als nicht vertrauenswürdig eingestuft sind. Hier speichert ein Client die Zertifikate nicht vertrauenswürdiger Server und ein Server die Zertifikate nicht vertrauenswürdiger Clients. Unabhängig davon, ob der Speicherort im System oder als Verzeichnis im Dateisystem liegt, gilt: Zertifikaten im Trusted Store vertraut die Anwendung. Einem Zertifikat, das in keinem der Speicherorte liegt, vertraut sie ebenfalls, wenn das Zertifikat seines Ausstellers im Trusted Issuer Store liegt. Sie kopiert es dabei nicht in den Trusted Store. Ein Zertifikat, das sie bei der Prüfung ablehnt, legt die Anwendung im Rejected Store ab. Auch ein vertrauenswürdiges Zertifikat gilt als nicht vertrauenswürdig, wenn es abgelaufen ist oder wenn die Zertifizierungsstelle seine hinterlegten Informationen nicht bestätigen kann. Den Trusted Peer Store pflegt nur die Anwendung selbst oder ein Administrator. Automatisch legt das SDK dort kein Zertifikat ab und entfernt auch keines. Ein Zertifikat kann außerdem ungültig werden, wenn es in einer Zertifikatsperrliste (engl. Certificate Revocation List, CRL) steht. Diese Liste lässt sich in jedem Speicherort separat führen. Ein Zertifikat, das der Client vom Server oder der Server vom Client erhält, gilt zunächst immer als unbekannt und damit als nicht vertrauenswürdig (engl. untrusted). Damit die Anwendung einem Zertifikat vertraut, muss es als vertrauenswürdig deklariert sein. Dazu liegt das Zertifikat des Clients im Trusted Store des Servers beziehungsweise das Zertifikat des Servers im Trusted Store des Clients. So behandelt der Client ein Serverzertifikat: 1. Der Client ermittelt das Zertifikat des Servers, mit dessen Endpunkt er sich verbinden soll. 2. Der Client prüft das Zertifikat des Servers. - Ist das Zertifikat gültig? - Ist das Gültigkeitsdatum überschritten? - Ist das Zertifikat des Ausstellers gültig? - Existiert das Zertifikat im Trusted Peer Store? - Ist es in eine Zertifikatsperrliste (CRL) eingetragen? - Existiert das Zertifikat im Rejected Store? 3. Wenn das Zertifikat vertrauenswürdig ist, stellt der Client eine Verbindung zum Server her. So behandelt der Server ein Clientzertifikat: 1. Der Server erhält beim Verbindungsaufbau das Zertifikat des Clients. 2. Der Server prüft das Zertifikat des Clients. - Ist das Zertifikat gültig? - Ist das Gültigkeitsdatum überschritten? - Ist das Zertifikat des Ausstellers gültig? - Existiert das Zertifikat im Trusted Peer Store? - Ist es in eine Zertifikatsperrliste (CRL) eingetragen? - Existiert das Zertifikat im Rejected Store? 3. Wenn das Zertifikat vertrauenswürdig ist, lässt der Server die Verbindung des Clients zu und bedient ihn. Wenn die Prüfung des Zertifikats der Gegenstelle fehlschlägt, können Sie die Prüfung mit eigenen Mechanismen erweitern. So lässt sich selbst auf Benutzerebene noch entscheiden, ob die Anwendung das Zertifikat akzeptiert. ## Arten von Zertifikaten Grundsätzlich gibt es selbstsignierte und signierte Zertifikate. Ein Zertifikat ist vergleichbar mit einer Urkunde. Eine Urkunde kann jeder ausstellen und jeder unterzeichnen. Entscheidend ist aber, ob der Unterzeichner wirklich für die Korrektheit der Urkunde bürgt, wie ein Notar, oder ob er selbst der Inhaber der Urkunde ist. Urkunden der zweiten Art sind wenig vertrauenerweckend, weil sich keine anerkannte, gesetzliche Instanz wie ein Notar für den Inhaber verbürgt. Für Zertifikate gilt dasselbe, denn auch sie tragen eine digitale Unterschrift, die Signatur. Die Signatur zeigt dem Empfänger einer Zertifikatskopie, wer sich für das Zertifikat verbürgt. Der Aussteller eines Zertifikats signiert es immer auch. Wenn der Aussteller eines Zertifikats gleich dessen Zielperson (engl. Subject) ist, handelt es sich um ein **selbstsigniertes Zertifikat** (Subject gleich Issuer). Wenn Aussteller und Zielperson verschieden sind, handelt es sich um ein signiertes Zertifikat, auch einfaches oder normales Zertifikat genannt (Subject ungleich Issuer). In OPC UA authentifizieren Zertifikate vor allem die Identität einer bestimmten Client- oder Serveranwendung. Verwenden Sie deshalb signierte Zertifikate als Anwendungszertifikate für die eigene Anwendung. Wenn der Aussteller zugleich Inhaber des Zertifikats ist, sollten Sie diesem selbstsignierten Zertifikat nur vertrauen, wenn Sie den Inhaber als vertrauenswürdig einstufen. Ein signiertes Zertifikat hat, wie oben beschrieben, sein Aussteller signiert. Deshalb muss das Zertifikat des Ausstellers (engl. Issuer Certificate) im Trusted Issuer Store der Anwendung liegen. Wenn es dort fehlt, gilt die Zertifikatskette (engl. Certificate Chain) als unvollständig, und die Anwendung akzeptiert das Zertifikat der Gegenstelle nicht. Wenn das Zertifikat des Ausstellers selbst kein selbstsigniertes Zertifikat ist, muss auch das Zertifikat von dessen Aussteller im Trusted Issuer Store liegen. Wie der Client Serverzertifikate prüft und welche Zertifikate er annimmt, beschreibt der Abschnitt [Serverzertifikate prüfen und vertrauen](https://www.traeger.de/docs/development/opcua/security/client#serverzertifikate-prufen-und-vertrauen). Für den Server beschreibt es der Abschnitt [Clientzertifikate prüfen und vertrauen](https://www.traeger.de/docs/development/opcua/security/server#clientzertifikate-prufen-und-vertrauen). Wie ein Benutzer sich mit einem Zertifikat ausweist, beschreibt die Seite [Benutzer und Rollen](https://www.traeger.de/docs/development/opcua/security/users-roles).