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. The quality of cryptographic methods and the content of the certificate can be freely determined.

  • Self-administrated certificate publisher (Certificate Authority): in this case, a self-administrated certification body is established, that issues all client and server certificates. Full control of cryptographic standards and content of the certificates is possible in this case as with the self-signed certificates.

  • Public certificate issuer: the certificate is issued by a provider of certification services.

The ImageMaster web service interface technically supports all options mentioned above. However, the usage of client and server certificates of a public certificate issuer makes little sense for the ImageMaster web service interface as it is an integration interface that is used by a few technical users or clients. In this case it is possible to store one (or several) 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 the 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, which are provided by public certificate authorities, are rather recommended for the operation of 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. As there are many servers, the clients cannot recognize all the server certificates. Instead, the clients have lists of all trusted certificate publishers and only trust server certificates which show that they were issued by one of the trusted providers. The IP address or DNS name of the server is provided in the certificate to determine for which server the certificate is valid. This is considered as 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 which are 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.