Hinweise zu TLS/SSL für Automic Automation

Es ist zwingend erforderlich, die Kommunikation zwischen den verschiedenen Komponenten, aus denen ihr System besteht, zu sichern. Vor allem bei der Cloud-Kommunikation müssen alle Daten verschlüsselt werden.

Ab Version 21 verwendet Automic Automation die TLS/SSL-Serverauthentifizierung – einen Industriestandard –, um die Kommunikation zwischen verschiedenen Komponenten zu sichern. Automic Automation verwendet auch Zertifikate, um die Identität dieser Partner gegenüber der Komponente zu authentifizieren, zu der sie eine Verbindung herstellen 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:

TLS/SSL-Implementierung – Übersicht

Das nachstehende Diagramm zeigt den für die TLS/SSL-Implementierung erforderlichen Prozess und hilft Ihnen, nicht nur die beteiligten Komponenten, sondern auch den Prozess selbst zu verstehen.

Klicken Sie auf das Bild, um es zu erweitern.

Upgrade-Ablauf aus der TLS-Perspektive

Die Kommunikation zwischen der Automation Engine und den verschiedenen Komponenten verwendet TLS/SSL über ein sicheres WebSocket (WSS). Diese Komponenten richten eine Verbindung zum Java-Kommunikationsprozess (JCP) und/oder dem REST-Prozess (REST) ein, die vertrauenswürdige Zertifikate verwenden, um ihre Identität gegenüber anderen Kommunikationspartnern nachzuweisen, wie beispielsweise Agenten.

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! TLS/SSL-Agenten (in Containern und vor Ort) sowie das TLS Gateway, wenn sie für die Automic Automation Kubernetes Edition verwendet werden, stellen eine Verbindung zu einem Ingress-/HTTPS-Load-Balancer her, der zur Authentifizierung ein Zertifikat anfordert.

Stellen Sie sicher, dass die Adresse des Load Balancers auf beiden Seiten definiert ist: in der Automation Engine und auf dem Agenten/TLS Gateway, und dass Ihr HTTPS-Load-Balancer die erforderlichen Zertifikate zur Nutzung besitzt. Weitere Informationen finden Sie unter Eine Verbindung zum AWI, die JCP- und REST-Prozesse über einen Ingress herstellen.

Automic Automation Administratoren und TLS/SSL

Die meisten Unternehmen verfügen über Sicherheits- und Zertifikatrichtlinien und eine Person oder Gruppe, die für das Erstellen, Verteilen und Verwalten von Zertifikaten (einschließlich der Erneuerung von Zertifikaten) verantwortlich ist. Sehr wahrscheinlich verwendet Ihr Unternehmen entweder eine öffentliche oder interne Zertifizierungsstelle (CA), um Zertifikate zu signieren. Wenden Sie sich an diese Person oder dieses Team, um herauszufinden, wie Ihr Unternehmen mit Zertifikaten umgeht und wie Sie die relevanten Zertifikate für Automic Automation erhalten.

Wichtig! Als Automic Automation-Administrator müssen Sie diese Verantwortung nicht übernehmen (es sei denn, Sie verwenden selbstsignierte Zertifikate in einer Testumgebung). Sie sollten jedoch ein grundlegendes Verständnis von TLS/SSL und Zertifikaten haben und wissen, welche Optionen es gibt und wie sie funktionieren, damit Sie besser verstehen können, welche Sicherheitsinfrastruktur Sie für Ihre Automic Automation-Umgebung benötigen. Sie müssen ALLE diese Konzepte verstehen, bevor Sie das Upgrade planen.

Grundlegende Konzepte bei der Verwendung von TLS/SSL

Als Systemadministrator müssen Sie die grundlegenden Konzepte von TLS/SSL verstehen, um den Schutz Ihres Automic Automation-Systems besser zu verstehen. Stellen Sie sicher, dass Sie über die folgenden Dinge informiert sind:

  • Was ist TLS/SSL? Wie funktioniert ein TLS/SSL-Handshake?

  • Was ist ein Zertifikat? Warum werden Zertifikate verwendet? Warum sind sie notwendig?

  • Welches sind die gängigsten Tools zur Erstellung von Zertifikaten (Java Keytool, OpenSSL in Linux, Keystore Explorer in Windows)?

  • Was ist eine Zertifizierungsstelle (CA, Certificate Authority)?

  • Warum werden Zertifikate signiert?

  • Was ist der Unterschied zwischen einem von einer internen Zertifizierungsstelle und einem von einer öffentlichen Zertifizierungsstelle signierten Zertifikat?

  • Was sind selbstsignierte Zertifikate und welche Nachteile hat ihre Verwendung?

  • Was ist ein Schlüsselspeicher (Keystore)/Schlüssel und welche Formate werden verwendet?

  • Was ist ein Schlüsselpaar mit privatem/öffentlichem Schlüssel?

  • Was ist eine Signaturanforderung für ein Zertifikat (CSR, Certificate Signing Request>)? Woraus besteht eine CSR?

  • Was ist ein Common Name (CN)?

  • Was ist ein Subject Alternative Name (SAN)?

  • Was bedeutet es, ein CA-Root-/Admin-Zertifikat zu haben, und wie ermöglicht es einem Agenten, sich anzumelden?

Überlegungen vor der Installation von Version 21 oder höher

Stellen Sie sicher, dass Sie die folgenden Aspekte berücksichtigen, bevor Sie auf Automic Automation Version 21 oder höher 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.

Zertifikattypen

Automic Automation unterstützt drei Zertifikattypen, um die Kommunikation zu sichern. Es wird empfohlen, eine der CA-signierten Optionen zu verwenden. Der Unterschied zwischen ihnen liegt in der Art und Weise, wie die Zertifikate erstellt werden.

Wichtig!

  • Nutzt Ihr Unternehmen bereits von einer öffentlichen oder internen Zertifizierungsstelle signierte Zertifikate, müssen Sie nur die für die Zertifikate verantwortliche Person oder das verantwortliche Team kontaktieren und die entsprechenden Zertifikate abrufen.

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

  • Wenn Sie nicht den Standardspeicherort verwenden möchten, der vom Java TrustStore oder BS-Speicher verwendet wird, um die Zertifikate zu speichern, stellen Sie sicher, dass Sie den Parameter trustedCertFolder= in der entsprechenden Konfigurationsdatei (INI) verwenden, um den Pfad zum Ordner zu definieren, in dem die vertrauenswürdigen Zertifikate gespeichert sind.

Dieser Abschnitt soll Ihnen nur einen kurzen Überblick geben.

Weitere Informationen über die verschiedenen Zertifikattypen und Beispiele, wie sie erstellt und verwendet werden können, finden Sie unter Welche Art von Zertifikaten sollte ich für Automic Automation v21 verwenden?

Wichtig! Beachten Sie, dass dies nur Beispiele sind, keine Anforderung für Automic Automation darstellen und nicht dafür gedacht sind, die Produktdokumentation zu ersetzen.

Von einer öffentlichen Zertifizierungsstelle (CA) signierte Zertifikate

Von einer öffentlichen Zertifizierungsstelle (CA) signierte Zertifikate, wie z. B. IdenTrust, DigiCert, Let's Encrypt, GlobalSign usw., werden von verschiedenen Betriebssystemen und/oder Anwendungen normalerweise bereits als vertrauenswürdig eingestuft. Dadurch entfällt der Aufwand für die Bereitstellung dieser Zertifikate für alle relevanten Hosts.

Es wird empfohlen, Zertifikate zu verwenden, die von einer öffentlichen Zertifizierungsstelle signiert wurden, wenn Sie mit Produktionsumgebungen und Anwendungen arbeiten, die mit dem Internet verbunden sind.

In diesem Fall stellt Ihnen die öffentliche Zertifizierungsstelle Ihrer Wahl die Zertifikate zur Auswahl, die Sie benötigen. Die relevanten Unternehmen stellen dafür bestimmte Tools oder APIs zur Verfügung. CA-Root-/Admin-Zertifikate werden normalerweise nur für das Signieren von Zwischenzertifikaten verwendet, die dann die Identitäten von Enddomänen verifizieren können.

Von einer internen Zertifizierungsstelle (CA) signierte Zertifikate

Sie können von einer unternehmensweiten, internen Zertifizierungsstelle (CA) signierte Zertifikate verwenden, wenn Sie z. B. in einer Testumgebung arbeiten oder Anwendungen verwenden, die nicht mit dem Internet verbunden sind.

Sie müssen eine Signaturanforderung für ein Zertifikat (CSR) stellen, die vom CA-Root-Zertifikat signiert wird. Die Antwort auf die CSR ist das Serverzertifikat, das Sie in den Truststore von Automation Engine laden.

Stellen Sie sicher, dass die vertrauenswürdigen Zertifikate auf den jeweiligen Hosts bereitgestellt werden.

Da die Serverzertifikate eine kürzere Lebensdauer haben können, kann die Gültigkeitsdauer des CA-Root-/Admin-Zertifikats länger sein.

Selbstsignierte Zertifikate

Mit selbstsignierten Zertifikaten können Sie die Sicherheit Ihres Automic Automation-Systems verwalten, ohne Drittanbieter einbeziehen zu müssen. In diesem Fall ist der Automic Automation-Administrator für das Verlängern und das Verteilen von Zertifikaten auf allen Hosts verantwortlich.

Wichtig! Es wird nicht empfohlen, selbstsignierte Zertifikate außerhalb einer Testumgebung zu verwenden.

Als Automic Automation-Administrator können Sie 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.

Hinweis: Aktualisieren Sie cn= auf den vollständig qualifizierten Domänennamen des JCP-Servers und ou=, o=, l= und c= auf für Ihre Umgebung geeignete Werte.

Beispiel für Java Keytool

Beispiel für einen Server namens 24JLZY2

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"

Sobald Ihre selbstsignierten Zertifikate vorliegen, müssen Sie sie im jeweiligen TLS/SSL-Keystore bereitstellen und die Automation Engine und die entsprechende TLS/SSL-Komponente für die Arbeit mit Ihren Zertifikaten konfigurieren.

  • Bereitstellen der Zertifikate im Keystore und Konfigurieren der AE

    Sie müssen verschlüsselte Passwö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 der AWI

    Importieren Sie die Serverzertifikate in den Java Certificate Truststore (cacerts) oder setzen Sie den Parameter trustedCertFolder= für die AWI-Konfigurationsdatei (uc4config.xml) entsprechend, bevor Sie das Automic Web Interface neu starten.

  • Konfigurieren der TLS/SSL-Komponenten (Agenten, TLS Gateway usw.)

    Sie müssen 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.

Zertifikatanforderungen für Automic Automation

Sobald Sie mit den grundlegenden Konzepten in TLS/SSL und Zertifikaten vertraut sind, stellen Sie sicher, dass die Zertifikate die Anforderungen erfüllen für: Automation Engine

Allgemeine Anforderungen

Die JCP- und REST-Prozesse verwenden vertrauenswürdige Zertifikate, um ihre Identität gegenüber anderen Kommunikationspartnern nachzuweisen, wie z. B. AWI sowie Java-, Windows- und UNIX-Agenten.

Die TLS/SSL-Implementierung von Automic Automation 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.).

Für die Konfiguration der TLS/SSL-Verbindung wird die Java-Standard-Cipher-Suite des JCP verwendet. Sie können die unterstützten Cipher Suites in der Java-Sicherheitsrichtlinie ändern. Weitere Informationen finden Sie unter https://www.java.com/en/configure_crypto.html.

Verwenden von Subject Alternative Names (SAN)

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

Hinweis: Wenn ein Subject Alternative Name (SAN) definiert wurde, muss der Common Name (CN) in der SAN-Liste wiederholt werden, weil der Common Name ignoriert wird, wenn Subject Alternative Names vorhanden sind.

TLS/SSL-Handshake

Der TLS/SSL-Handshake ist der Mechanismus, der verwendet wird, um die Kommunikationspartner zu authentifizieren. In diesem Abschnitt wird erklärt, wie der standardmäßige TLS/SSL-Handshake speziell im Zusammenhang mit Automic Automation funktioniert und welche Elemente vorhanden sein müssen, damit er funktioniert.

Wichtig! Als Automic Automation-Administrator müssen Sie keine Zertifikate erstellen und verteilen. Sie müssen nur die Person oder das Team kontaktieren, die bzw. das für Zertifikate in Ihrem Unternehmen verantwortlich ist, um zu erfahren, wie die relevanten Zertifikate erreicht werden.

Der TLS/SSL-Handshake hat zwei Seiten:

  • die AE-/Server-Seite (JCP und/oder REST-Prozesse)

  • die Komponenten-/Host-Seite (AWI, die Agenten usw.)

Der Host stellt die Verbindung zur AE her. Die AE sendet dann den öffentlichen Schlüsselabschnitt des Zertifikats an den Host, der wiederum die Standardspeicherorte im Betriebssystem durchsucht und das Zertifikat verifiziert.

Der Host überprüft, ob seine Verbindungsparameter für die AE mit den Servernamen in den Zertifikaten übereinstimmen. Wenn sie nicht übereinstimmen, können sie keine Verbindung herstellen. Beispiel: servername ist nicht gleich servername.fqdn.

Stellen Sie auf der Automation Engine-/Server-Seite sicher, dass die Zertifikate auf dem AE-Server verfügbar sind, ebenso wie auf dem Host, auf dem die JCP/REST-Prozesse installiert sind.

Wenn Sie auf der Host-Seite (AWI, Agenten usw.) nicht den Standardspeicherort verwenden möchten, der vom Java TrustStore oder BS-Speicher verwendet wird, um die Zertifikate zu speichern, stellen Sie sicher, dass Sie den Parameter trustedCertFolder= in der entsprechenden Konfigurationsdatei (INI) verwenden, um den Pfad zum Ordner zu definieren, in dem die vertrauenswürdigen Zertifikate gespeichert sind.

Abgelaufene JCP-Zertifikate verlängern

Sie müssen sicherstellen, dass die verwendeten Zertifikate nicht nur die jeweiligen Sicherheitsanforderungen erfüllen, sondern auch nicht abgelaufen sind. Andernfalls können die Komponenten keine Verbindung zur Automation Engine herstellen.

Das System prüft das Zertifikatablaufdatum alle 24 Stunden (um Mitternacht UTC). Wenn das Ablaufdatum eines oder mehrerer Zertifikate innerhalb von 30 Tagen liegt, zeigt AWI die folgende Benachrichtigung an: "Die folgenden JCP-Zertifikate laufen innerhalb der nächsten 30 Tage ab: <Zertifikatname (Ablaufdatum)>". Das Ablaufdatum des Zertifikats wird auch beim Start sowie um Mitternacht (UTC) in die JCP-Logdatei geschrieben.

Die Benachrichtigung wird in allen Mandanten aber nur für Benutzer mit dem Recht Zugriff auf Administration angezeigt. Weitere Informationen finden Sie unter Berechtigungen Automation Enginegewähren. Die Benachrichtigung bleibt sichtbar, bis das Zertifikat verlängert wird.

Hinweise:

  • AWI zeigt nur eine Benachrichtigung an, selbst wenn mehr als ein Zertifikat abläuft. Alle relevanten Zertifikate werden nacheinander durch ein Komma getrennt nach Ablaufdatum aufgelistet; das Zertifikat, das dem Ablaufdatum am nächsten ist, wird zuerst aufgelistet.

  • Nach der Erneuerung des Zertifikats muss der JCP nicht neu gestartet werden.

  • Stellen Sie sicher, dass das neue Zertifikat richtig eingestellt ist und dieselbe Definition wie der TLS-Abschnitt der INI-Datei der Automation Engineverwendet, siehe Automation Engine. Andernfalls wird die alte KeyStore-Definition verwendet und der JCP wird nicht gestartet.

Optional können Sie auch die Variable UC_SERVER_TLS_SETTINGS verwenden, um eine benutzerdefinierte Aktion auszulösen, wenn eines dieser Zertifikate kurz vor dem Ablauf steht. Weitere Informationen finden Sie unter UC_SERVER_TLS_SETTINGS – Serverzertifikatsverwaltung.

Wenn das Ablaufdatum naht ( z. B. innerhalb der nächsten ein bis drei Monate) und Sie ein von einer externen oder internen Zertifizierungsstelle (CA) signiertes Zertifikat verwenden, stellen Sie sicher, dass Sie die relevanten Personen informieren. Das kann entweder Ihr Automic Automation-Administrator sein oder die Person oder das Team, das in Ihrem Unternehmen für die Sicherheit zuständig ist. Sie müssen möglicherweise eine Signaturanforderung für ein Zertifikat (CSR, Certificate Signing Request) stellen, damit das Zertifikat vom CA-Root-Zertifikat signiert wird.

Die neuen Zertifikate müssen entweder für jeden JCP erstellt werden, oder es muss jeweils ein Zertifikat für alle JCP-Domänennamen erstellt werden. Außerdem sollten sich der Schlüsselspeichername, das Schlüsselspeicherkennwort, das Schlüsselkennwort und der Schlüsselalias nicht ändern. Andernfalls müssen die entsprechenden INI-Dateiparameter angepasst werden, was wiederum einen Neustart des JCP erforderlich macht.

Sobald die neuen Zertifikate bereit sind, müssen sie für alle JCPs bereitgestellt werden (z. B. über einen FileTransfer). Wenn sich die INI-Datei nicht ändert, ist kein Neustart der JCPs erforderlich.

Nachdem die Zertifikate für die JCPs erneuert und bereitgestellt wurden, müssen Sie prüfen, ob die Zertifikate für die Agenten ebenfalls aktualisiert werden müssen. Beachten Sie Folgendes:

  • Wenn ein neues Zertifikat von derselben Zertifizierungsstelle wie das ursprüngliche signiert ist und die Root-/Zwischenzertifikate der Zertifizierungsstelle bereits im entsprechenden Truststore (Betriebssystem oder Java) auf den Agentenhosts vorhanden sind (was der Fall sein sollte), muss nichts getan werden. Der Agent vertraut der Zertifizierungsstelle, die das neue Zertifikat signiert hat; daher vertrauen sie automatisch dem Serverzertifikat.

  • Wenn Sie neue selbstsignierte Zertifikate verwenden, müssen die Agenten ihnen direkt vertrauen. Das heißt, dass die neuen selbstsignierte Zertifikate erneut für alle Agenten bereitgestellt werden müssen (wie bei der ersten Bereitstellung). Dazu können Sie sie entweder in einen trustedcertfolder kopieren oder sie im Betriebssystem- oder Java-Truststore installieren.

Hinweis: Während FileTransfers erfordern die Agents auch Zertifikate für die Authentifizierung. Die Automation Engine erneuert automatisch diese Zertifikate für die Windows-, UNIX- und Java-Agenten sowie das Zertifikat für das TLS Gateway.

Informationen über TLS/SSL in dieser Dokumentation finden

Die Dokumentation enthält dort Informationen zur TLS/SSL-Implementierung, wo Sie diese brauchen. Beispielsweise finden Sie Informationen zur TLS/SSL-Implementierung für einen Agenten auf der entsprechenden Dokumentationsseite für diesen Agenten. Das gleiche gilt für alle anderen Komponenten, für die die Einrichtung von TLS/SSL erforderlich ist.

Es ist jedoch wichtig, dass Sie die Informationen finden, die Sie benötigen, unabhängig von Ihrem Einstiegspunkt in die Dokumentation:

Hinweis: Dies bezieht sich auf die obligatorische Implementierung der TLS/SSL-Serverauthentifizierung, die in Version 21 für die Kommunikation zwischen der Automation Engine und den verschiedenen Komponenten eingeführt wurde.

TLS/SSL und der Abschnitt Sicherheit

Der Abschnitt Administration und Konfiguration der Dokumentation enthält viele Seiten, die sich ausschließlich der Sicherheit Ihres Systems widmen. Dieser Abschnitt enthält die folgenden Informationen über TLS/SSL:

TLS/SSL und die AE-Installation

Der Abschnitt Installation der Dokumentation enthält die TLS/SSL-Informationen, die Sie für die Vorbereitung der Installation benötigen. Außerdem sind Informationen enthalten, die Sie während des Installationsvorgangs benötigen.

Für die manuelle Installation eines lokalen Systems:

Für die Automic Automation Kubernetes Edition:

TLS/SSL und die Agenteninstallation

Die Windows-, UNIX- und Java-Agenten, d. h. die SQL-, JMX-, PeopleSoft-, RA-Kern-, SAP- und IA (Analytics)-Agenten, verwenden TLS/SSL, um die Verbindung zur Automation Engine einzurichten.

TLS/SSL und das AE-Upgrade

Der Abschnitt Upgrade der Dokumentation enthält die Informationen über TLS/SSL, die Sie für die Vorbereitung auf das Upgrade benötigen. Außerdem sind Informationen enthalten, die Sie während des Upgrade-Vorgangs benötigen.

Für das manuelle Upgrade eines lokalen Systems:

Für die Automic Automation Kubernetes Edition:

TLS/SSL- und Java-Komponenten, Proxy und TLS Gateway

Diese Komponenten erfordern auch TLS/SSL-Sicherheit:

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: