Univention, zarafa with an Official certificate

mail

#1

In the past we used an Yaffas Zarafa mail environment, with an Commodo Certificate.
Now we set-up an Univention domain, and migrate our mail to an dedicated unc zarafa mail server.
Everything works fine, without the Commodo Certificate.

We create an DNS Alias for the mail server, and this works fine, when we connect to the server with the Alias name.
We receive only still the certificate security notfication. So we will bind the Commodao certifcate, to remove this error message.
For example the mail server name is
XXXMail.OurDomain.nu
The Commodo certificate CN is
MailXXX.OurDomain.nu

When I configure the SSL the Appache2 certificate settings, the error message on the web interface disappears,
when I apply the same settings for the Zarafa environment, I’m unable to log-on to zarafa.
To set-up SSL I follow wiki.zarafa.com/index.php/Zarafa … rtificates while I didn’t find Univention SSL documentation related to Zarafa.

Is there anyone that, know more about Univention SSL, in combination with Zarafa? And can tell me, how I can fix this issue?

Thanks!!


#2

Hello Goudulf,

I think thats more an univention topic than really related to Zarafa. I found the following in the Univention knowledge base for using external certs: sdb.univention.de/content/15/230 … cates.html


#3

Hey,

using different certificates for Zarafa involves a number of components:

[ol][li]The web server Apache (used for the Zarafa WebApp and Z-Push for ActiveSync with mobile devices)[/li]
[li]The Postfix SMTP server for receiving incoming and delivering outgoing mails[/li]
[li]The “zarafa-gateway” process (for IMAP and POP3 access)[/li]
[li]The “zarafa-ical” process (for calendar access via CalDAV)[/li]
[li]The “zarafa-server” process (for MAPI access with Outlook and for general communication between the “zarafa-server” process and all of the other “zarafa-*” processes)[/li][/ol]

The support database article Felix Bartels linked to describes how to use a custom certificate with the first two daemons mentioned above, Apache and Postfix.

Configuring certificates for the other deamons can be done in a similar way by setting UCR (Univention Config Registry) variables. The corresponding variables are:

[ul][li]For the “gateway” process: “zarafa/cfg/gateway/ssl_certificate_file” and “zarafa/cfg/gateway/ssl_private_key_file”[/li]
[li]For the “ical” process: “zarafa/cfg/ical/ssl_certificate_file” and “zarafa/cfg/ical/ssl_private_key_file”[/li]
[li]For the “server” process: “zarafa/cfg/server/server_ssl_key_file” and potentially “zarafa/cfg/server/server_ssl_ca_file”[/li][/ul]

Note that the gateway and ical processes require their certificates and keys to reside in two separate files whereas the server process requires them to be concatenated into a single file. The comments in corresponding configuration files in “/etc/zarafa” do mention this, but it’s not entirely clear just from reading the config registry variables’ descriptions. The server does require a CA file to be set as well (which the other two processes don’t need); you may have to add your public CA’s file there.

Kind regards,
mosu


#4

I follow up the recomendations, and it works fine with IE, or Edge.
But when I run a check I receive the following.

Error while checking the SSL Certificate!!
Unable to get the local issuer of the certificate. The issuer of a locally looked up certificate could not be found. Normally this indicates that not all intermediate certificates are installed on the server.
We advise you not to submit any confidential or personal data to this website because a secure connection could not be established with this website.
SSL Certificate is not expired
Site is listed in the certificate
Organisation details are not listed
Encryption strength is at least 2048-bit
Signature Algorithm is strong
Accepting only high encryption cipher suites
No connection upgrade to 128-bit for old browsers
No Extended Validation on company details
No Debian weak key present
No known security issues for this Certificate Authority

How can I solve this on my UNC server?


#5

This usually means that the CA that signed the certificate isn’t trusted by the browser/the operating system. This usually means that it’s a self-signed certificate.

Another possibility is that it is one from one of the official CAs, but that it wasn’t signed by the CA itself but by an intermediate.

Why don’t you tell us more about what exactly you’re doing?

[ul][li]What does “run a check” mean? Did you execute some command, if so, what was that command (including all options)?[/li]
[li]What is the certificate you’ve tried to install? Post the output of “openssl x509 -in <yourCertFileName.pem> -noout -text” here.[/li]
[li]Have you restarted all Zarafa services as well as the web server process after the installation of the certificate?[/li][/ul]

mosu