ich habe versucht, meinen Dovecot-IMAP-Server (Version 1.0.10 – ein Upgrade ist derzeit keine Option) mit einem neuen SSL-Zertifikat auf Ubuntu wie folgt zu konfigurieren:
$ grep ^ssl /etc/dovecot/dovecot.conf
ssl_disable = no
ssl_cert_file = /etc/ssl/certs/mydomain.com.crt.20120904
ssl_key_file = /etc/ssl/private/mydomain.com.key.20120904
$ /etc/init.t/dovecot stop
$ sudo dovecot -p
$ [i enter the ssl password here]
es zeigt keine Fehler und wenn ich es ausführe ps aux | grep dovecotbekomme ich
root 21368 0.0 0.0 12452 688 ? Ss 15:19 0:00 dovecot -p
root 21369 0.0 0.0 71772 2940 ? S 15:19 0:00 dovecot-auth
dovecot 21370 0.0 0.0 14140 1904 ? S 15:19 0:00 pop3-login
dovecot 21371 0.0 0.0 14140 1900 ? S 15:19 0:00 pop3-login
dovecot 21372 0.0 0.0 14140 1904 ? S 15:19 0:00 pop3-login
dovecot 21381 0.0 0.0 14280 2140 ? S 15:19 0:00 imap-login
dovecot 21497 0.0 0.0 14280 2116 ? S 15:29 0:00 imap-login
dovecot 21791 0.0 0.0 14148 1908 ? S 15:48 0:00 imap-login
dovecot 21835 0.0 0.0 14148 1908 ? S 15:53 0:00 imap-login
dovecot 21931 0.0 0.0 14148 1904 ? S 16:00 0:00 imap-login
me 21953 0.0 0.0 5168 944 pts/0 S+ 16:02 0:00 grep --color=auto dovecot
es sieht so aus, als ob alles einwandfrei läuft. Dann teste ich, ob ich mich per Telnet mit dem Dovecot-Server verbinden kann, und das hier funktioniert einwandfrei:
$ telnet localhost 143
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK Dovecot ready.
aber wenn ich teste, ob Dovecot die SSL-Zertifikate richtig konfiguriert hat, scheint es zu einem Fehler zu kommen:
$ sudo openssl s_client -connect localhost:143 -starttls imap
CONNECTED(00000003)
depth=0 /description=xxxxxxxxxxxxxxxxx/C=AU/ST=xxxxxxxx/L=xxxx/O=xxxxxx/CN=*.mydomain.com/[email protected]
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /description=xxxxxxxxxxx/C=AU/ST=xxxxxx/L=xxxx/O=xxxx/CN=*.mydomain.com/[email protected]
verify error:num=27:certificate not trusted
verify return:1
depth=0 /description=xxxxxxxx/C=AU/ST=xxxxxxxxxx/L=xxxx/O=xxxxx/CN=*.mydomain.com/[email protected]
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/description=xxxxxxxxxxxx/C=AU/ST=xxxxxxxxxx/L=xxxxxxxx/O=xxxxxxx/CN=*.mydomain.com/[email protected]
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
.
.
.
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxx==
-----END CERTIFICATE-----
subject=/description=xxxxxxxxxx/C=AU/ST=xxxxxxxxx/L=xxxxxxx/O=xxxxxx/CN=*.mydomain.com/[email protected]
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 2831 bytes and written 342 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: xxxxxxxxxxxxxxxxxxxx
Session-ID-ctx:
Master-Key: xxxxxxxxxxxxxxxxxx
Key-Arg : None
Start Time: 1351661960
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
. OK Capability completed.
zumindest gehe ich davon aus, dass es sich um einen Fehler handelt???
Antwort1
Das Problem liegt bei OpenSSL, nicht bei Dovecot.
Es gibtein Käferin openssl, wodurch die Suche nach dem Standard-CApath gestoppt wird. Sie müssen also -CApathin Ihrer Befehlszeile angeben, wo die Liste der Stamm-CA-Zertifikate zu finden ist. Beispiel:
sudo openssl s_client -connect localhost:143 -starttls imap -CApath /dev/null
Wenn Sie Ihren Ordner „certs“ noch nicht ausgefüllt haben und über Computerkenntnisse verfügen, folgen Siedieses Tutorialum certdata.txt von Mozilla herunterzuladen und die erforderlichen PEM-Dateien und Symlinks zu generieren. Die Skripte müssen möglicherweise geändert werden, wenn Sie keinen Zugriff auf /bin haben, und Sie müssen einen Symlink ln -s ca-bundle.crt cert.pem erstellen.
(Durch die Angabe von /dev/null wird OpenSSL gezwungen, den Standardpfad von cert.pem in Ihrem OpenSSL-Verzeichnis zu verwenden. Um herauszufinden, wo sich Ihr OpenSSL-Verzeichnis befindet, geben Sie ein openssl version -d).
Da Sie StartSSL verwenden, müssen Sie möglicherweise Ihr Zertifikat und das Zwischenzertifikat für Dovecot verknüpfen, in Ihrem Fall StartCom Class 2 Primary Intermediate Server CA. Ihr kostenloses Zertifikat verwendet StartCom Class 1 Primary Intermediate Server CA.
Antwort2
Sie können es verbose_ssl = yesin der Dovecot-Konfiguration verwenden, um zusätzliche Protokollierungsausgaben zu erzeugen.
In meiner Konfiguration (Dovecot 2.0) verwende ich die folgenden Anweisungen:
ssl_cert = </etc/ssl/certs/mydomain.com.crt.20120904
ssl_key = </etc/ssl/private/mydomain.com.key.20120904
Antwort3
Alte Frage – neue Probleme (diesmal Letsencrypt-Zertifikate):
"Überprüfungs-Rückgabecode: 21 (das erste Zertifikat konnte nicht überprüft werden)"
(was bedeutet, dass das Zwischenzertifikat (die Kette) nicht gefunden/zur Überprüfung verwendet wird)
Hier ist die Lösung, die ich nach viel Herumprobieren in den letzten 24 Stunden gefunden habe.
Lassen Sie mich zunächst kurz darauf eingehen, was ich zum Testen verwendet habe:
Ich habe Dovecot auf einem anderen E-Mail-Server (Ubuntu 18.xx) und dieser hat local.confabgesehen von den verwendeten Domänen/Zertifikaten die GLEICHEN Dovecot-Einstellungen. Beide verwenden Letsencrypt-Zertifikate und beide wurden gestern erneuert.
Der Dovecot (Version 2.2.33.2) unter Ubuntu 18 funktioniert einwandfrei.
Keine Fehlercodes bei Verwendungopenssl s_clientzum Testen der E-Mail-Ports: 993/IMAP oder :995/POP.
Aber auf einem anderen Computer (dem, auf dem der Fehler auftritt) verwende ich:
Betriebssystem: Ubuntu 20.04.2
Dovecot (Ubuntu-Standard-/Repo-Version): 2.3.7.2 (3c910f64b)
OpenSSL (Ubuntu-Standard-/Repo-Version):1.1.1f 31 Mar 2020
Der Fehler wurde mir bewusst, nachdem sich ein Kunde über das Hinzufügen eines E-Mail-Kontos zu einem Android-Telefon (Standard-E-Mail-App von Google/Gmail) beschwert hatte:
"Dem Zertifikat kann nicht vertraut werden."
Wenn ich das Zertifikat für das Web oder SMTP verwende, funktioniert der OpenSSL-Test einwandfrei und überprüft.
Dies lässt mich glauben, dass das Problem bei Dovecot unter Ubuntu 20 liegt.
Andere E-Mail-Clients wie Thunderbird und Outlook funktionieren ebenfalls einwandfrei.
Ich habe sofort beschlossen, mit „openssl s_client“ zu testen, und der Fehler hat mich schließlich hierher geführt.
Meine Konfiguration sah sowohl auf der defekten als auch auf der funktionierenden Dovecot-Maschine folgendermaßen aus:
ssl_ca = </etc/letsencrypt/live/{CertName}/fullchain.pem
ssl_cert = </etc/letsencrypt/live/{CertName}/cert.pem
ssl_key = </etc/letsencrypt/live/{CertName}/privkey.pem
Ich habe nicht herausgefunden, welche Software den Fehler verursacht, aber ich habe den Fehler behoben. Das Android-Telefon vertraut dem Zertifikat jetzt voll und ganz. Mir war schon vorher klar, dass der Fehler wahrscheinlich durch die fehlende Überprüfung der Zertifikatskette/CA verursacht wurde.
Lösung/TL;DR:
Verwenden Sie diefullchain.pemals Ihren Zertifikatseintrag ( ssl_cert =). Er enthält sowohl Ihr LE-Zertifikat als auch Ihre LE-Kette.
Ihre Dovecot-Konfiguration für SSL sollte folgendermaßen aussehen (ersetzen Sie {CertName} natürlich durch Ihren eigenen):
ssl_ca = </etc/letsencrypt/live/{CertName}/chain.pem (or 'fullchain' should work)
ssl_cert = </etc/letsencrypt/live/{CertName}/fullchain.pem
ssl_key = </etc/letsencrypt/live/{CertName}/privkey.pem
Während des Tests sollte der Fehler nicht mehr auftreten:
Verify return code: 0 (ok)
Ich musste auf dem Computer, auf dem der Fehler nicht auftrat (Ubuntu 18), nichts ändern – also habe ich es nicht getan.
Update:
Dovecot, das derzeit mit Ubuntu 20 Repository/apt verwendet wird, ist/war betroffen.
Fehlerreferenz:https://dovecot.org/pipermail/dovecot/2021-April/121884.html