TLS/SSL-Zertifikate vorbereiten

Die Kommunikation zwischen der Automation Engine, der Automic Web Interface, der Java API und dem Proxy-Client sowie zwischen der Automation Engine, den TLS/SSL-Agenten (Java-, Windows-, UNIX-Agenten) und dem TLS Gateway verwendet TLS/SSL über ein sicheres WebSocket (WSS). Diese Komponenten richten eine Verbindung mit dem Java-Kommunikationsprozess (JCP) und/oder dem REST-Prozess (REST) ein. Diese Server-Prozesse verwenden vertrauenswürdige Zertifikate, um ihre Identität gegenüber anderen Kommunikationspartnern wie z. B. Agenten nachzuweisen.

Deshalb müssen Sie entscheiden, welche Art von Zertifikaten Sie verwenden werden, um die Kommunikation in Ihrem System zu sichern. Diese Entscheidung muss sorgfältig durchdacht werden, da sie nicht nur bestimmt, wie sicher die Verbindungen sind, sondern auch die Zeit und den Aufwand, die Sie in die Erneuerung und Bereitstellung der Zertifikate investieren müssen.

Wichtig! Lesen Sie in Broadcom Software Academy nach. Es gibt einen Kurs zu diesem Thema. Weitere Informationen finden Sie im Abschnitt Schulung am Ende dieses Themas.

Diese Seite beinhaltet Folgendes:

Überlegungen vor der Installation von Automic Automation Version 21

Stellen Sie sicher, dass Sie die folgenden Aspekte berücksichtigen, bevor Sie auf Automic Automation Version 21 aktualisieren oder diese installieren:

  • Wenn Ihr Unternehmen bereits von einer Drittanbieter-Zertifizierungsstelle signierte Zertifikate nutzt, können diese auch für Automic Automation verwendet werden?

  • Müssen bei der Verwendung von Automic Automation strenge Sicherheitsstandards erfüllt werden, besonders in Produktionsumgebungen?

  • Wer ist für die Verwaltung von Zertifikaten verantwortlich und ist eine bestimmte Person oder ein bestimmtes Team im Unternehmen für die Public Key Infrastructure (PKI) verantwortlich?

  • Wer ist verantwortlich für die Installation und/oder das Verteilen von Zertifikaten und die Konfiguration von TLS/SSL für Automic Automation?

  • Wie viele Zertifikate benötigen Sie? Nur ein paar für Ihre Automic-Server, oder müssen Sie mehrere Server verwalten, die über viele Standorte verteilt sind, und eine zentrale Ansicht benötigen?

  • Wie wichtig ist die Verbindungssicherheit? Was ist der schlechteste Fall, wenn ein Zertifikat abläuft oder beeinträchtigt ist?

Basierend auf den Anforderungen und Ressourcen Ihres Unternehmens können Sie entscheiden, welcher Typ von TLS/SSL-Zertifikat verwendet werden soll.

Zertifikate – Übersicht

Ein Zertifikat mit öffentlichem Schlüssel enthält Informationen wie Name, Hostname/Domänenname/IP-Adresse, Gültigkeitsdauer und Standort, der verwendet werden soll, um den Besitzer (Server) zu identifizieren. Es enthält außerdem den öffentlichen Schlüssel, den der Mandant verwendet, um den Server zu überprüfen. Durch Verwendung einer digitalen Signatur für das Signieren des Zertifikats, beispielsweise durch eine öffentliche oder kommerzielle Zertifizierungsstelle (CA, Certificate Authority), wird sichergestellt, dass das Zertifikat nicht nur gültig ist, sondern auch von allen Kunden als vertrauenswürdig eingestuft werden kann, die dieser Zertifizierungsstelle vertrauen.

Die Automic Automation TLS/SSL-Implementierung verwendet Zertifikate mit öffentlichem Schlüssel im X.509-Format und TLS-Version 1.2 für die sicheren Verbindungen zwischen dem Server (Automation Engine) und den Mandanten (AWI, Agenten usw.).

Zertifikattypen

Es stehen drei Zertifikattypen zur Verfügung, um die Kommunikation zu sichern:

  • Selbstsignierte Zertifikate

    Die Verwendung von selbstsigniertem Zertifikaten bietet Ihnen Flexibilität und Sie müssen dafür kein TLS/SSL-Experte sein. Es obliegt jedoch Ihrer Verantwortung, die Zertifikate zu erneuern und zu verteilen.

  • Von einer internen Zertifizierungsstelle (CA) signierte Zertifikate

    Das Erstellen einer eigenen internen Zertifizierungsstelle (CA) zum Signieren Ihrer Zertifikate ist nützlich, wenn Sie in einer Testumgebung arbeiten oder Anwendungen verwenden, die nicht mit dem Internet verbunden sind. In diesem Fall fällt die Notwendigkeit weg, sich an Drittanbieter zu wenden.

  • Von einer öffentlichen Zertifizierungsstelle (CA) signierte Zertifikate

    Die Verwendung von Zertifikaten, die von einer öffentlichen Zertifizierungsstelle (CA) signiert wurden, wie z. B. IdenTrust, DigiCert, Let‘s Encrypt, GlobalSign usw., wird empfohlen, wenn Sie mit Produktionsumgebungen und Anwendungen arbeiten, die mit dem Internet verbunden sind. Diese registrierten CAs sind autorisiert, Endzertifikate auszustellen, die von Browsern und anderen Anwendungen, die TLS/SSL zum Schutz von Verbindungen verwenden, als vertrauenswürdig eingestuft werden. Dadurch wird der Aufwand der Verwaltung von Zertifikaten reduziert.

TLS/SSL-Zertifikate erstellen und verwenden – AE, Agenten und AWI-Verbindungen

In diesem Abschnitt finden Sie einen Überblick darüber, wie TLS/SSL-Zertifikate erstellt und verwendet werden, die entweder von einer internen oder öffentlichen Zertifizierungsstelle (CA) oder selbst signiert wurden. Der Unterschied zwischen ihnen liegt in der Art und Weise, wie die Zertifikate erstellt werden:

  • Selbstsignierte Zertifikate

    Sie können selbstsignierte Zertifikate unter Verwendung von Tools wie Java Keytool, OpenSSL oder dem KeyStore Explorer erstellen. Dazu müssen Sie einen Keystore im Format PKCS#12 erstellen und die Keystore-Datei an einem sicheren Speicherort speichern. Dann müssen Sie das Schlüsselpaar generieren und die Gültigkeitsdauer sowie weitere Zertifikatdetails definieren.

    Beispiel für Java Keytool

    keytool -genkeypair -alias jetty -keyalg RSA -storetype PKCS12 -keypass changeit -storepass changeit -keystore httpsKeyfile -validity 365 -keysize 2048 -dname "cn=24JLZY2, ou=Automic, o=Broadcom, l=Vienna, c=AT"

  • Durch eine interne Zertifizierungsstelle signierte Zertifikate

    Sie können eine interne Zertifizierungsstelle mit Tools wie OpenSSL erstellen. In diesem Fall können Sie auch entscheiden, ob Sie mehrere Schichten von CAs oder ein internes CA-Stammzertifikat erstellen möchten, um das Endzertifikat des Automic-Servers zu signieren.

    Dafür müssen Sie die erforderlichen Dateien erstellen: den privaten Schlüssel und das selbstsignierte Stammzertifikat.

    Der private Schlüssel muss an einem sicheren Speicherort gespeichert werden und sollte kennwortgeschützt sein. Dieses Kennwort ist erforderlich, wenn Sie das Stammzertifikat erstellen. Da die Endzertifikate, die für den Server verwendet werden, eine kürzere Lebensdauer haben können, kann die Gültigkeitsdauer des CA-Stammzertifikats länger sein.

    Beispiel

    $ openssl req -x509 -new -key automicCA.key -sha256 -days 700 -out automicCA.crt

    Sie benötigen eine Zertifikatsignierungsanforderung (CSR, Certificate Signing Request), um andere Zertifikate mit dieser CA zu signieren. Dafür erstellen Sie einen privaten Schlüssel für den Automic-Server.

    Wenn Ihr Unternehmen bereits eine interne Zertifizierungsstelle hat, die verwendet wird, um Endzertifikate für andere Anwendungen zu erstellen, können Sie diesen Schritt überspringen und diese interne Zertifizierungsstelle verwenden.

  • Von einer öffentlichen Zertifizierungsstelle signierte Zertifikate

    In diesem Fall müssen Sie die öffentliche Zertifizierungsstelle Ihrer Wahl auffordern, Ihnen die Zertifikate zur Verfügung zu stellen, die Sie benötigen. Es gibt mehrere Möglichkeiten, diese Zertifikate zu erhalten. Die relevanten Unternehmen stellen dafür bestimmte Tools oder APIs zur Verfügung. CA-Stammzertifikate werden normalerweise nur für das Signieren von Zwischenzertifikaten verwendet, die dann die Identitäten von Enddomänen verifizieren können.

    Wenn Ihr Unternehmen bereits von einer öffentlichen Zertifizierungsstelle signierte Zertifikate für andere Anwendungen verwendet, können Sie diesen Schritt überspringen.

Unabhängig vom Typ der Zertifikate, die Sie verwenden, müssen Sie, sobald Sie Ihre Zertifikate zur Verfügung haben, den TLS/SSL-Keystore bereitstellen und die Automation Engine, die Automic Web Interface, die TLS/SSL-Agenten (Java-,Windows- und UNIX-Agents) und das TLS Gateway so konfigurieren, dass sie mit Ihren Zertifikaten funktionieren.

  • Bereitstellen des Keystores und Konfigurieren der AE

    Sie müssen verschlüsselte Kennwörter für die Keystore-Verbindungen erstellen, die INI-Datei (ucsrv.ini) der AE entsprechend konfigurieren und die Keystore-Datei auf dem Zielserver bereitstellen, bevor Sie die Automation Engine starten und Ihre Verbindungen testen.

  • Konfiguration AWI

    Wenn Sie selbstsignierte Zertifikate verwenden, müssen Sie die Serverzertifikate in den Java Certificate Truststore (cacerts) importieren oder den Parameter trustedCertFolder= für die AWI-Konfigurationsdatei (uc4config.xml) entsprechend festlegen, bevor Sie das Automic Web Interface neu starten.

  • Konfigurieren der TLS/SSL-Agenten und/oder des TLS Gateway

    Wenn Sie selbstsignierte Zertifikate verwenden, müssen Sie den Pfad zu dem verwendeten Zertifikat im Abschnitt [AUTHORIZATION] der INI-Datei des relevanten TLS/SSL-Agenten oder TLS Gateway konfigurieren, oder den Java TrustStore oder BS-Speicher verwenden, um die entsprechenden Zertifikate zu importieren.

Wenn Sie von einer Zertifizierungsstelle signierte Zertifikate verwenden, müssen Sie nichts für die Automic Web Interface oder die Agenten/das TLS Gateway konfigurieren. Sie müssen nur prüfen, ob die Stammzertifikate bereits im Java TrustStore- oder BS-Speicher vorhanden sind.

Weitere Informationen zu den verschiedenen Zertifikattypen und ausführliche Anweisungen zur Erstellung und Verwendung finden Sie unter Welche Art von Zertifikaten sollte ich für Automic Automation v21 verwenden?

Hochverfügbarkeit, mehrere Netzwerkkarten oder JCPs auf mehreren Servern

Jede in Automic Automation verwendete IP-Adresse und jeder Server/Hostname müssen im Zertifikat vorhanden sein. Daher ist es für mehrere Netzwerkkarten, verschiedene interne und externe Adressen, DNS-Aliase oder mehrere JCPs über verschiedene Server hinweg notwendig, dass Sie Subject Alternative Names (SAN) definieren.

Hinweis: Wenn Sie einen Subject Alternative Name (SAN) definieren, müssen Sie den Common Name (CN) in der SAN-Liste wiederholen, weil der Common Name ignoriert wird, wenn Subject Alternative Names vorhanden sind.

Um eine CSR zu erstellen, müssen Sie den Common Name (CN) für das Serverzertifikat angeben und es muss mit dem Hostnamen/der Domäne/Adresse übereinstimmen, mit der die Agenten eine Verbindung zum Server herstellen.

Schulung

Die Broadcom Software Academy bietet zahlreiche kostenlose Online-Schulungen. Informationen dazu, wie Sie innerhalb der Academy navigieren und sich für Kurse anmelden, finden Sie unter Kostenlose Online-Kurse.

Diesem Thema sind die folgenden Kurse zugeordnet:

  • Automic Automation TLS und Zertifikate

  • Automic Automation TLS Gateway

Weitere Informationen finden Sie unter Kostenlose Online-Kurse.

Nächster Schritt:

Die AE-Datenbank einrichten