In Desigo entsprechen Betriebszertifikate digitalen Zertifikaten für eine sichere Kommunikation http (https) mit in Desigo-Geräten eingebetteten Webservern oder gesicherter BACnet-Kommunikation (BACnet/SC, WSS://) zwischen Geräten.

Die Betriebszertifikate für Webserver und BACnet/SC in einem Projekt sind unterschiedlich. Die Basis-Workflows zur Erstellung und Handhabung der Zertifikate sind identisch.

Siehe https://en.wikipedia.org/wiki/Public_key_certificate.

Folgende Gerätetypen unterstützen Betriebszertifikate für eingebaute Webserver:

  • PXC3.Exxx-1
  • DXR2.Exxx-1
  • PXG3.Wxxx-1
  • PXMxx-1
  • PXMxx.E
  • PXC4..
  • PXC5.E003
  • PXC7.E400x

Vorteile der Zertifikate

Mit TLS (in https oder wws) wird die Kommunikation mit Webservern verschlüsselt, um Abhören und Ändern der Kommunikation zu verhindern. Zusätzlich können Web-Client-Benutzer so sicher sein, dass sie mit dem echten Webserver und nicht einer Fälschung verbunden sind. Bei korrekter https-Verbindung zeigt der Web-Browser dies mittels grünem Text in der URL-Leiste an.

Beispiel für korrekte https-Verbindung

Bei Zertifikatsproblemen zeigt der Web-Browser eine Fehlermeldung an. Meist bedeutet dies, dass die Serverauthentifizierung nicht verifiziert werden kann. Der Benutzer kann zwar weiterfahren, was aber nicht sinnvoll ist.

Ähnlich verhält es sich bei einem falschen oder abgelaufenen Zertifikat, wo ebenfalls eine Fehlermeldung in der BACnet/SC-Kommunikation erzeugt wird. Da BACnet/SC jedoch Machine-to-Machine (M2M) Kommunikation ist, bezieht sich der WebSocket-Fehler nicht direkt auf die Benutzerbedienung, sondern erzeugt einen Fehler im BACnet-System, welche dann als regulärer BACnet-Fehler behandelt wird.

Warnungsmeldung zu fehlerhaftem Zertifikat

Was sind Zertifikate?

Jedes Zertifikat wird durch eine vertrauenswürdige Zertifizierungsstelle (CA) ausgegeben.

In Desigo wird für jeden Webserver ein eigenes Zertifikat ausgestellt. Zusätzlich geben die Zertifizierungsstellen eigene Zertifikate aus, sogenannte Root-Zertifikate.

Ein Zertifikat enthält mehrere Felder. Die wichtigsten sind:

  • Die Identität, z.B. die IP-Adresse des Webservers
  • Der kryptographische Schlüssel für sichere Kommunikation
  • Eine Gültigkeitsperiode
  • Information zur CA, die das Zertifikat ausstellte
  • Signatur als Zeichen der Echtheit

Die Signatur ist ein Sicherheitscode, die vor der CA ausgestellt wird und fälschungssicher ist. Der Vorgang der Zertifikatserstellung wird daher oft Signierung genannt.

Zur Validierung einer Zertifikatssignatur muss ein Client bereits ein Zertifikat der ausstellenden CA besitzen. Aus diesem Grund vertrauen Web-Browser und Betriebssysteme jeweils mehreren CAs. Benutzer und Administratoren können weitere CAs wie Firmen-CAs hinzufügen.

Oft sind CAs auf mehreren Ebenen organisiert, mit einer Root-CA und einer oder mehr dazwischenliegenden CAs.

In Windows befinden sich die Zertifikate unter Internet-Optionen > Inhalt > Zertifikate.

Liste der Zertifikate in MS Windows

Zertifikatstypen

In Desigo werden die Zertifikate durch ABT Site verwaltet. Sie wählen unter den folgenden Optionen für jedes Gerät aus:

  1. Interne CA (Vorgabe): ABT ist die CA.
  • Automatisch durch ABT gehandhabte Zertifikate.
  • Jedes Projekt hat ein eigenes Root-Zertifikat.
  • Externe CA: CA durch externe Organisation bereitgestellt. So kann eine CA z.B. durch die IT-Abteilung des Kunden oder den Systembediener bereitgestellt werden.
    • Kann eine Anforderung in Hochsicherheitsprojekten sein.
    • Erfordert weitere Workflows.
  • Kein Zertifikat.
  • Bei einer internen CA kann jeder Bediener, der eine Kopie des ABT-Projekts besitzt, neue Zertifikate für das Projekt erstellen. Aus diesem Grund ist es wichtig, die ABT-Projektdateien inklusive Exporte über Pack & Go sorgfältig zu verteilen und aufzubewahren.

    Details in ABT Site Online-Hilfe.

    Zertifikate einer externen CA importieren

    Im Folgenden wird gezeigt, wie Betriebszertifikate aus einer externen CA importiert werden. Mehrere Geräte können gemeinsam behandelt werden.

    Betriebszertifikate einer externen Zertifizierungsstelle (CA) importieren

    Root-Zertifikate exportieren

    Die Web-Clients müssen die Root-Zertifikate der CAs für die Validierung der Betriebszertifikate aufweisen. Die Methode zur Angabe der Root-Zertifikate hängt vom Client-Typ ab:

    • Desigo-Touchpanels: Root-Zertifikate werden automatisch durch ABT Site geladen.
    • Desigo CC und Web-Browser:
      • Externe CA: Werden vom Administrator der externen CA bereitgestellt, z.B. IT-Abteilung des Kunden.
      • Interne CA: Das Root-Zertifikat muss aus ABT Site exportiert und im Client importiert werden.
        Ein Desigo CC Administrator mit Zugriff auf das Tool OpenSSL erstellt ein Betriebszertifikat für Desigo CC zusammen mit einem CSR. Diese werden als Dateien an ABT Site (oder eine andere CA) übergeben, dort signiert und zurück an Desigo CC zum Import gegeben.

    Die folgende Darstellung zeigt, wie Root-Zertifikate aus ABT Site exportiert und im Client importiert werden.

    Root-Zertifikat für Client bereitstellen

    Die meisten Web-Browser (aber nicht alle) verwenden die Zertifikatsablage des Betriebssystems, z.B. den Zertifikatsspeicher unter Microsoft Windows.

    So verwendet Mozilla Firefox z.B. einen eigenen Zertifikatsspeicher. Das Root-Zertifikat muss daher in Firefox importiert werden. Das kann geändert werden durch Einstellen von about:config > security.enterprise_roots.enabled auf true. Die Einstellung ist standardmässig bei false.

    Einstellung about:config in Mozilla Firefox

    Die Installation der Root-Zertifikate oder eine Änderung der Sicherheitseinstellungen auf den Computern des Kunden muss mit der zuständigen IT-Abteilung abgesprochen sein.

    Zertifikatseinsatz

    Sind alle Betriebszertifikate und Root-Zertifikate installiert, präsentiert sich die Situation wie folgt:

    Zertifikatseinsatz

    Jedes Gerät mit einem eigenen Webserver hat ein eigenes Betriebszertifikat mit IP-Adresse oder vollqualifiziertem Domänennamen (FQDN). Jeder Client hat eines oder mehr Root-Zertifikate. Manche Geräte sind sowohl Server wie auch Client, z.B. Touchpanels mit eingebettetem Webserver.

    Jedes Zertifikat hat eine Gültigkeitsperiode begrenzt durch zwei Daten. Das bedeutet, dass jedes Zertifikat endlich ist und periodisch ersetzt werden muss.

    Die Laufzeitdauer wird durch die CA bestimmt. Die Vorgabe für die interne CA ist 5 Jahre. Das Gerät löst einen BACnet-Alarm aus, wenn das Ablaufdatum des Betriebszertifikats naht. Nach Ablauf zeigen die Clients bei jeder neuen Verbindung eine Warnung bis hin zu einem Kommunikationsstop in restriktiven Umgebungen.

    Standardformat und Inhalt

    Die durch die CA ausgestellten Dateien müssen die folgenden Anforderungen erfüllen, um die Kompatibilität der durch eine externe CA erstellten Zertifikate sicherzustellen. Wenn Sie andere Anforderungen haben, kontaktieren Sie den Kunden-Support.

    • Die Dateien müssen die Gerätezertifikate im PEM-Format enthalten, gefolgt von den Zertifikaten der Zertifikatsbehörden gemäss folgendem Schema. Das Zwischenzertifikat darf fehlen oder kann wiederholt werden für jede Zwischenzertifikatsbehörde in der Vertrauenskette.

    -----START ZERTIFIKAT-----

    (Gerätezertifikat)

    -----ENDE ZERTIFIKAT-----

    -----START ZERTIFIKAT-----

    (Zwischenzertifikat)

    -----ENDE ZERTIFIKAT-----

    -----START ZERTIFIKAT-----

    (Root-Zertifikat)

    -----ENDE ZERTIFIKAT-----

    • Die Gerätezertifikate müssen eine X.509v3-Erweiterung mit Subject Alternative Name enthalten, die wiederum die IP-Adresse oder den DNS-Namen des Geräts wie in der Zertifikatssignierungsanforderung enthalten muss.