It is often the wish of our customers and partners to be able to receive the work results of WZR as electronic versions. This has above all the advantage of shortening the time span between order placement and (preliminary) delivery of the results. This inevitably raises the question of a secure transmission of the data. The simplest way is transmission by encrypted e-mail. However, this method is not always available. On the one hand, this can be due to non-existing e-mail certificates, and on the other hand, it can fail due to size restrictions for e-mails.

We solve both problems with our data exchange service secured by Let’s Encrypt certificate. This guarantees strong encryption for the transport of your data and you can be sure to be connected to the right server.
Our identity verification and server certificate signing were signed by Let’s Encrypt.

Data exchange via our encrypted website is the easiest way for you to receive your data. You will receive the access data to the data exchange system from us.

Our employees can optionally protect the provided data with a password and limit the download period. A timely download of the data is therefore advisable.

Many people consider the encryption of e-mails to be too complicated and unnecessary. Of course, the technology involves a certain degree of complexity, but the end user of modern mail programs no longer notices any of this. We have compiled the most important questions and background information here and hope to convince you of the advantages of secure communication.

E-mails are like postcards…
… or do you send your sensitive company data on postcards?

E-mail is a convenient means of communication. Since it is quick and easy to use, sensitive information or documents are also often sent this way. But what actually happens to the e-mail once it has left your company premises and before it reaches the recipient? Unfortunately, this cannot be predicted exactly. The decentralized architecture of the Internet can route the message once around the world. Keep in mind that an email in plain text can be read, copied or altered like a postcard by any system through which it is routed. Even if you don’t appear to be the focus of virtual attacks, automated systems allow an attacker to evaluate large amounts of data in a short period of time. The information tapped in the process can mean long-term and often unnoticed damage to your company.

Encryption is standard…
… or do you not use envelopes?

Public key encryption” has become a mature standard in recent years. Practically every current e-mail program has the necessary functions. Therefore, you do not need any additional software. All you need is a valid certificate for your e-mail address.

An envelope is made of paper…
… and what is a certificate for e-mail encryption?

A digital certificate consists of information about you and your organization and your personal key pair. The key pair consists of the “private” and “public” keys. You can think of these simply as a salad of numbers and letters.

Your signature: In real life, you would sign a letter to assure that it is from you. Similarly, you can “digitally sign” your emails using the certificate. The recipient can use the signature to check whether the e-mail has been tampered with and receives your public key via the signature. An e-mail can be signed without encrypting it. This corresponds to a signed postcard.

Your envelope: The public key represents a kind of (return) envelope. With the public key of another person you can encrypt an e-mail to this person. Figuratively speaking, you pack your message in an envelope. The special feature is that this envelope can only be opened with the private key of the recipient.

You can buy envelopes…
… certificates too, but is there another way?

The advantage of commercial certificate issuers (e.g. Trustcenter, VerySign, Deutsche Telekom, …) is the integration of their root certificates into common software. The validity of personal certificates is checked on the basis of the root certificates and some other techniques. In addition, these certificate authorities verify the identity of the requesting person/organization in the real world. This form of certificates is particularly suitable if you want to communicate with a wide public.

There are also free certification organizations whose root certificates have not yet been incorporated into current software (e.g. CAcert).

The WZR also operates its own “Public Key Infrastructure” (PKI). This primarily covers our own corporate area. This means that our customers, partners and suppliers must first add our root certificate to their list of trusted root certification authorities. After that, the personalized certificates of the WZR employees are accepted as valid. This way we can issue you a free certificate and effectively protect your e-mail traffic.

Complicated theory…
… is it easy to use in practice?

Yes, the practice requires only a few steps and after that e-mails can be easily signed and encrypted. The necessary steps are basically the same for any email software. An elegant approach is to set up a central, automated system (e.g. e-mail gateway).

You obtain a certificate or receive one from the WZR on request.
Your certificate for your own e-mail address is to be integrated into your e-mail program.
Import our root certificate into your list of certification authorities.
Exchange of the public keys:
You will receive a digitally signed e-mail from us. This signature is assigned to exactly one of our employees and contains his or her “public key”.
For your part, you reply with a digitally signed e-mail.
Exchange of encrypted e-mails:
Receiving: your e-mail program automatically decrypts the messages when you open them.
Sending: Before sending, you may have to click on encrypt. However, all mail programs known to us offer an automatic function for this.

If you have any technical questions, our IT department will be happy to assist you.

Act now and protect your business-relevant data from the eyes of unknown persons and organizations!

A PKI is a very good basis for the use of asymmetric encryption systems. With its strictly hierarchical structure, it serves to map a system of trust relationships. In practice, these relationships are documented via certificates. At the top of the hierarchy is the so-called root certificate. This is used to sign subordinate certificates and thus confirm the identity of the respective applicant. The root certificate therefore “trusts” the signed certificate. If you or your software trust the root certificate, then you automatically trust its subordinate certificates as well.

Why is the trust relationship between certificates so important?
The reason lies in the elementary relationship between encryption and the identities of the communication partners. When you receive an encrypted message, you have to make sure that it comes from the right sender and that the sender data has not been falsified. In practice, this is guaranteed by the digital signature. In addition to encryption, this is the second important function of a certificate.

Certificate Authority (CA)

A CA manages a PKI and handles the signing of certificate requests. It also provides the public part of your root certificate. The public/commercial certificate authorities (e.g. TC TrustCenter, VerySign, Post, etc.) verify the applicant’s data in real life and have the advantage of wide distribution of your root certificates in popular software. For example, if you surf to the website of your local bank, your web browser will usually trust the certificate immediately because the signing root certificate is already known to your software.

On the other hand, if you call up a website that is protected by a non-commercial CA (e.g. CaCert), an internal PKI of the organization or a self-signed certificate, you will receive a security warning. At this point you have to decide whether you want to trust the corresponding certificate or not. In case of existing PKIs, you can import the corresponding root certificates into your software. Then your software behaves exactly as with a purchased certificate.

The strength of the encryption is identical for commercial and non-profit certificates or depends on the parameters specified when the certificate was created. The significant difference lies only in the acquisition of the trust position.

Structures in WZR

We rely on a mixed operation of public certificates and internal PKI. In the area of secured web pages and encrypted FTP, certificates from commercial providers have proven their worth. Since we are addressing a broad public here, warning messages about compromised security would only have a disturbing effect and cause uncertainty.

We use our own PKI for e-mail and internal systems. In order to initiate e-mail security between us and our customers and partners, it is necessary to exchange signed e-mails anyway. Transmitting our root certificate in addition is only a very small additional effort compared to a commercial solution. In addition, we can provide our communication partners with a free certificate if they do not have a PKI or an e-mail certificate.

In order for your computer to trust WZR’s certificates, you must first trust our certification authority. To do this, first install our root certificate (also called root certificate) and then, as required (see step 4), our intermediate certification authorities.

The following instructions show the installation using Windows XP as an example, but also apply in a similar form to other variants of Windows (e.g. Vista, Windows 7). The certificates are integrated into the certificate management of Windows. Many programs (e.g. Outlook, Internet Explorer) use this central collection point for their security techniques. Other software (e.g. Firefox, Thunderbird), however, brings its own certificate management. In this case you should include our certificates in the corresponding certificate management of the software you use.

Carrying out the installation

Step 1:

Option A:
You have the individual certificates as files with the extension .crt. Open the certificate files you have by double-clicking on them. Start with our root certificate (WZR_root_ca_2010.crt).

Option B:
You have received a certificate store from us (e.g. your_contact.p7b). Open this file with a double click. A Microsoft Management Console (MMC) with the certificate snap-in opens. Expand the folder structure on the left side until you see the list with the certificates in the right part of the MMC. Double-click on the certificate with the name “WZR – Common Root CA – 2010”.

Step 2:

Click on the “Install Certificate…” button in the certificate display (General tab).

Step 3:

Use the Certificate Import Wizard to maintain the certificate in the Windows Certificate Manager. As a rule, you only need to click on “Next” until you can complete the process by clicking on “Finish”. When installing our root certificate “WZR – Common Root CA – 2010” there is an additional security warning. To ensure that you do not install a fake certificate, compare the fingerprint given in the warning with the following characters (spaces and upper/lower case may vary):

Fingerprint “WZR – Common Root CA – 2010” (sha1):
D1:AE:F2:8E:00:11:06:0B:3C:35:C6:D2:0A:A2:FC:41:0C:9F:49:DA

If the fingerprints match, confirm by clicking “Yes”. The fingerprint is no longer requested for the intermediate certification authorities, since these are derived from the root certificate and are therefore already trusted. If you still want to check them, you can compare the fingerprints in the certificate view under the “Details” tab. They are:

Fingerprint “WZR – SubCA Internal Users – 2010” (sha1):
C5:9F:2B:B2:DC:33:0E:7E:D7:3F:A4:B2:0C:76:26:47:2F:DD:EB:ED

Fingerprint “WZR – SubCA External Users – 2010” (sha1):
E6:7C:36:9A:78:92:B9:12:F4:E2:51:D1:68:4C:8A:DC:E8:A0:0A:81

Step 4:

Repeat steps 1-3 for our intermediate certification authorities. Since specific intermediate certification authorities are assigned to individual task areas in our company, you only need the intermediate certificates of the WZR services you use. This separation offers the advantage that we can provide specially adapted certificates to different services.

Related documents

If you have received a personal certificate from us, you might be interested in the “Install my certificate” guide.

known problems

In some cases the certificate import wizard assigns our root certificate “WZR – Common Root CA – 2010” incorrectly. Then the certificate does not end up with the “trusted root CAs” but with the “intermediate CAs”. Consequently, certificates issued by the WZR are considered invalid. In the article “Checking the Certification Authorities” we show you how to check if the root certificate is installed correctly.

Fix the problem by removing the root certificate from the certificate store for intermediate certification authorities. Perform the installation again according to these instructions. In step 3, select “Save all certificates in following store” when prompted for the certificate store. Then click “Browse” and select “Trusted Root Certification Authorities” from the list. Then continue with “Next” as described above.