8.3.1. SSL/TLS X.509 Certificates

8.3.1.1. Background

The dashboard shall be reachable encrypted via HTTPS. So the dashboards needs a X.509 certificate and the corresponding private key.

Furthermore, the clients have to trust the certificate which the dashboard uses. In X.509 this is done via a trust chain.

8.3.1.2. Certificate Formats

DER

Binary X.509 certificate.

PEM

ASCII armored Base64 encoded DER certificate.

A PEM text file can contain more than one element but not all software is able to handle such files. (CRLs, certificate revocation lists, must not be in a file with several elements. Each CRL needs its own file.)

Common file extensions:

  • .pem

  • .crt

  • .crl

PKCS#7

Binary format which can contain several certificates.

Common file extensions:

  • .p7b

  • .p7m

  • .p7s

PKCS#12

Binary format which can contain a password protected private key and a certificate chain.

Common file extensions:

  • .p12

  • .pfx

8.3.1.3. Retrieve the Root Certificate of a Webserver (Axivion Dashboard Server) with a Browser

Microsoft Edge (Chromium) on Windows 10

  • Navigate to a website on the server whose root certificate you want to store.

  • Click on the lock symbol in the address bar, then “Connection is secure”.

  • Click on the certificate icon (“Show certificate”).

  • In the opened certificate window, the tab “Certification Path” shows the chain of the certificate from the root certificate down to the servers certificate. Note: if the client cannot find a certificate going up from the servers certificate to the root certificate, only a part of the certificate chain is shown.

  • Select the certificate you want to store and click the button “View Certificate”.

  • In the newly opened certificate window, on the tab “Details”, click the button “Copy to File…”

  • As format, choose “Base-64 encoded X.509 (.CER)” which is the PEM format.

8.3.1.4. Root Certificates and Self-Signed

All X.509 certificates need an issuer (parent in the hierarchy). This also holds for root certificates which are the top of their hierarchy. So a root certificate is its own issuer and thus signs itself. This means that every root certificate is and has to be self-signed.

It is not necessary that in the TLS handshake the server sends the root (= self-signed) certificate to the client (because the client has to know the root certificate in its own truststore to trust it). However, we recommend to put the root certificate in the certificate chain the server delivers anyway because in certain circumstances it makes the retrieval of it easier (to install it on a client - after verifying it).