SSL Certificate

SSL certificates are what enable websites to move from HTTP to HTTPS, which is more secure. An SSL certificate is a data file hosted in a website’s origin server. SSL certificates make SSL/TLS encryption possible, and they contain the website’s public key and the website’s identity, along with related information. Modern browsers require websites to use an SSL certificate to enable HTTPS before all features are enabled, and we have decided to only serve the KMD PlassData system from an HTTPS endpoint, so you MUST supply a valid SSL certificate as part of the installation if you want to enable access to the system from outside the server machine itself, which start out as single-user on https://dviserver.local

You can get more information about https and ssl certificates on i.e. wikipedia on https

It is your IT organisation that handles certificates on your network, and you will need to liase with them to have a useable certificate generated. You cannot do it yourself as the KMD PlassData certificate needs to be signed by a Certificate Authority (CA) that is trusted by the machines on your network. That can either be a CA put in place by your organisation and pushed to all PC’s, or it may be a public CA that is globally trusted through a certificate chain. If KMD PlassData is going to be accessed by “personal” devices, the organisation CA must be added to these as trusted, or a public CA must be used.

The KMD Plass Data server(s) are using four different endpoints, and you may choose to supply four different certificates (when running on separate servers) or a certificate with multiple server names enabled. Your IT organisation decides what is best/allowed in your situation.

If you are planning to deploy KMD Plassdata to a shared server at i.e. endpoint https://my-dvi-server.int, your certificate(s) must enable/accept:

  • https://my-dvi-server.int
  • https://client.my-dvi-server.int
  • https://api.my-dvi-server.int
  • https://ids.my-dvi-server.int

and this can be done by including X509v3 Subject Alternative Names as
DNS:my-dviserver.int, DNS:client.my-dviserver.int, DNS:api.my-dviserver.int, DNS:ids.my-dviserver.int

If you are planning for several environments like test, training and production on the same server, you may save yourself some trouble (but also a little lower security) by adding these endpoints to your certificate so that you only need to manage and renew one certificate for all endpoints, i.e.:

  • https://my-dvi-server.int
  • https://client.my-dvi-server.int
  • https://api.my-dvi-server.int
  • https://ids.my-dvi-server.int
  • https://test.my-dvi-server.int
  • https://client.test.my-dvi-server.int
  • https://api.test.my-dvi-server.int
  • https://ids.test.my-dvi-server.int
  • https://train.my-dvi-server.int
  • https://client.train.my-dvi-server.int
  • https://api.train.my-dvi-server.int
  • https://ids.train.my-dvi-server.int

Finally, a simple, but security-wise not recommended, solution is to issue a * certificate to https://my-dvi-server.int and name all sub-sites with dashes instead of dots, like https://client__-__ test.my-dvi-server.int as a * certificate only supports one level above root url.

Updated: