STARTTLS issue with sieve
Hi all,
I am currently struggling with an odd sieve/Pigeonhole issue. Some weeks ago I had to replace our dovecot certificate due to expiration. In the past I did use a self-signed certificate, but because we now have a little openssl based CA I have decided to create signed certificate for imaps. Dovecot is happily accepting the new certificate which has integrated the whole cert-chain. Unfortunately Pigeonhole does not seem to like the certificate:
<--snip
gnutls-cli --starttls -p4190 mail.novanetwork.local
Processed 173 CA certificate(s). Resolving 'mail.novanetwork.loc'... Connecting to '10.2.1.23:4190'...
- Simple Client Mode:
"IMPLEMENTATION" "Dovecot Pigeonhole" "SIEVE" "fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave" "NOTIFY" "mailto" "SASL" "" "STARTTLS" "VERSION" "1.0" OK "Dovecot ready."
STARTTLS OK "Begin TLS negotiation now."
-->
At this point the TLS process does not proceed. When I press CTRL-D I get the following output:
*** Starting TLS handshake
Certificate type: X.509
Got a certificate list of 3 certificates.
Certificate[0] info:
- subject
C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=Mail Server,CN=mail.novanetwork.local', issuerC=DE,ST=Baden-Wuerttemberg,O=NOVA Elektroanlagen GmbH,OU=NOVA Intermediate CA,CN=NOVA Intermediate CA', RSA key 2048 bits, signed using RSA-SHA256, activated2017-06-23 06:58:40 UTC', expires2020-06-22 06:58:40 UTC', SHA-1 fingerprint `51a9b62eaebb6b4a2b8cc9a22740dc689445da0c' Public Key ID: 165eaaa4b36c091ec8f32103da003a1f43b1c57d Public key's random art: +--[ RSA 2048]----+ | .o.. | |. .o. . E | |o.. .. . | |= o . + | |+* o . S | |o==. o o | | .=o+.. | | .ooo | | .o | +-----------------+
- subject
Certificate[1] info:
- subject
C=DE,ST=Baden-Wuerttemberg,O=NOVA Elektroanlagen GmbH,OU=NOVA Intermediate CA,CN=NOVA Intermediate CA', issuerC=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=NOVA Root CA,CN=NOVA Root CA', RSA key 4096 bits, signed using RSA-SHA256, activated2016-12-05 11:40:29 UTC', expires2026-12-03 11:40:29 UTC', SHA-1 fingerprint `308870b657dccd4902ca119d18d7ba8d6ad54ec0'
- subject
Certificate[2] info:
- subject
C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=NOVA Root CA,CN=NOVA Root CA', issuerC=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=NOVA Root CA,CN=NOVA Root CA', RSA key 4096 bits, signed using RSA-SHA256, activated2016-12-05 11:36:47 UTC', expires2036-11-30 11:36:47 UTC', SHA-1 fingerprint `95326e3ff12683cc40a85874d562d0a6f15dcb37'
- subject
Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed
I have checked the certificate with:
openssl verify -verbose -CAfile /etc/ssl/certs/ca-chain.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem: OK
and also with:
openssl verify -verbose -CAfile /etc/ssl/certs/mail.novanetwork.local.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem: OK
Does anyone have an idea what could be the cause of the problem and how to fix it ?
Thank you for your kind help.
best regards Andreas
Andreas Oster aoster@novanetwork.de (Fr 07 Jul 2017 08:15:05 CEST):
Hi all,
I am currently struggling with an odd sieve/Pigeonhole issue. Some weeks ago I had to replace our dovecot certificate due to expiration. In the past I did use a self-signed certificate, but because we now have a little openssl based CA I have decided to create signed certificate for imaps. Dovecot is happily accepting the new certificate which has integrated the whole cert-chain. Unfortunately Pigeonhole does not seem to like the certificate:
As it seem, Pigeonhole sends you the full cert chain:
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen …
- Certificate[2] info:
- subject `C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=NOVA Root CA,CN=NOVA Root CA', issuer
The last one being the CA used.
SHA-1 fingerprint `95326e3ff12683cc40a85874d562d0a6f15dcb37'
- Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed
For me it reads as if your client (gnutls-cli) does not trust the chain your server sent. (The server doesn't care about the chain).
I have checked the certificate with:
openssl verify -verbose -CAfile /etc/ssl/certs/ca-chain.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem: OK
How do you know that gnutls-cli uses the same CA file? Try passing the CA file to gnutls-cli?
The --x509cafile seems to be hardcoded in /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (Debian9, amd64)
$ strings /usr/lib/x86_64-linux-gnu/libgnutls.so.30 | grep '/etc/ssl' /etc/ssl/certs/ca-certificates.crt
So, on my system gnutls-cli seems to use the same CA store (/etc/ssl/certs) as openssl.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Am 08.07.2017 um 23:10 schrieb Heiko Schlittermann:
As it seem, Pigeonhole sends you the full cert chain:
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen …
- Certificate[2] info:
- subject `C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=NOVA Root CA,CN=NOVA Root CA', issuer The last one being the CA used.
SHA-1 fingerprint `95326e3ff12683cc40a85874d562d0a6f15dcb37'
- Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Err
It is wrong to send the root CA along with the intermediate and server certificates. The root CA cert must be in the CA trust bundle of the client.
Alexander
Alexander Dalloz ad+lists@uni-x.org (So 09 Jul 2017 13:14:56 CEST): …
It is wrong to send the root CA along with the intermediate and server certificates. The root CA cert must be in the CA trust bundle of the client.
I wouldn't say it is wrong. But it should be useless, as the client wont trust the root CA it received. The client should trust only its copy of the root CA.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
But if it won’t trust that copy, that invalidates the chain, right?
On Sun, Jul 9, 2017 at 9:48 AM Heiko Schlittermann hs@schlittermann.de wrote:
Alexander Dalloz ad+lists@uni-x.org (So 09 Jul 2017 13:14:56 CEST): …
It is wrong to send the root CA along with the intermediate and server certificates. The root CA cert must be in the CA trust bundle of the client.
I wouldn't say it is wrong. But it should be useless, as the client wont trust the root CA it received. The client should trust only its copy of the root CA.
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Roger Klorese rogerklorese@gmail.com (So 09 Jul 2017 18:49:27 CEST):
But if it won’t trust that copy, that invalidates the chain, right?
For my understanding (I may be wrong) the client needs to trust one element of the chain, be it the certificate itself, or its signer or the root of the chain.
Heiko-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
On 10/07/17 04:48, Heiko Schlittermann wrote:
Alexander Dalloz ad+lists@uni-x.org (So 09 Jul 2017 13:14:56 CEST): …
It is wrong to send the root CA along with the intermediate and server certificates. The root CA cert must be in the CA trust bundle of the client.
I wouldn't say it is wrong. But it should be useless, as the client wont trust the root CA it received. The client should trust only its copy of the root CA.
I've seen clients that invalidate if you send the root along with the rest of the chain. I've seen ssllabs lower a server's grade because it had a chain like this:
Root A -> Root B -> intermediate -> server cert ...
... Where both Root A and Root B are in the browser's trusted bundle, but Root A signed Root B with an SHA1 hash and root B signed the intermediate with and SHA256 hash, so if you returned Root B and the intermediate as chain certs you got a lower grade because of the SHA1 sig, but if you just passed the intermediate it was fine.
In short, it may work some of the time or most of the time to pass the root cert, but there will be edge cases where it will fail. It's safest to not pass the root cert.
Peter
Am 08.07.2017 um 23:10 schrieb Heiko Schlittermann:
Andreas Oster aoster@novanetwork.de (Fr 07 Jul 2017 08:15:05 CEST):
Hi all,
I am currently struggling with an odd sieve/Pigeonhole issue. Some weeks ago I had to replace our dovecot certificate due to expiration. In the past I did use a self-signed certificate, but because we now have a little openssl based CA I have decided to create signed certificate for imaps. Dovecot is happily accepting the new certificate which has integrated the whole cert-chain. Unfortunately Pigeonhole does not seem to like the certificate:
As it seem, Pigeonhole sends you the full cert chain:
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen …
- Certificate[2] info:
- subject `C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=NOVA Root CA,CN=NOVA Root CA', issuer
The last one being the CA used.
SHA-1 fingerprint `95326e3ff12683cc40a85874d562d0a6f15dcb37'
- Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed
For me it reads as if your client (gnutls-cli) does not trust the chain your server sent. (The server doesn't care about the chain).
I have checked the certificate with:
openssl verify -verbose -CAfile /etc/ssl/certs/ca-chain.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem: OK
How do you know that gnutls-cli uses the same CA file? Try passing the CA file to gnutls-cli?
The --x509cafile seems to be hardcoded in /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (Debian9, amd64)
$ strings /usr/lib/x86_64-linux-gnu/libgnutls.so.30 | grep '/etc/ssl' /etc/ssl/certs/ca-certificates.crt
So, on my system gnutls-cli seems to use the same CA store (/etc/ssl/certs) as openssl.
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann
Hello Heiko,
removing the CA and intermediate certificates from the server certificate and adding the CA certs to the ca-certificates.crt resolved my issue.
Thank you for your kind help.
best regards Andreas
Andreas Oster aoster@novanetwork.de (Mo 10 Jul 2017 08:23:17 CEST): …
Hello Heiko,
removing the CA and intermediate certificates from the server certificate and adding the CA certs to the ca-certificates.crt resolved my issue.
According to what Peter wrote, I'd put the root CA to your ca-certificates, but let the intermediate cert in the certificate chain sent by the server. (That's what the intermediate certs are good for, isn't it?)
Heiko-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Am 10.07.2017 um 08:52 schrieb Heiko Schlittermann:
Andreas Oster aoster@novanetwork.de (Mo 10 Jul 2017 08:23:17 CEST): …
Hello Heiko,
removing the CA and intermediate certificates from the server certificate and adding the CA certs to the ca-certificates.crt resolved my issue.
According to what Peter wrote, I'd put the root CA to your ca-certificates, but let the intermediate cert in the certificate chain sent by the server. (That's what the intermediate certs are good for, isn't it?)
Yes, that's exactly how you should do it.
Heiko
Alexander
Am 08.07.2017 um 23:10 schrieb Heiko Schlittermann:
Andreas Oster aoster@novanetwork.de (Fr 07 Jul 2017 08:15:05 CEST):
Hi all,
I am currently struggling with an odd sieve/Pigeonhole issue. Some weeks ago I had to replace our dovecot certificate due to expiration. In the past I did use a self-signed certificate, but because we now have a little openssl based CA I have decided to create signed certificate for imaps. Dovecot is happily accepting the new certificate which has integrated the whole cert-chain. Unfortunately Pigeonhole does not seem to like the certificate:
As it seem, Pigeonhole sends you the full cert chain:
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen …
- Certificate[2] info:
- subject `C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=NOVA Root CA,CN=NOVA Root CA', issuer
The last one being the CA used.
SHA-1 fingerprint `95326e3ff12683cc40a85874d562d0a6f15dcb37'
- Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed
For me it reads as if your client (gnutls-cli) does not trust the chain your server sent. (The server doesn't care about the chain).
I have checked the certificate with:
openssl verify -verbose -CAfile /etc/ssl/certs/ca-chain.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem: OK
How do you know that gnutls-cli uses the same CA file? Try passing the CA file to gnutls-cli?
The --x509cafile seems to be hardcoded in /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (Debian9, amd64)
$ strings /usr/lib/x86_64-linux-gnu/libgnutls.so.30 | grep '/etc/ssl' /etc/ssl/certs/ca-certificates.crt
So, on my system gnutls-cli seems to use the same CA store (/etc/ssl/certs) as openssl.
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann
Hi all,
in a posting on the dovecot user list Stephan Bosch pointed out that there is already a fix:
https://github.com/dovecot/pigeonhole/commit /c80aa7c25b0b4e61bb8e3a91864a355f7f2fa89f
This small change also resolved my sieve login issue.
best regards Andreas
Am 07.07.2017 um 08:15 schrieb Andreas Oster:
Hi all,
I am currently struggling with an odd sieve/Pigeonhole issue. Some weeks ago I had to replace our dovecot certificate due to expiration. In the past I did use a self-signed certificate, but because we now have a little openssl based CA I have decided to create signed certificate for imaps. Dovecot is happily accepting the new certificate which has integrated the whole cert-chain. Unfortunately Pigeonhole does not seem to like the certificate:
<--snip
gnutls-cli --starttls -p4190 mail.novanetwork.local
Processed 173 CA certificate(s). Resolving 'mail.novanetwork.loc'... Connecting to '10.2.1.23:4190'...
- Simple Client Mode:
"IMPLEMENTATION" "Dovecot Pigeonhole" "SIEVE" "fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave" "NOTIFY" "mailto" "SASL" "" "STARTTLS" "VERSION" "1.0" OK "Dovecot ready."
STARTTLS OK "Begin TLS negotiation now."
-->
At this point the TLS process does not proceed. When I press CTRL-D I get the following output:
*** Starting TLS handshake
Certificate type: X.509
Got a certificate list of 3 certificates.
Certificate[0] info:
- subject
C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=Mail Server,CN=mail.novanetwork.local', issuerC=DE,ST=Baden-Wuerttemberg,O=NOVA Elektroanlagen GmbH,OU=NOVA Intermediate CA,CN=NOVA Intermediate CA', RSA key 2048 bits, signed using RSA-SHA256, activated2017-06-23 06:58:40 UTC', expires2020-06-22 06:58:40 UTC', SHA-1 fingerprint `51a9b62eaebb6b4a2b8cc9a22740dc689445da0c' Public Key ID: 165eaaa4b36c091ec8f32103da003a1f43b1c57d Public key's random art: +--[ RSA 2048]----+ | .o.. | |. .o. . E | |o.. .. . | |= o . + | |+* o . S | |o==. o o | | .=o+.. | | .ooo | | .o | +-----------------+Certificate[1] info:
- subject
C=DE,ST=Baden-Wuerttemberg,O=NOVA Elektroanlagen GmbH,OU=NOVA Intermediate CA,CN=NOVA Intermediate CA', issuerC=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=NOVA Root CA,CN=NOVA Root CA', RSA key 4096 bits, signed using RSA-SHA256, activated2016-12-05 11:40:29 UTC', expires2026-12-03 11:40:29 UTC', SHA-1 fingerprint `308870b657dccd4902ca119d18d7ba8d6ad54ec0'Certificate[2] info:
- subject
C=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=NOVA Root CA,CN=NOVA Root CA', issuerC=DE,ST=Baden-Wuerttemberg,L=Ettlingen,O=NOVA Elektroanlagen GmbH,OU=NOVA Root CA,CN=NOVA Root CA', RSA key 4096 bits, signed using RSA-SHA256, activated2016-12-05 11:36:47 UTC', expires2036-11-30 11:36:47 UTC', SHA-1 fingerprint `95326e3ff12683cc40a85874d562d0a6f15dcb37'Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed
I have checked the certificate with:
openssl verify -verbose -CAfile /etc/ssl/certs/ca-chain.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem: OK
and also with:
openssl verify -verbose -CAfile /etc/ssl/certs/mail.novanetwork.local.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem /etc/ssl/certs/mail.novanetwork.local.cert.pem: OK
Does anyone have an idea what could be the cause of the problem and how to fix it ?
Thank you for your kind help.
best regards Andreas
Hi all,
in another posting Stephan Bosch pointed out that there is already a fix:
https://github.com/dovecot/pigeonhole/commit/c80aa7c25b0b4e61bb8e3a91864a355...
This small change also resolved my sieve login issue.
best regards Andreas
participants (5)
-
Alexander Dalloz
-
Andreas Oster
-
Heiko Schlittermann
-
Peter
-
Roger Klorese