Certificates – Why and What for

In this article I would like to give you an insight into the topic “Securing the Internet-based exchange of information through certificates”. I’ll take a quick look back at the beginnings of the Internet and the use of protocols such as HTTP, SMTP, POP … and their encrypted transport via SSL or TLS. Above all, however, I would like to explain to you how you can use public certificates with Univention Corporate Server to secure your data transfer or also how you can create trustworthy certificates by yourself with Let’s Encrypt. Completely secure and free of charge on top.

In the early days of the Internet and its precursors, connecting a new location (mainly universities) was still a complex undertaking. One trusted in the honesty and sincerity of everyone involved, because after all it was a matter of achieving something together. At that time, security in communication between the locations was less of an issue and the communication protocols used simply sent plain text.

With the increasing spread of the Internet, the need became apparent for communication to take place in such a way that it could not be seen by third parties. One approach that prevailed back then and has been maintained to this day was to continue to use the known and widely used protocols such as HTTP, SMTP, POP, IMAP, FTP, etc., but to build an encrypted transport option around them. This encrypted transport of the network packets was first called SSL (Secure Socket Layer) and in later iterations TLS (Transport Layer Security).

SSL / TLS Certificates – An Integral Part of Network Communication

Today SSL / TLS is an integral part of network communication – whether in the company or home network or across the Internet.

For encryption SSL / TLS works with so-called certificates. A recipient (e.g. a web server) with whom I want to communicate is in possession of a certificate file and a secret, cryptographic key. The certificate file contains among other things cryptographic information that allows me as the sender to encrypt my message packets. Message packets encrypted in this way can then only be decrypted with the secret (private) key belonging to the certificate. The messages cannot be read by third parties.

Such a certificate also always contains information from which certification authoriy and for which recipient (subject) the certificate was issued. As a sender, this gives me good clues as to whether I am really talking to the right recipient. Here is an extract from the currently valid certificate for “univention.de”:

Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA G1
Subject: CN = univention.de
X509v3 Subject Alternative Name:
DNS:univention.de, DNS:www.univention.de

Screenshot: Create Cert CLI

Trustworthy or Not? How to Distinguish Certificates from Each Other

There is one small catch: With the right SSL tool, everyone can create their own certificates and issue them for “google.com”, “their-bank.de” or “univention.de” and in the worst case intercept and decrypt communication. It is therefore essential to be able to distinguish between trustworthy and untrustworthy certification authorities. In the case of the trustworthy ones, we believe that they only issue certificates to authorized recipients with the best of intentions and with a lot of effort and security mechanisms.

The most commonly used applications that need to check these things are web browsers like Mozilla’s Firefox, Google’s Chrome browser, Apple’s Safari or Microsoft’s Edge browser. These browsers or their underlying operating systems come with a list of trustworthy certification authorities. All certificates issued by these certification authorities are usually trusted automatically – as long as the “subject” matches the website it is accessing and the certificate has not expired. (Certificates are only valid for a certain time).

UCS CA and Self-signed Certificates

UCS makes use of certificates in many places to cryptographically secure and encrypt network communication between end devices and UCS systems, but also between the UCS systems themselves.

There is one hurdle we need to overcome: How do we get the certificates? Especially if we do not know in advance the name (subject) to which the certificates must be issued? After all, UCS systems can be named at will.

As mentioned above, anyone can generate certificates with the right SSL tools – and that’s exactly what we make use of. A Certificate Authority (CA) for the UCS domain is automatically set up on each UCS master. This authority receives a so-called root certificate, which on the one hand checks and provides identification for the certificate authority itself and on the other hand can be used to issue further certificates. For other UCS systems in the domain, this happens automatically when joining the domain. UCS also comes with a command line tool, which can be used to easily create additional certificates or list and revoke existing ones.

As a result, all services offered by UCS that support SSL / TLS (e.g. the web server, LDAP, listener / notifier, mail server etc.) are directly equipped with a suitable certificate and can communicate in encrypted form.



Test and Use UCS Core Edition

Univention Corporate Server (UCS) is available as an ISO image for installation or as a preinstalled, virtual machine image. With these images, you can instantly use UCS for free as a UCS Core Edition.

Download Now

Trust UCS CA Certificates or Use Other Certificates

However, since a separate certificate authority is set up with each UCS domain, these are not part of the list of trustworthy certificate authorities of browsers and operating systems, which usually results in an unpleasant warning message:


To solve this, we now have two options:
a) We teach our devices and applications to trust the UCS CA.
b) We replace, for example for the web server, the self-signed certificate with one that was issued by a public certificate authority that the devices and applications trust innately.

For variant a) there is a suitable guide in the Univention forum to solve this for Windows clients via group policies.

And if things need to go fast: A temporary variant independent of the operating system is also described, e.g. for test systems or if you only have a few end devices in the environment:

Certificates from Public Certificate Authorities

For variant b) we need suitable certificates that have been issued by a public, trustworthy certificate authority. The process differs slightly from certificate authority to certificate authority. In the end, however, you get a handful of files that you have to copy to the UCS system. They should include at least (in PEM format):

  • The public certificate itself (e.g. “domain.crt”)
  • The corresponding secret key (e.g. “private.key”)
  • Usually a certificate chain that the server can also deliver in order to be able to trace the trustworthiness via so-called sub- or intermediate CA certificates up to the root certificate of the CA (e.g. “chain.crt”).

UCS now offers suitable UCR variables for most services in order to store the certificate files. This means that I don’t have to replace the existing self-issued certificates, but can simply change the configuration options to the new certificates – and this individually for each service. This is described in more detail in the article “Using your own SSL certificates“.

Screenshot of UCR Variables RADIUS in UCS


Secure and Affordable – Create Your Own Certificates with Let’s Encrypt

It is even easier with the Let’s Encrypt app from the Univention App Center. Let’s Encrypt started at the end of 2015 to make SSL / TLS encryption the norm on the Internet. To this end, various organizations around the Electronic Frontier Foundation (EFF) and the Mozilla Foundation have come together to obtain and set up certificates free of charge and much easier than before. Let’s Encrypt has meanwhile achieved a remarkable success story.

Screenshot of the App Let's Encrypt in the Univention App Center


The Let’s Encrypt app from the Univention App Center starts there and independently takes care of obtaining current, valid certificate files from Let’s Encrypt CA, stores them in the server’s file system and optionally configures the services for the web server (Apache2 ), the IMAP server (Dovecot) and the SMTP server (Postfix) accordingly.

Please feel free to write a comment if you have any questions or comments on the topic.

Use UCS Core Edition for Free!
Download now


  1. Landon Wubbels

    July 25, 2020 at 07:11

    When will the Univention Let’s Encrypt App support DNS validation?

  2. Michael Grandjean

    July 30, 2020 at 11:43


    there is no precise roadmap to add DNS validation to the Let’s Encrypt App. The challange is, that in this case UCS would also need to be the authoritative nameserver for the domain – not only internally but also for everyone else on the internet. This is usually not a common setup and would require additional effort for everyone who runs a UCS system. Without further adjustments, not only the the Let’s Encrypt DNS challenge could be queried by anyone, but also all other DNS information of the UCS domain. So we are quite far from an easy-to-use two-or-three-clicks installation for the Let’s Encrypt certificate and this makes the whole thing more complex than the current version of the App which only offers the HTTP validation.

  3. Landon Wubbels

    January 1, 2021 at 00:48

    I know it’s been a while since my previous comment Michael, but it’s possible to delegate a subdomain or use a second domain for DNS challenges. And fully supported by acme.sh.


Leave a Reply

Your email address will not be published. Required fields are marked *