Erfahrungen mit den neuen experimental Zarafa SPK 0.4.x

[Jdo2002]

@Cookie24
Frage1: Zarafa ist ein Serverprodukt und läuft daher die ganze Zeit und erzeugt IO, daher funktioniert der Ruhezustand nicht
Frage2: Der E-Mail Server wird von Zarafa genutzt um Mails zu verschicken. Daher benötigst du ihn. Was du nicht benötigst ist das Roundcube.

 

[bolzerrr]

Hi Jdo2002,

gibt es bereits Aussagen ob es das Pakt auch für die ds214play geben wird?
Würde gerne wissen ob sich das warten lohnt oder Roundcube drauf muss ;-)

Viele Grüße

 

[andraesh]

SegFault seit Umstellung auf Attachements ausserhalb mysql?

Hi,
ich habe heute auf meiner DS213j mit aktuellster Firmware 3810 und Zarafa 0.4.2_armada370 umgestellt, dass die Attachements ausserhalb der Datenbank gespeichert werden, und dann die MySQL Datenbank gesichert, gelöscht und neu zurückgespielt, um den benutzten Speicherplatz wieder freizugeben.

Das ganze hat auch den ganzen Abend funktioniert, aber jetzt crashed zarafa-server mit einem SegFault:

Tue Dec 3 22:29:45 2013: Starting zarafa-server version 7,1,7,42779, pid 9173
Tue Dec 3 22:29:45 2013: Listening for priority pipe connections on /var/run/zarafa-prio
Tue Dec 3 22:29:45 2013: Listening for pipe connections on /var/run/zarafa
Tue Dec 3 22:29:45 2013: Listening for TCP connections on port 236
Tue Dec 3 22:29:46 2013: Connection to database 'zarafa' succeeded
Tue Dec 3 22:29:46 2013: zarafa-licensed is running, but no license key was found. Not all commercial features will be available.
Tue Dec 3 22:29:48 2013: Loading searchfolders
Tue Dec 3 22:29:49 2013: Startup succeeded on pid 9252
Tue Dec 3 22:29:54 2013: Caught SIGSEGV (11), traceback:
Tue Dec 3 22:29:54 2013: 0x000000000ba290 /usr/local/zarafa/bin/zarafa-server(_Z7sigsegvi+0x80) [0xba290]
Tue Dec 3 22:29:54 2013: 0x0000004203cc10 /lib/libc.so.6(__default_sa_restorer_v2+0) [0x4203cc10]
Tue Dec 3 22:29:54 2013: 0x0000004208229c /lib/libc.so.6(cfree+0x28) [0x4208229c]
Tue Dec 3 22:29:54 2013: 0x00000041b4a51c /usr/local/zarafa/lib/libmysqlclient.so.16(+0x7251c) [0x41b4a51c]
Tue Dec 3 22:29:54 2013: 0x00000041b4bcd4 /usr/local/zarafa/lib/libmysqlclient.so.16(gzclose+0xa8) [0x41b4bcd4]
Tue Dec 3 22:29:54 2013: 0x000000001b8808 /usr/local/zarafa/bin/zarafa-server(_ZN16ECFileAttachment22SaveAttachmentInstanceEjjiPh+0x178) [0x1b8808]
Tue Dec 3 22:29:54 2013: 0x000000001b7460 /usr/local/zarafa/bin/zarafa-server(_ZN19ECAttachmentStorage14SaveAttachmentEjjbiPhPj+0x1c4) [0x1b7460]
Tue Dec 3 22:29:54 2013: 0x00000000106954 /usr/local/zarafa/bin/zarafa-server(_Z10WritePropsP4soapP9ECSessionP10ECDatabaseP19ECAttachmentStorageP10saveObjectjbjS8_PbP11_s_FILETIMESB_+0x1634) [0x106954]
Tue Dec 3 22:29:54 2013: 0x0000000010a61c /usr/local/zarafa/bin/zarafa-server(_Z10SaveObjectP4soapP9ECSessionP10ECDatabaseP19ECAttachmentStoragejjjjjP10saveObjectS8_jPb+0x36c) [0x10a61c]
Tue Dec 3 22:29:54 2013: 0x0000000010a6e8 /usr/local/zarafa/bin/zarafa-server(_Z10SaveObjectP4soapP9ECSessionP10ECDatabaseP19ECAttachmentStoragejjjjjP10saveObjectS8_jPb+0x438) [0x10a6e8]
Tue Dec 3 22:29:54 2013: 0x0000000010bac0 /usr/local/zarafa/bin/zarafa-server(_Z14ns__saveObjectP4soapy17xsd__base64BinaryS1_P10saveObjectjjP18loadObjectResponse+0x860) [0x10bac0]
Tue Dec 3 22:29:54 2013: 0x000000002b2a90 /usr/local/zarafa/bin/zarafa-server(_Z25soap_serve_ns__saveObjectP4soap+0xdc) [0x2b2a90]
Tue Dec 3 22:29:54 2013: 0x000000000ca8e8 /usr/local/zarafa/bin/zarafa-server(_ZN14ECWorkerThread4WorkEPv+0x3e4) [0xca8e8]
Tue Dec 3 22:29:54 2013: 0x0000004003ee64 /lib/libpthread.so.0(+0x6e64) [0x4003ee64]
Tue Dec 3 22:29:54 2013: When reporting this traceback, please include Linux distribution name, system architecture and Zarafa version.

Irgend eine Idee, woran das liegen kann? Ich glaube zwar nicht, dass irgendwelche wichtigen Mails verloren gehen, wenn ich das Backup von gestern einspiele, aber die Performance mit Outlook ist subjektiv besser als vorher.

Edit: Sieht aus, als würde das Problem mit dem Anlegen des ersten neuen Attachements zusammenhängen. Alle Dateien im Filesystem der Attachements sind von heute nachmittag. Nur eine hat das Datum des Crashes:

DiskStation> pwd
/volume1/homes/zarafa/4/19
DiskStation> ls -l 39*
-rw-r--r-- 1 root root 23418 Dec 3 13:00 394
-rw-r--r-- 1 root root 0 Dec 3 22:29 3994.gz

Edit2: Wenn ich "attachement_compression = 0" setze, werden die Mail von fetchmail geholt und Zarafa crashed nicht.
Die Attachements werden dann umkomprimiert abgelegt.

Merci,
Andreas

 

[andraesh]

Kann den Beitrag leider nicht mehr editieren, daher hier:

Edit3:
Das Problem ist vermutlich, dass auf der Synology das Busybox gzip zum Einsatz kommt. Das kennt keine verschiedenen Komprimierungsstufen, wie mittels "attachment_compression" konfigurierbar:

DiskStation> gzip --help
BusyBox v1.16.1 (2013-11-06 05:34:59 CST) multi-call binary.

Usage: gzip [OPTIONS] [FILE]...

Compress FILEs (or stdin)

Options:
-c Write to stdout
-d Decompress
-f Force

Für mich erstmal unerheblich, da ich die Attachements lieber unkomprimiert ablege, um die DS213j nicht mit der Komprimierung zu beschäftigen.

Andreas

 

[tkoester]

Edit2: Wenn ich "attachement_compression = 0" setze, werden die Mail von fetchmail geholt und Zarafa crashed nicht.
Die Attachements werden dann umkomprimiert abgelegt.

Mein altes Thema.

http://www.synology-forum.de/showthread.html?44463-Erfahrungen-mit-den-neuen-experimental-Zarafa-SPK-0.4.x&p=360498&viewfull=1#post360498
http://www.synology-forum.de/showthread.html?38556-Zarafa-Datenbank-optimieren&p=337918&viewfull=1#post337918

Ceterum censeo...

Das Problem ist vermutlich, dass auf der Synology das Busybox gzip zum Einsatz kommt. Das kennt keine verschiedenen Komprimierungsstufen, wie mittels "attachment_compression" konfigurierbar:

Würde mich wundern, wenn Zarafa die Attachments durch gzip piped. Zumindest ist die zlib eine Voraussetzung für das Bauen von Zarafa.

EDIT: Siehe provider/libserver/ECAttachmentStorage.cpp - da wird mit gzopen via zlib ein File zum Abspeichern des Attachments aufgemacht. Passiert also alles ohne Zutun der Busybox oder sonstiger externer Programme.

Viele Grüße,
Thorsten

 

[MasterSam]

Allerdings funktioniert Apple Mail auf dem Mac immer noch nicht.
Ich habe schon alles versucht, u.a. die DS neu gestartet, den Zarafa Server neu gestartet, IMPA für den User neu aktiviert,... hat alles nichts gebracht.
Mail.App sagt der Server antwortet nicht und im gateway logfile steht:

Sat Sep 14 12:44:38 2013: [ 9286] POP3/IMAP Gateway will now exit 
Sat Sep 14 12:44:38 2013: [ 9286] POP3/IMAP Gateway shutdown complete 
Sat Sep 14 12:45:17 2013: [15150] Starting zarafa-gateway version 7,1,5,42059 (42059), pid 15150 
Sat Sep 14 12:47:46 2013: [15150] Starting worker process for IMAPs request 
Sat Sep 14 12:47:47 2013: [25499] Unable to negotiate SSL connection 
Sat Sep 14 12:47:47 2013: [25499] Client 192.168.178.230 thread exiting 
Sat Sep 14 12:47:47 2013: [15150] Starting worker process for IMAPs request 
Sat Sep 14 12:48:57 2013: [25543] Unable to negotiate SSL connection 
Sat Sep 14 12:48:57 2013: [25543] Client 192.168.178.230 thread exiting

Es scheint also irgendein Problem mit der SSL Verbindung zu geben...

Ich möchte das mal nach oben holen - leider habe ich genau das gleiche Problem (ebenfalls ein StartCom-Zertifikat, ebenfalls keine Probleme mit der stabilen Version, ebenfalls die Option ssl_enable_v2 = yes in der gateway.cfg schon erfolglos getestet). Ich halte das für ein gravierendes Problem, da die meisten irgendeinen User mit IMAP haben werden und eine unverschlüsselte Verbindung kann ja keine Lösung sein (immerhin funktioniert die einwandfrei). Falls ich irgendwelche Informationen beitragen kann tue ich das gerne, eine Lösung konnte ich leider nicht finden

@jdo2002: Der Rest scheint aber sehr gut zu funktionieren, auch ein Versionswechsel (stable auf experimental) war kein Problem - vielen Dank für die Mühe die du dir bei der Pflege des Pakets machst!

 

[oj69]

Das ist nicht "irgendein Problem" sondern sehr wahrscheinlich eine Fehlkonfiguration. Wie ist denn die gateway.cfg von Zarafa konfiguriert ? Welches Zertifikat wird hier zum Verbindungsaufbau verwendet ? Ist das ein selbstgeneriertes Zertifikat oder ein öffentlich erstelltes Zertifikat ? Falls selbstgeneriert: ist das dem Mac bekannt und als "vertrauenswürdig" eingestuft ?

 

[MasterSam]

Vielen Dank für deine Antwort. Die Info mit dem Mac stammt von InTheCloud, den ich hier zitiert hatte. Ich habe es nicht mit dem Mac getestet, sondern auf einem Windows-PC mit Thunderbird und einem iPad (zum Testen, normalerweise läuft es dort über ActiveSync, was problemlos funktioniert, ebenfalls über eine verschlüsselte Verbindung). Hätte ich dazuschreiben müssen, sorry Der Fehler ist aber der gleiche:

Fri Jan  3 17:30:59 2014: [ 1296] Starting worker process for IMAPs request
Fri Jan  3 17:30:59 2014: [ 6967] Unable to negotiate SSL connection
Fri Jan  3 17:30:59 2014: [ 6967] Client 79.254.107.xx thread exiting

Die Konfiguration ist - sofern ich keinen Fehler eingebaut habe - identisch mit selbiger von der Stable-Version, mit dem Unterschied, dass ich zusätzlich testweise ssl_enable_v2 = yes gesetzt habe. Die von mir modifizierten Einträge habe ich fett hervorgehoben, der Rest ist nicht verändert. Was ich im Moment nicht ausschließen kann ist, dass sich die Vorlage (also die mitgelieferte gateway.cfg) zwischen dem Stable- und dem Experimental-Release unterscheidet. Das werde ich am Wochenende mal prüfen.

[B]imaps_enable    =       yes[/B]
imaps_port      =       993

...

[B]ssl_private_key_file    =       /usr/syno/etc/ssl/ssl.key/server.key
ssl_certificate_file    =       /usr/syno/etc/ssl/ssl.crt/combined.crt
ssl_enable_v2   =       yes[/B]
ssl_verify_client       =       no
ssl_verify_file         =
ssl_verify_path         =

combined.crt ist ein kombiniertes Zertifikat - das enthält die ca.pm von StartSSL, deren intermediate Zertifikat und mein Server-Zertifikat. Die Datei habe ich nicht verändert seit dem Wechsel auf die Experimental-Version, wenn da irgendwas nicht passt schaltet das Gateway beim Start aber die SSL-Unterstützung ab (steht dann im Log und es lauscht nicht auf Port 993). Thunderbird bringt auch eine Sicherheitswarnung, wenn er dem Zertifikat nicht vertraut (hatte ich beim Stable-Release bevor das Zertifikat korrekt hinterlegt war), das ist hier nicht der Fall.
Das Zertifikat wird in der Form offiziell akzeptiert, sowohl von den üblichen Browsern (Firefox, IE, Chrome, Safari, etc.) als auch von Thunderbird (bei Verwendung des Stable-Zarafa-Pakets). Active Sync läuft auch mit der Experimental-Version direkt nach der Installation problemlos über eine verschlüsselte Verbindung. Nur IMAPs eben nicht

Hier die Infos zum Zertifikat, die mir Firefox ausspuckt, wenn ich z.B. die Webapp von Zarafa öffne:


vg, Johannes

 

[InTheCloud]

@MasterSam und oj69:
Mein Problem ist identisch mit dem von MasterSam und bisher leider ebenfalls ungelöst. Wie bereits von mir geschrieben vermute ich keine Fehlkonfiguration, da sich die Konfiguration mit dem Update auf das Experimental nicht geändert hat und vorher alles funktioniert hat. Der Apache auf der Synology akzeptiert das Zertifikat problemlos. Ein iPhone kann sich mit SSL problemlos verbinden. Nur IMPAS funktioniert eben nicht. Ich vermute daher ein Problem im Zusammenhang mit dem Experimental, das wir versuchen sollten zu lösen, bevor es das nächste Stable wird. Noch ein Hinweis: Wenn ich versuche das Zertifikat in der Server.cfg zu hinterlegen um die Zarafa-interne Kommunikation ebenfalls zu verschlüsseln, dann startet der Zarafa server nicht mehr hoch.

Wenn also jemand IMAPS in Verbindung mit einem offiziellen Zertifikat und der Experimental Version am Laufen hat dann würde ich mich freuen, wenn derjenige mal hier Schritt für Schritt erklären könnte, welche Dateien er wie geändert hat, ob er z.B. das Zertifikat in einem bestimmten Format verwendet (ASCII, UTF8, ...), welche Rechte er für den Ordner vergeben, hat in dem die Zertifikate liegen, usw.

 

[MasterSam]

Das Problem, dass Zarafa überhaupt nicht mehr startet, sobald SSL in der server.cfg aktiviert ist, kann ich bei mir auch nachvollziehen. Habe versucht nach dieser Anleitung die nötige PEM-Datei zu erstellen:
http://www.zarafa.com/wiki/index.php/Zarafa_with_official_SSL_certificates

Wenn ich dann den Server wieder starten möchte, tut er das nicht:

DiskStation> /var/packages/Zarafa/scripts/start-stop-status start
Starting Zarafa...
Mapi.so entry is already added to php.ini - skipped
plugin_enabled is already added to dagent.cfg
plugin_enabled is already added to spooler.cfg
$Starting licensed:
$Starting zarafa-server:

(an der Stelle ist Ende, da bewegt sich nichts mehr, auch nach 10 min nicht)

Trotz Log-Level 5 steht im Log nicht mehr als:

DiskStation> tail  /var/log/zarafa/server.log
Sat Jan  4 10:58:14 2014: Listening for TCP connections on port 236
Sat Jan  4 11:01:52 2014: Audit logging not enabled.
Sat Jan  4 11:01:52 2014: Starting zarafa-server version 7,1,7,42779, pid 9052
Sat Jan  4 11:01:52 2014: Config warning: Option 'index_services_enabled' is not used anymore.
Sat Jan  4 11:01:52 2014: Config warning: Option 'index_services_path' is not used anymore.
Sat Jan  4 11:01:52 2014: Config warning: Option 'index_services_search_timeout' is not used anymore.
Sat Jan  4 11:01:52 2014: Using select events
Sat Jan  4 11:01:52 2014: Listening for priority pipe connections on /var/run/zarafa-prio
Sat Jan  4 11:01:52 2014: Listening for pipe connections on /var/run/zarafa
Sat Jan  4 11:01:52 2014: Listening for TCP connections on port 236

Wäre es eventuell denkbar, dass es ein Problem mit openssl (oder welche Bibliothek auch immer verwendet wird) gibt?

@oj69: funktioniert bei dir das aktuelle Experimental-SPK mit SSL ohne Probleme? Abgesehen von Active Sync, was wohl über den Apache läuft? Welche Diskstation und DSM-Version hast du? Bei mir ist es eine DS213 (ARM-Plattform) mit DSM 4.3-3810 Update 2.

vg, Johannes

 

[oj69]

Bei mir funktioniert das alles wunderbar. Bitte vergesst nicht, dass das neue Experimental-SPK auf einem neueren Zarafa-Versionsstand aufsetzt. Da hat sich m.E. einiges geändert (nachzulesen auf zarafa.com in den Release Notes). Unter anderem auch die Konfiguration "ssl enable v2". Was für einen Sinn macht es, diese Einstellung explizit zu setzen ?

PS: wie in meiner Signatur geschrieben, benutze ich eine DS713+ mit dem aktuellen DSM.
PS2: Du bist ja auch witzig. Ein Logfiles server.log bringt hier gar nichts, wenn wir Dein imap-Problem lösen wollen. Hier solltest Du mal in der gateway.log etc. nachsehen.

 

[MasterSam]

Hmm, die DS713+ ist eine x86-Plattform, eventuell betrifft es nur die ARM-Plattform.
Zur Frage, warum man ssl_enable_v2 aktiviert: wie du schon geschrieben hast veröffentlicht Zarafa Release Notes, aus denen ersichtlich ist dass diese Option in Version 7.1.3 erst hinzukam (siehe hier in den Release Notes). Da es mit dem SPK 0.3.3 mit Zarafa 7.1.2 funktioniert macht es m.E. Sinn erstmal versuchen die Konfiguration so weit anzugleichen wie möglich. Zumal eben diese Einstellung zu exakt dieser Fehlermeldung ("Unable to negotiate SSL connection") im Gateway führen kann (siehe Zarafa-Support-Foren). Scheint bei mir keine Rolle zu spielen, aber einen Versuch war/ist es wert.

Alle Einträge aus der gateway.log findest du in Beitrag #68. Dort steht tatsächlich nicht mehr drin, sonst wäre es vermutlich einfacher der Sache auf den Grund zu gehen (auch nicht bei Erhöhung des Log-Levels in der gateway.cfg auf 5). Im letzten Beitrag bin ich auf den davorstehenden Beitrag von InTheCloud eingegangen, dass Zarafa bei ihm überhaupt nicht mehr startet, wenn er SSL in der server.cfg aktiviert. Ich schrieb, dass bei mir das gleiche passiert - und habe entsprechende Infos in den Text eingebaut. Zarafa ist in verschiedene Module gegliedert, die der Reihe nach starten - das Gateway wird erst nach dem Server gestartet. Wenn der Server schon nicht startet wird also gar nicht versucht das Gateway zu starten, weshalb es keinen Sinn machen würde einen Auszug der gateway.log zu posten (dort steht nichts drin).

Ich habe mal versucht von einem Ubuntu-Client eine SSL-Verbindung herzustellen. Hier zum IMAP-Server (die entscheidenden Fehler sind hervorgehoben):

me@Ubuntu-VBox:~$ openssl version
OpenSSL 1.0.1c 10 May 2012
me@Ubuntu-VBox:~$ openssl s_client -connect xxxx.xxxx.info:993 -CAfile ./ca.pem
CONNECTED(00000003)
depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority
verify return:1
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
verify return:1
depth=0 description = 7uyQ7HJYNAGs6Ic6, C = DE, CN = xxxx.xxxx.info, emailAddress = xxxx.xxxx@gmx.de
verify return:1
[B][COLOR="#FF0000"]3074033864:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1256:SSL alert number 20
3074033864:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:[/COLOR][/B]
---
Certificate chain
 0 s:/description=7uyQ7HJYNAGs6Ic6/C=DE/CN=xxxx.xxxx.info/emailAddress=xxxx.xxxx@gmx.de
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/description=7uyQ7HJYNAGs6Ic6/C=DE/CN=xxxx.xxxx.info/emailAddress=xxxx.xxxx@gmx.de
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3312 bytes and written 342 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : AES256-SHA
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 67D68393151493B13E926141D720C559D0965949FC4BEF893A0C9116B9CFFD7B0C3CB36DB826E390CFA6538A13452B29
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1388850373
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

und hier zum Apache (gleicher Host, anderer Port - zur besseren Vergleichbarkeit habe ich den gleichen cipher genommen):

me@Ubuntu-VBox:~$ openssl s_client -connect xxxx.xxxx.info:443 -CAfile ./ca.pem -cipher AES256-SHA
CONNECTED(00000003)
depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority
verify return:1
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
verify return:1
depth=0 description = 7uyQ7HJYNAGs6Ic6, C = DE, CN = xxxx.xxxx.info, emailAddress = xxxx.xxxx@gmx.de
verify return:1
---
Certificate chain
 0 s:/description=7uyQ7HJYNAGs6Ic6/C=DE/CN=xxxx.xxxx.info/emailAddress=xxxx.xxxx@gmx.de
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/description=7uyQ7HJYNAGs6Ic6/C=DE/CN=xxxx.xxxx.info/emailAddress=xxxx.xxxx@gmx.de
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3587 bytes and written 405 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : AES256-SHA
    Session-ID: A79884B48641958C2AFC89BC77308FF3DDC4AFEBBE4B324349E3CFDA7154872A
    Session-ID-ctx: 
    Master-Key: 108B187BC21607CDF2F1D1BD140FDBB9266B8A85808903F7DE7DDAF304077E8B55F53A1E7E57BED530F347B8A7DD9F75
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 61 e0 1c 48 a4 9d 37 f1-b3 52 3f 43 aa 5a 9b b6   a..H..7..R?C.Z..
    ...
    00b0 - 80 78 69 c2 84 6e 01 53-4e 3f 05 73 63 23 3c f8   .xi..n.SN?.sc#<.

    Start Time: 1388850542
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

Nachdem ich IMAPs benötige bin ich mittlerweile wieder auf das Stable-Release zurück. Der Vollständigkeit halber auch hier nochmal die Ausgabe von openssl, läuft einwandfrei durch (damit wird auch klar, dass kein SSLv2 verwendet wird, weshalb die Option enable_ssl_v2 das Problem nicht lösen wird):

me@Ubuntu-VBox:~$ openssl s_client -connect xxxx.xxxx.info:993 -CAfile ./ca.pem
CONNECTED(00000003)
depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority
verify return:1
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
verify return:1
depth=0 description = 7uyQ7HJYNAGs6Ic6, C = DE, CN = xxxx.xxxx.info, emailAddress = xxxx.xxxx@gmx.de
verify return:1
---
Certificate chain
 0 s:/description=7uyQ7HJYNAGs6Ic6/C=DE/CN=xxxx.xxxx.info/emailAddress=xxxx.xxxx@gmx.de
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/description=7uyQ7HJYNAGs6Ic6/C=DE/CN=xxxx.xxxx.info/emailAddress=xxxx.xxxx@gmx.de
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3555 bytes and written 405 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : AES256-SHA
    Session-ID: 4B006F3429E5FAC814CB67907250F0D70721A6CFC35E5054AB5C89BE83507AA1
    Session-ID-ctx: 
    Master-Key: 82C94401538D17A9D8E56AF103F567A62022AD088F55D9DDEAEBD3732C1A36C883D00582D4D94848C0FF6661517879D5
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 7a f1 7f f9 f6 90 d9 48-2b 5f 6f d3 a9 97 b4 ce   z......H+_o.....
    ...

    Start Time: 1388854112
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
* OK [CAPABILITY IMAP4rev1 LITERAL+ AUTH=PLAIN] Zarafa IMAP gateway ready

Zum Abschluss nochmal ein kurzer Gedankensprung zum Experiment meines letzten Postings. Auch beim Stable-Release habe ich testhalber in der server.cfg mal SSL aktiviert. Gleiche Einstellungen wie bei der Experimental. Startet einwandfrei. Hier die server.log:

DiskStation> tail /var/log/zarafa/server.log
Sat Jan  4 17:54:16 2014: Starting zarafa-server version 7,1,2,39121, pid 25533
Sat Jan  4 17:54:16 2014: Listening for priority pipe connections on /var/run/zarafa-prio
Sat Jan  4 17:54:16 2014: Listening for pipe connections on /var/run/zarafa
Sat Jan  4 17:54:16 2014: Listening for TCP connections on port 236
[B]Sat Jan  4 17:54:16 2014: Listening for SSL connections on port 237[/B]
Sat Jan  4 17:54:16 2014: Connection to database 'zarafa' succeeded
Sat Jan  4 17:54:16 2014: zarafa-licensed is running, but no license key was found. Not all commercial features will be available.
Sat Jan  4 17:54:16 2014: Startup succeeded on pid 25540

vg, Johannes

 

[oj69]

Warum verwendet Du überhaupt "SSL enable V2" ? Das ist doch auch sicherheitstechnisch ein absoluter Rückschritt ...

 

[MasterSam]

Im Produktivbetrieb gar nicht, hatte das zum Testen aktiviert um mögliche Fehlerursachen auszuschließen. Dass es in dieser Konfigurationm Fall mit dem Problem nichts zu tun hat, hat sich erst später gezeigt.

 

[Homer MB]

Hallo zusammen,

Weiß jemand wann das Finale geplant ist

Gruß Homer

 

[u2_honolu]

habe genau die selben probleme mit der verschlüsselung in der experimental (spk 0.4.x).
unter der 0.3.3. lief meine ssl verschlüssellung (port 237) zu meinem outlook client ohne probleme. nach dem upgrade funktioniert sie nun nicht mehr..

bleibt immer bei $starting zarafa-server hängen.

habe schon eine vm aufgesetzt und dort mittels openssl neue zertifikate für die zarafa verschlüsselung genertiert. leider ohne erfolg.

für eine behebung des problems wäre ich sehr dankbar

 

[Schascha]

Hallo Habe Zaraf 0.4.2 auf die 214 Play installiert. Installation klappte. Beim starten von Zarafa Administration krieg ich immer die Meldung "Es tut uns Leid, die von Ihnen gesuchte Seite konnte nicht gefunden werden.". Weiß jemand warum das so ist?

 

[oj69]

funktioniert denn der Aufruf von http://<IP-Adresse>/webapp bzw. http://<IP-Adresse>/webaccess ?

 

[oj69]

Hallo zusammen,

Weiß jemand wann das Finale geplant ist

Gruß Homer

Das musst Du jdo2002 fragen.

Grüße

oj69

 

[Schascha]

Ja http://<IP-Adresse>/webapp bzw. http://<IP-Adresse>/webaccess funktionieren. Nur die Administrationsseite kann ich niht starten . Es kommt immer nur die Meldung"Es tut uns Leid, die von Ihnen gesuchte Seite konnte nicht gefunden werden."