☰

Wie kann man Cyrus davon abhalten, ein Stammzertifikat bereitzustellen?

tag-icon • tag-icon ssl-certificate certificate openssl cyrus
Wie kann man Cyrus davon abhalten, ein Stammzertifikat bereitzustellen?

Seit ich das Zertifikat für meine Cyrus-Instanz geändert habe, erhalte ich jedes Mal, wenn ich mich mit cyradm anmelde, die folgende Warnung:

cyradm --user cyrus --authz cyrus localhost
verify error:num=19:self signed certificate in certificate chain

Dies ist ein OpenSSL-Fehler, der auch beim Verbinden mit dem Server auftritt openssl s_client -connect FQDN(ich habe meinen Betreff/Zertifikatsnamen durch FQDN ersetzt und den Zertifikatsblock zum Posten weggelassen):

CONNECTED(00000003)
depth=2 /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=FQDN
   i:/C=NL/O=TERENA/CN=TERENA SSL CA
 1 s:/C=NL/O=TERENA/CN=TERENA SSL CA
   i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
 2 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
   i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
---
Server certificate
-----BEGIN CERTIFICATE-----
(omitted)
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=FQDN
issuer=/C=NL/O=TERENA/CN=TERENA SSL CA
---
No client certificate CA names sent
---
SSL handshake has read 4171 bytes and written 328 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 88FC7D094D2B0A0EAD11ADBAB0F4605CFF8B72DA0079C3C6E47939018C4CA3D4
    Session-ID-ctx: 
    Master-Key: A88EF226C587C6F9AE43EC7D04D6BC462E657ED851B6FC336940898A57C31E55BCFFACDFFEDBAFB3C65A024F27EB1006
    Key-Arg   : None
    Start Time: 1431561482
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
* OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE AUTH=LOGIN AUTH=PLAIN SASL-IR] FQDN Cyrus IMAP v2.4.12-Debian-2.4.12-2 server ready

Das ist von meinem /etc/imapd.conf:

tls_ca_path:            /etc/ssl/certs
tls_ca_file:            /etc/ssl/certs/TERENA_SSL_CA.pem
tls_cert_file:          /etc/ssl/certs/mail.pem
tls_key_file:           /etc/ssl/private/mail.key

Ich habe das TERENA CA-Zertifikat vonhttps://www.terena.org/activities/tcs/repository/, Abschnitt „TCS CA-Zertifikate (SHA1)/TERENA SSL CA (PEM)“. Die Überprüfung der Datei lesszeigt, dass nur ein Zertifikat in der Datei vorhanden ist. Dies kann also nicht der Grund für die Einbindung des Root-Zertifikats sein. Das betreffende Root-Zertifikat „UTN_USERFirst_Hardware_Root_CA.pem“ ist Teil des ca-certificatesPakets, das auf dem Server installiert ist.

Ich habe keine Ahnung, warum Cyrus darauf besteht, das Stammzertifikat der Kette zu liefern und sich dann darüber zu beschweren.

Aktualisierung 1:

  • Auf dem System läuft Ubuntu 12.04.
  • Die Berechtigungen der Zwischenzertifizierungsstelle betragen 644, die Berechtigungen des Blattzertifizierungsstellen sind 444.
  • ls -lah /etc/ssl/certs/cyrus*tut nichts, es gibt keinen solchen Ordner.

  • openssl x509 -in /etc/ssl/certs/cyrus-imapd-ca.pem -noout -text |grep Issuer, mit Dateipfad zu meinem Zertifikat:

    Issuer: C=NL, O=TERENA, CN=TERENA SSL CA
        CA Issuers - URI:http://crt.tcs.terena.org/TERENASSLCA.crt

Antwort1

Wahrscheinlich ist die Fehlermeldung irreführend – ich erhalte diesen Fehler auch, seit ich die servernameEinstellung in imapd.conf(Debian 8.2/stable) geändert habe.

Ich habe zwei Zwillingsserver eingerichtet, Standardinstallation, mit einem Zwischenzertifikat von RapidSSL. Auf beiden läuft cyrus-imapd mit absolut identischem Setup (ich habe die Konfigurationsdateien mit verglichen, um diffsicherzugehen). Nur weil ich pedantisch bin, habe ich servernamein imapd.confauf beiden Servern in denselben CNAME geändert – einer ist Master, der andere soll ein Replikationsserver für Failover werden, daher der gleiche Name. Dadurch wird natürlich auch der AUTH-Bereich von SASL geändert. Während srv1ich auf den Fehler 19 bekomme, den Sie auch bei Verwendung der cyrusUID mit Standardbereich (einfacher Hostname) beobachtet haben, srv2bekomme ich auf einen anderen Fehler (mit identischem Setup, aber einem anderen kanonischen Domänennamen), nämlich diesen:

Login failed: authentication failure at /usr/lib/x86_64-linux-gnu/perl5/5.20/Cyrus/IMAP/Admin.pm line 120.

Komisch, nicht wahr? Wenn ich auf dem ersten oder zweiten Server die Kommentarzeichen entferne servername, imapd.conffunktioniert alles ohne Fehler. Meine Lösung bestand darin, einen Cyrus SASL-Benutzer mit dem Realm hinzuzufügen, servernameund alles funktioniert wieder einwandfrei. Der Fehler „selbstsigniertes Zertifikat“ ist verschwunden.

Nachdem ich Ihre Frage gelesen hatte, habe ich noch ein paar Tests durchgeführt: Wenn ich tls_ca_path: /tmp/und tls_ca_file:nur auf das Zwischenzertifikat setze, gibt Cyrus trotzdem das verkettete Stamm-CA-Zertifikat aus. ABER: Dieser Fehler wird nicht ausgelöst, wenn entweder das Kommentieren aufgehoben oder ein SASL-Benutzer mit demselben Realm wie servernamehinzugefügt wird .cyrusservername

Ziemlich seltsam. Da Cyrus das Root-CA-Zertifikat sowieso ausgibt, bin ich sicher, dass es nicht die Ursache für diese Fehlermeldung ist. Ich bekomme es nicht, weder auf dem zweiten Server noch auf dem Master mit korrekter SASL-Realm-Einstellung! In meinem Fall war es das falsche Realm, bei Ihnen kann es anders sein. Die Fehlermeldung 19 hat also in keiner Weise etwas mit dem Root-CA-Zertifikat zu tun.

Hoffe, das hilft, lbc (noch ein Perl-Hasser :-)

verwandte Informationen