Zertifikate kommen bei der Verwendung verschlüsselter TLS-Verbindungen zwischen Client und Server zum Einsatz. Zum erfolgreichen Aufbau einer solchen Verbindung benötigt der Server stets ein Zertifikat und einen zugehörigen privaten Schlüssel. Der HEM2 / DLM Pro hat dazu bereits ein selbst-signiertes Zertifikat an Bord. Es müssen also keine eigenen Zertifikate eingespielt werden. Diese Option besteht allerdings sowohl auf der Server- als auch auf Clientseite.

Serverseitig können ein eigenes Zertifikat und der zugehörige private Schlüssel eingespielt werden. Dabei kann dieses Zertifikat selbst-signiert oder auch von einer offiziellen Zertifizierungsstelle signiert sein. Wird im Client kein CA-Zertifikat (CA = Certificate Authority) hinterlegt, kommt so in jedem Fall eine TLS-Verbindung zu Stande. Werden im Client ein oder mehrere CA-Zertifikate hinterlegt, müssen die jeweiligen Server-Zertifikate dazu passen (OCPP Security Profile 2). Als CA-Zertifikat kann das Server-Zertifikat selbst hinterlegt werden. Hat der Client eine Verbindung ins Internet, können dort auch Root-Zertifikate von Zertifizierungsstellen hinterlegt werden, die das Server-Zertifikat signiert haben. Es kann aber auch ein eigenes Root-Zertifikat hinterlegt werden, das das Server-Zertifikat signiert hat.

Als zusätzliche Sicherheitsstufe kann zusätzlich ein Zertifikat auch in umgekehrter Richtung verwenden werden (OCPP Security Protocol 3). Dazu werden im Client ein Zertifikat und der zugehörige private Schlüssel hinterlegt. Der Server erhält unter den CA-Zertifikaten ebenfalls dieses Zertifikat oder ein Root-Zertifikat, das das Client-Zertifikat signiert hat. Damit kommt die TLS-Verbindung nur zu Stande, wenn auch der Server das Client-Zertifikat verifizieren kann.

Sie Können Zertifikate selbst erstellen, z.B. mit dem Programm OpenSSL, das kostenlos für Windows, wie auch für Linux erhältlich ist. Es folgen ein paar Beispiele unter Verwendung von OpenSSL. Die Beispiele verwenden in Verbindung mit dem Parameter -config eine Konfigurationsdatei, die im UTF8-Format gespeichert ist. Dies hat den Vorteil, dass im Zertifikat auch Umlaute und sonstige Unicode-Zeichen verwendet werden können. Die Konfigurationsdatei hat stets folgendes Format:

[req]
prompt = no
distinguished_name = dn
req_extensions = ext

[dn]
CN = Unsere Tiefgarage
emailAddress = info@tiefgarage-koeln.de
O = Tiefgarage Köln GmbH
OU = Abteilung 13
L = Köln
C = DE

[ext]
subjectAltName = DNS:tiefgarage-koeln.de,DNS:*.tiefgarage-koeln.de
         

Erstellung eines privaten Schlüssels rootCA.key für ein Root-Zertifikat:
openssl genrsa -des3 -out rootCA.key 4096

Erstellung eines selbst-signierten Root-Zertifikats rootCA.crt unter Verwendung des oben erstellten privaten Schlüssels rootCA.key und der Konfigurationsdatei rootCA.cnf (der Parameter -days gibt an, wieviele Tage lang das Zertifikat gültig ist):
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 365 -out rootCA.crt -config rootCA.cnf -utf8

Erstellung eines privaten Schlüssels client.key für ein Client-Zertifikat:
openssl genrsa -out client.key 2048

Erstellung eines Certificate Signing Requests (CSR) client.csr für ein Client-Zertifikat unter Verwendung des oben erstellen privaten Schlüssels client.key und der Konfigurationsdatei client.cnf:
openssl req -new -key client.key -out client.csr -config client.cnf -utf8

Erstellung eines Client-Zertifikats client1.crt, das mit dem obigen Root-Zertifikat rootCA.crt und dem zugehörigen privaten Schlüssel rootCA.key signiert wird (der Parameter -days gibt wieder an, wie lange das Zertifikat gültig ist):
openssl x509 -req -in client.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out client.crt -days 365 -sha256