Connections 5 CR3 - Connecions Mail 1.6 - Lotus Domino 9.01 FP5

[ra.t]

Hallo Admins,

ich habe folgendes Problem:
Nach einem Update von Connections 5 CR2 auf CR3 funktioniert die SSL Verbindung von Connections Mail zu unserem Dominoserver nicht mehr.
Auf dem Dominoserver ist folgendes bei SSL ciphers eingestellt:
RC4 encryption with 128-bit key and MD5 MAC
RC4 encryption with 128-bit key and SHA-1 MAC
Triple DES encryption with 168-bit key and SHA-1 MAC

Sobald sich nun ein Kollege in Connections anmeldet verursacht das Mailplugin eine Fehlermeldung.
Auf der Konsole des Dominoservers erscheint dann dieser SSL-Fehler:

SSLProcessClientHello> SSL/TLS protocol clientVersion 0x0301, serverVersion 0x0301
SSLProcessClientHello> 12 ciphers requested by client
SSLProcessClientHello> Client requested RSA_WITH_AES_128_CBC_SHA (0x002F)
SSLProcessClientHello> Best common cipherspec 0x002F (so far)
SSLProcessClientHello> Best common non-EC cipherspec 0x002F (so far)
SSLProcessClientHello> Client requested DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
SSLProcessClientHello> Client requested DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
SSLProcessClientHello> Client requested RSA_WITH_3DES_EDE_CBC_SHA (0x000A)
SSLProcessClientHello> Client requested Unknown Cipher (0xFEFF)
SSLProcessClientHello> Client requested DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
SSLProcessClientHello> Client requested Unknown Cipher (0x0013)
SSLProcessClientHello> Client requested RSA_WITH_DES_CBC_SHA (0x0009)
SSLProcessClientHello> Client requested Unknown Cipher (0xFEFE)
SSLProcessClientHello> Client requested Unknown Cipher (0x0015)
SSLProcessClientHello> Client requested Unknown Cipher (0x0012)
SSLProcessClientHello> Client requested TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00FF)
SSLProcessClientHello> TLS_EMPTY_RENEGOTIATION_INFO_SCSV found
SSLProcessClientHello> hash/alg in certchain  fSupHasAlg:0000
SSLProcessClientHello> We selected cipher RSA_WITH_AES_128_CBC_SHA (0x002F)
SSLProcessHandshakeMessage Exit> Message: ClientHello (1) State: HandshakeServerIdle (3) Key Exchange: 1 Cipher: RSA_WITH_AES_128_CBC_SHA (0x002F)
SSLAdvanceHandshake Enter> Processed: ClientHello (1) State: HandshakeServerIdle (3)
SSLAdvanceHandshake client_hello> SGC FLAG: 0   Count = 2
SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeServerHello
SSLEncodeServerHello> Sending empty renegotiation_info (0xff01) extension
SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeCertificate
SSLEncodeCertificate> Generating a certificate message with 3 certs
SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeServerHelloDone
SSLAdvanceHandshake Exit> State HandshakeClientKeyExchange (11)
SSL_Handshake> After handshake state = HandshakeClientKeyExchange (11); Status = -5000
int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone]
SSLProcessProtocolMessage> Record Content: Alert (21)
SSLProcessAlert> Got an alert of 0x28 (handshake_failure) level 0x2 (fatal)
SSL_Handshake> After handshake2 state HandshakeClientKeyExchange (11)
SSL_Handshake> SSL Error: -6994
int_MapSSLError> Mapping SSL error -6994 to 4171 [SSLFatalAlert]


Ich hatte nun schon verschiedenen notes.ini Einträge für SSL und Cipher mal getestet, aber leider alles erfolglos.
Am Connections Server oder IHS habe ich noch nichts verändert, obwohl die Änderung im SSL von dieser Seite kommt.
Wie habt ihr das eingerichtet, das die Server sich weiter über SSL unterhalten können ?

mfg
Ralf

[Tode]

Vermutlich ist Dein Domino- Zertifikat noch ein SHA1- Zertifikat, siehe hier

[ra.t]

Hallo Tode,
vielen Dank für die schnelle Antwort.

Auf dem Mailserver nutzen wir ein öffentliches Zertifikat:
SHA-256 mit RSA-Verschlüsselung

mfg
Ralf

[Tode]

In dem Fall könntest Du mal probieren, ob die beiden Server sich mit einem anderen Cipher besser verstehen, indem Du in Deinem SSLCipherSPEC- Eintrag in der Notes.ini den 2F entfernst und ggf. mal 33 und 16 hinzufügst.

[ra.t]

Hallo Tode,
bringt alles nichts.

 int_MapSSLError> Mapping SSL error -6995 to 4161 [SSLNegotiationErr]

TLS/SSL connection "ConnectionsAdresse"(54614) -> "Dominoserver"(443) failed with no supported ciphers

mfg
Ralf

[Tode]

Nur nochmal für mich: Wie sieht Deine SSLCipherSpec denn aktuell aus?

[ra.t]

Hallo Tode,

wie oben geschrieben.

Zusätzlich ist aktuell noch SSLCipherSpec=2F35 in der notes.ini eingetragen.
Bringt aber nichts.

mfg
Ralf

PS.: Aber wie schon geschrieben, wir haben das Problem erst, nachdem ich den Websphere und Connections Server aktualisiert habe.

[Tode]

Zusätzlich? Du weißt aber schon, dass die Zeile SSLCipherSpec den Eintrag im Domino directory ÜBERSCHREIBT?

Das heißt: Aktuell habt Ihr nur 2 Cipher aktiv...

Mach doch mal einfach ALLES rein, und strippe dann runter auf das, was Du brauchst:

SSLCipherSpec=9D9C3D3C352F0A3339676B9E9F

Vielleicht ist auch einfach der Keystrength zu stark für das Cipher, auf das sich beide einigen.

Probier mal noch den INI- Parameter

SSL_DH_KEYSIZE=1024

Check Daniel Nasheds Blog für Details

[Tode]

Hier mal noch eine genaue Beschreibung der verschiedenen Cipher, und welche man wofür verwendet. Für Dich interessant:

This article describes how administrators can configure SSL/TLS cipher specifications in Domino 9.0.1 FP4 IF2 without using the no-longer-functional settings in the public directory.

[ra.t]

Hallo Tode,
die Blogs von Daniel habe ich schon durch.
Leider alles ohne Erfolg.
Deinen ersten Eintrag hatte ich auch schon gemacht,
der zweite ist Morgen dran.

Auffallend ist, das ich in Websphere unter Sicherheit / Keystores nun auch keinen Key mehr von dem Dominoserver abrufen kann.
mfg
Ralf

[ra.t]

Hallo Tode,
so, habe nun deine Vorschläge auch noch mal getestet, .... leider immer gleiches Ergebnis.

Noch eine Idee ? Connections wieder auf CR2 downgraden, das es wieder funktioniert ?

mfg
ralf

[ra.t]

Hallo Tode,
ich habe nun noch etwas festgestellt:

Wenn ich in Websphere ein Zertifikat von einem anderen Dominoserver abrufe, dann funktioniert dies noch.
- Das Zertifikat ist auch nur ein Signaturalgorytmus von SHA1, öffentlicher Schlüssel: RSA 2048.

Der wichtige Server für Connections hat die Signatur :SHA256 öffentlicher Schlüssel: RSA 4096

mfg
Ralf

[Tode]

Ich habe NULL Ahnung von Connections... Kann der u.U. kein 4096 Bit? Sorry, aber ab hier bin ich wohl raus...

[ra.t]

Hallo Tode,

neeeeeeiiiiiiiiinnnnn, bitte nicht "raus"

du bist doch der einzige, der sich hier aktiv beteiligt.

Ich werde wohl ein neues Zertifikat für den betroffenen Server erstellen lassen, dann sollte es wohl wieder mit Connections Mail funktionieren.

Dann ist unser System halt ab heute nicht mehr so sicher.

mfg
Ralf

[nmeisenzahl]

Hallo zusammen,
der Websphere versteht 4096bit Keys aktuell nur wenn man die Java Policy customized. Siehe hier -> http://www-01.ibm.com/support/docview.wss?uid=swg21625723

Gruß

[ra.t]

Hallo somebody,

vielen Dank für die Info aus dem Jahr 2013.
Evt. wurde bei einem Update des Websphere Servers oder IHS etwas überschrieben oder ähnliches.
Wie schon erwähnt, hatte ja vorher funktioniert.

Nächste Woche wird das noch mal mit unserem Dienstleister diskutiert.

mfg
Ralf

[MaVo]

Hallo Ralf,

schau Dir mal diesen Blogeintrag an.

https://milanmatejic.wordpress.com/2015/10/30/ibm-connections-mail-plug-in-integration-with-inotes/

VG
Martin

[ra.t]

Hallo Martin,

die Infos aus dem Blog hatte ich auch schon getestet (hatte ich oben schon erwähnt:"SSLCipherSpec=2F35").
mfg
Ralf

[MaVo]

Hallo Ralf,

sorry, über lesen.

Wenn ich den Log-Auszug richtig verstehe, haben sich die Teilnehmer auf einen Cipher geeinigt. Doch der Handshake schlägt mit "Error -6994" fehl.

Zum Fehlermeldung "Error -6994" habe folgenden IBM KB Artikel gefunden: http://www-01.ibm.com/support/docview.wss?uid=swg21528704

Kannst Du bitte mal überprüfen, ob die CAs bei Domino und Connections vorhanden sind?

VG Martin

[m3]

Hallo somebody,

vielen Dank für die Info aus dem Jahr 2013.
Evt. wurde bei einem Update des Websphere Servers oder IHS etwas überschrieben oder ähnliches.
Wie schon erwähnt, hatte ja vorher funktioniert.

Nächste Woche wird das noch mal mit unserem Dienstleister diskutiert.

mfg
Ralf

NEIN, das gilt noch immer. Für 4096 bit keys musst Du den oben beschrieben "fix" anwenden.