Certificate infrastructure

Before creating the server and client certificates, the following preliminary consideration is necessary. There are 3 options to obtain the certificates:

  • Self-signed certificates: in this case, each key owner confirms the details of the key. No additional infrastructure is necessary for issuing a certificate. You can determine the quality of cryptographic methods and the content of the certificate.

  • Self-administrated certificate publisher (Certificate Authority): in this case, you establish a self-administered certification body that issues all client and server certificates. As with self-signed certificates, you have full control over cryptographic standards and the content of the certificates.

  • Public certificate issuer: a provider of certification services issues the certificate.

The ImageMaster web service interface technically supports all options mentioned above. However, using client and server certificates from a public certificate issuer makes little sense for the ImageMaster web service interface, as it is an integration interface used by a few technical users or clients. In this case, you can store one or more server certificates directly in the clients. The client certificates must be stored on the server anyway to perform the authentication. This method, called certificate pinning, is the safest and most preferred usage method.

A direct storage of the server certificate on the client guarantees the highest possible level of security. Interference in the communication between the client and the server in the form of a man-in-the-middle attack would be possible only with a copy of the private key of one server.

Server certificates provided by public certificate authorities are recommended for operating web servers. In this case, the clients (usually web browsers) do not need to authenticate to the server via the TLS protocol, but the server must authenticate to the clients. Because there are many servers, the clients cannot recognize all server certificates. Instead, the clients have lists of all trusted certificate publishers and only trust server certificates shown to be issued by one of the trusted providers. The certificate provides the IP address or DNS name of the server to determine which server the certificate is valid for. This is considered conclusive proof of the server's authenticity.

Use self-signed certificates and self-managed certificate publishers for the implementation scenarios of the ImageMaster web service interface, as this offers the following advantages:

  • full control over the cryptographic properties of the keys and the used signature mechanism

  • full control over the properties of the certificate such as:

    • validity period

    • purpose of usage

  • no additional costs of certification services

  • no additional infrastructure required

  • obtaining a fake certificate issued by a (compromised) certification service provider is impossible

General certificate requirements

Certificates used in an ImageMaster environment must comply with the following rules:

  • The certificate must contain as commonName (=CN) your server’s host name. This may be “www.imagemaster.de” or “localhost” if you’re testing locally. This name must appear between the “https://” and the first slash “/” that follows. For example if the URL you’re trying to connect to is “https://www.imagemaster.de:8181/its/good”, the CN should be “www.imagemaster.de”.

    When creating your certificate with the keytool, your “first and last name” is asked. Provide your server’s host name here because the value requested is used for the CN entry.

  • The path of all root certificates must be valid, e.g. not expired. If you use a self-signed certificate, you will get a warning that the certificate is not from a trusted certificate authority, but for testing such a certificate will work.