dovecot - Jul 2017 - STARTTLS issue with sieve

Am 08.07.2017 um 23:10 schrieb Heiko Schlittermann:
> Andreas Oster <aoster at 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 at 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 ------------ -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20170710/9f791249/attachment.sig>

Am 10.07.2017 um 08:52 schrieb Heiko Schlittermann:
> Andreas Oster <aoster at 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