Support desk FAQ: Hyarchis DMS and certificates

Our support desk has recently been receiving lots of questions about the use of SSL certificates in Hyarchis DMS. Since Hyarchis DMS 2015 (v3), the use of SSL certificates has been mandatory; since patch 5, it must also be possible to validate these certificates. In this blog entry, I’ll explain why we insist on the use of SSL certificates and how you can provide your DMS with the right certificate.

How did it work previously?

Up to and including Hyarchis 2012r2 (v2.4.1), communication between the client and server used the .NET Remoting protocol, the standard method for enabling communication between services within the .NET Framework. This protocol is mainly intended for communication between services within an organisation, so in a trusted environment. As part of its .NET Framework 3.0, Microsoft introduced Windows Communication Foundation (WCF), the successor to .NET Remoting. With WCF, it was assumed that the client and server would not be located within the same trusted environment, meaning that trust between these two would have to be established in some other way. That’s when SSL certificates made their appearance.

SSL certificates

The SSL certificate authenticates, among other things, the identity of the server. When a client application connects to the Hyarchis server, the client will first request the certificate. In this certificate, the client expects to find an ID that matches the server name recorded in the client connection profile. So if the client initiates a connection with “DMSSERVER01”, this ID must appear in the certificate too. The certificate is the server’s proof of ID that shows the client that the server really is who it says it is and that the client is not connecting to another server “impersonating” the Hyarchis server (this is known as a “man-in-the-middle attack”). Matters become more complex when, for example, a load balancer is placed between client and server(s), in which case the ID of the load balancer will generally be recorded in the client connection profile. Given that the name in the connection profile must match the name in the server certificate, the Hyarchis servers must be provided with the certificate issued in the name of the load balancer.


The server’s “proof of ID” must, however, be trustworthy, the same way that a Dutch passport, for example, is more likely to create trust about the identity of the passport holder than, say, a passport issued by Somalia (the most corrupt country in the world, according to Transparency International [2015]). This means that the certificate must be issued by a trusted party. There are several options open to you:

  1. Purchase a certificate from a public Certificate Authority (CA) like VeriSign, Comodo or GlobalSign, to name a few. Most businesses purchase their certificates from the same company and so there is a good chance that your system administrator already has an agreement with one of the above, making it easy to request a new certificate. Certificates issued by public CAs are trusted both inside and outside their own network domains. In most cases, the Hyarchis server is not connected directly to the Internet, so there is generally no need to have a certificate from a public CA.
  2. Request a certificate from a private CA. In general, large companies have their own “private” (in-house) certificate authority that can issue certificates that are trusted within the company’s own network domain, meaning they can only be used in this domain.
  3. Request a Hyarchis certificate. You can ask Hyarchis for a certificate for use on your server. Hyarchis certificates, which are signed with the Hyarchis private key and trusted by Hyarchis applications, can only be used for client-server connections between Hyarchis components.

I hope that this has helped clarify a few matters concerning the use of SSL certificates in combination with Hyarchis DMS. Feel free to contact us if you have any questions. We’d be happy to help.