On 29.12.2023 21:41, Andrei Borzenkov wrote:
On 29.12.2023 18:47, Andrei Borzenkov wrote:
On 29.12.2023 15:30, Carlos E. R. wrote:
I would learn How to do it, if someone points me to a "how to create CA and certificates for dovecot that makes Thunderbird happy, for dummies".
The dummies part is important.
Sorry, I do not know such document. Certificate management is complex, and making guide which is correct, reasonably complete and suitable for complete dummies is probably quite challenging task by itself.
Anyway, I tried and could not reproduce your problem. I setup dovecot ("zypper in dovecot", generated self-signed certificate using the same command I showed, that's all) on Leap 15.4. I configured TB 115.5.0 to use it with IMAP in TLS mode. TB asked me if I wanted to trust this certificate and entered exception in cert_override.txt. I then replaced key/certificate pair on dovecot with new one and restarted dovecot. When updating folders TB popped up the same question and updated cert_override.txt. So as far as I can tell it works as expected.
If you can describe conditions which lead to your issue, I may try to dig further. But so far I do not have anything to begin with.
The format of the cert_override.txt is pretty trivial and can be generated manually if necessary.
OK, actually I did get the same errors from dovecot. But I also was able to override them in TB. So this confirms that the problem is on the TB side. The self-signed certificate *is* invalid and will always be. Until you either enroll it as trusted root (which strictly speaking is invalid as well - the same certificate cannot be used both for CA and end-system without some form of exceptional override) or use client side overrides.
Why you do not get prompts from TB to add exception I do not know. But that is also rather different issue which has absolutely nothing to do with dovecot.
And to continue with the SAN saga ... Apparently TB does a series of checks and returns the first problem found. With self-signed certificate it never gets past the "no certificate authority" check so SAN is completely irrelevant. Why TB does not return error 48 (to indicate missing certificate authority) I do not know. I got 48 when I created X509v1 certificate with MD5 hash which should be considered invalid today. So I created my own CA and imported its certificate and signed certificate for dovecot - which now becomes signed with trusted CA - and *now* I got completely different message from TB that certificate does not belong to this site and someone may be trying to impersonate it. At this point SAN becomes important, because only now TB actually checks it. To eliminate *this* error I had to add Subject Alternative Name extension with the DNS name matching *exactly* the host name used on the *client* side. So discussion on the dovecot mailing list was totally correct - as long as we are talking about "real" certificate, not some self-signed mongrel. And in case you still refuse to see behind the trees - no official public commercial CA was involved. No exceptions had to be accepted. And NSS can be configured to use system-wide trust list, so CA certificate needs to be deployed just once for all users, current and future. Yes, certificate management is complicated. And no, you cannot expect to get step by step guide for dummies that can be used under any conditions without applying your own brains to understand what you are doing and, more importantly, *why* you need to do exactly that.