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
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.
