FWIW & TWIMC: I added

ssl_dh = </etc/dovecot/dh.pem

to my config and ran

$ sudo openssl dhparam -out /etc/dovecot/dh.pem 4096

(which took ten minutes to so...), now everything seems to work.

See also the section "Diffie-Hellman Parameters for SSL" here:
https://wiki2.dovecot.org/Upgrading/2.3

(In reply to Thorsten Leemhuis from comment #1)
> FWIW & TWIMC: 

Forget about that comment, I did something wrong during testing and didn't read the report properly. Sorry for the noise

/me hides in a corner in shame

I can confirm the problem.
The workaround works ...

The only thing to mention is that the existing certificates need to be removed prior running mkcert.sh.

After updating to F33 i have this problem. I did:

1. Added ssl_dh = </etc/dovecot/dh.pem to /etc/dovecot/dovecot.conf

2. openssl dhparam -out /etc/dovecot/dh.pem 4096

3. systemctl restart dovecot 

It didn't help so I uninstalled dovecot and installed it again. I did 1 to 3 again but I still get SSL_CTX_use_certificate:ee key too small.

What should I do?

@rhampf you are mentioning that you got the problem when doing something else. For the purpose of this bugreport, please keep it simple and on topic and use /usr/libexec/dovecot/mkcert.sh .

I upgraded to F33 and dovecot wouldn't let me in anymore. I got the same error as you got. I didn't try mkcert.sh as I don't need a self-signed certificate. (Please correct me if I'm wrong.) I use a certificate I bought from Comodo.

Then I did what I wrote in my previous comment.

I'm not very skillful in this field. I wanted to report that this workaround doesn't work for me. If I'm doing something wrong or someone has ideas I would be very glad to hear. Now I'm considering lowering the level of security to sidestep this problem.

Ok, thanks for clarifying.

The problem in this bug is about the self-signed certificate, and how the script for creating the certificate was outdated and incompatible with the modern security standards used in Fedora.

The fix for this bug is to create secure certificate - not to support insecure certificates.

It is a different problem if you recently bought a certificate that doesn't meet modern security standards. Or if it should be considered a bug that Fedora only support modern security standards.

The insecure cerficate sounds like something to discuss with Comodo. Comodo will probably tell you that Fedora is to blame for too aggressively deprecating things. I think Fedora is right in putting users and security first and being a leader without compromises. (But I'm no expert in this area, don't know the certificate you bought, and don't know exactly in what way it is too weak.)

I don't know if there is a way to enable your insecure certificate in Fedora. In some cases, there has been something like that (for example when md5 was deprecated - bug 1498322 ) but I haven't stumbled upon any evidence of any workarounds in this case. It might be configurable in /etc/crypto-policies/back-ends/*.config somehow. Perhaps something inspired by https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-security-level can work. Or perhaps support for the weak security has been completely removed.

(In reply to Mads Kiilerich from comment #5)
> @rhampf you are mentioning that you got the problem when doing
> something else. For the purpose of this bugreport, please keep it simple and
> on topic and use /usr/libexec/dovecot/mkcert.sh .

Well just removing dovecot & reinstalling plus running /usr/libexec/dovecot/mkcert.sh does not resolve the problem. Same error.

Trying variations incl. permutations based on conf files of dovecot generate the same results.

What a crap update to Fedora 33. I've been using Fedora (Core) since its conception but unfortunately the number of update errors due to lack of testing keep increasing. Pushing out new features and fancy options appears to have more priority than consistency & evolutionary growth.

(In reply to Jan from comment #8)
> Well just removing dovecot & reinstalling plus running
> /usr/libexec/dovecot/mkcert.sh does not resolve the problem. Same error.

Yes, the fix has not yet been released in a regular update, and this seems to be reproducing and confirming the reported problem.

> Trying variations incl. permutations based on conf files of dovecot generate
> the same results.

Did you try *just* setting default_bits = 4096 and running mkcert.sh? I just tested and confirmed that this is all it takes to make it work after installing dovecot. (But it is tricky to convince thunderbird to trust the self-signed certificate - different story.)

Exactly what result do you see in that case?

Bit of a saga in my case.  Here's what I needed to do to get back to normal.

1) First sign of problems was old server cert + key blowing after upgrade of dovecot IMAP server machine to F33

> imap-login: Error: Failed to initialize SSL server context: Can't load SSL certificate (ssl_cert setting): error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small:

I set the key size to 4096 and deleted and regenerated the cert + key as described in this bug report at the top.

Set the CN in the dovecot-openssl.cnf while you are in there to match your server

2) That didn't clear it, the error changed to

> imap-login: Error: Failed to initialize SSL server context: Can't load DH parameters (ssl_dh setting): error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small

I had to do the magic incantations from Thorsten in Comment #1 additionally.  My mailserver is the weakest available fanless x86_64, this took like 6h.

Then I could login after accepting the cert in Android K-9 reader... yay.

3) Thunderbird could not be convinced to take the new cert.  There seemed to be two issues: a) thunderbird currently has a bug about banning :993, since that makes sense for firefox as a webbrowser and they share some guts, and b) since I created the original cert, my base domain is on the HSTS list... nothing cared while I used the old IMAP server cert predating that but with the new one, HSTS causes it to refuse selfsigned as an option.  I want selfsigned because it's more secure with TOFU for this than trusting many CAs to produce a cert for my IMAP server domain.

4) This stackoverflow answer describes how to clear the :993 (well, :465 but just replace with :993) banning bug

https://stackoverflow.com/questions/63947262/thunderbird-78-how-to-add-security-exception

5) Disable HSTS temporarily in FFOX and Thunderbird using its "Edit Config..." button at the bottom of the first config page

https://security.stackexchange.com/questions/102279/can-hsts-be-disabled-in-firefox

After that, I could filling the correct URL with :993 of my IMAP server and get the selfsigned cert accepted as an exception.

6) Undo the config mangling you did in both FFOX and Thunderbird and resume your life

I think it's good that Fedora cranked up the security with this but it seems quite underestimated the vertical stack of problems this can unleash, although I can see the HSTS makes me a bit unusual, still, it is a byzantine research project for some working critical infrastructure that is (however desirably) broken from a distro change.

> --- Comment #9 from Mads Kiilerich <mads> ---
> (In reply to Jan from comment #8)

Thanks for the reaction.

>> Well just removing dovecot & reinstalling plus running
>> /usr/libexec/dovecot/mkcert.sh does not resolve the problem. Same error.
> 
> Yes, the fix has not yet been released in a regular update, and this 
> seems to be reproducing and confirming the reported problem.

Noted.

>> Trying variations incl. permutations based on conf files of dovecot generate
>> the same results.
> 
> Did you try *just* setting default_bits = 4096 and running 
> mkcert.sh? I just tested and confirmed that this is all it takes to
> make it work after installing dovecot. ....

I (already) did and basic testing of dovecot incl. SSL ops is OK. Sucessfully ran SSL tests using "https://stackoverflow.com/questions/14959461/how-to-talk-to-imap-server-in-shell-via-openssl".

Later also added dh i.e.

  openssl dhparam -out /etc/dovecot/dh.pem 4096

  ssl_dh = </etc/dovecot/dh.pem

to /etc/dovecot/dovecot.conf

Current output of "doveconf -n -P" is

# 2.3.11.3 (502c39af9): /etc/dovecot/dovecot.conf
# OS: Linux 5.9.15-200.fc33.x86_64 x86_64 Fedora release 33 (Thirty Three)
# Hostname: <mailserver removed>
mbox_write_locks = fcntl
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
    special_use = \Drafts
  }
  mailbox Junk {
    special_use = \Junk
  }
  mailbox Sent {
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    special_use = \Sent
  }
  mailbox Trash {
    special_use = \Trash
  }
  prefix =
}
passdb {
  driver = pam
}<mailserver removed>
ssl = required
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_cipher_list = PROFILE=SYSTEM
ssl_key = </etc/pki/dovecot/private/dovecot.pem
userdb {
  driver = passwd
}

> ... (But it is tricky to convince thunderbird to trust the
> self-signed certificate - different story.)

Being a Thunderbird user since 2006 and running approx. 9 mail accounts on a variety of mail-servers from TB, its the mail-tool of choice. And yes I know working with certificates in TB is awkward at best.

Some people suggested dropping TB and moving to Evolution which
does work with the current Dovecot server. Do not want to run an additional mail tool just for Dovecot access.


> Exactly what result do you see in that case?

Current attemps yield logging such as

Dec 24 11:21:57 <mailserver removed> dovecot[69412]: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=<IP removed>, lip=<IP removed>, TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number 46, session=<JaV1LTO3JPNSX1w8>

where SSL issue: alert number 46 = sslv3 alert certificate unknown a.k.a. server certificate is self signed.

Self signing is of course the default in a local Dovecot installation. To me that's also the preferred approach for the future.

At this point in time I'm trying to find a TB based solution. Since this self signed certification problem has been around for a while there may be a solution or work-around (sometime in the near/far future).


Thanks.

(In reply to Andy Green from comment #10)
> 1) First sign of problems was old server cert + key blowing after upgrade of
> dovecot IMAP server machine to F33
> 
> > imap-login: Error: Failed to initialize SSL server context: Can't load SSL certificate (ssl_cert setting): error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small:
> 
> I set the key size to 4096 and deleted and regenerated the cert + key as
> described in this bug report at the top.
...
> the error changed to

To get more clarity, we should conclude that the workaround worked. It confirms that the bug tracked here is well understand and fixable. Other bugs should be reported and tracked separately.

> > imap-login: Error: Failed to initialize SSL server context: Can't load DH parameters (ssl_dh setting): error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small
> 
> I had to do the magic incantations from Thorsten in Comment #1 additionally.

Weird. I did not see that problem. AFAIK, I don't have any custom crypto settings. "update-crypto-policies --show" shows "DEFAULT", and my old /etc/crypto-policies/back-ends/nss.config was essentially like /usr/share/crypto-policies/back-ends/DEFAULT/nss.config . And "doveconf | grep dh" just shows "ssl_dh = ". I guess there must be some other setting that make you hit some other bug. That should be reported separately.

> 3) Thunderbird could not be convinced to take the new cert.

Yes, thunderbird regressed and is painful to work around with self signed certificates. I commented upstream in https://bugzilla.mozilla.org/show_bug.cgi?id=1681960#c5 how I understood it and got it working. But that's yet another issue.

@mhlavink you set this to "MODIFIED". What does that mean? I don't see any change in f33, master, or upstream?

(In reply to Jan from comment #11)
 
> > Exactly what result do you see in that case?
> 
> Current attemps yield logging such as
> 
> Dec 24 11:21:57 <mailserver removed> dovecot[69412]: imap-login:
> Disconnected (no auth attempts in 0 secs): user=<>, rip=<IP removed>,
> lip=<IP removed>, TLS handshaking: SSL_accept() failed: error:14094416:SSL
> routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number
> 46, session=<JaV1LTO3JPNSX1w8>
> 
> where SSL issue: alert number 46 = sslv3 alert certificate unknown a.k.a.
> server certificate is self signed.
> 
> Self signing is of course the default in a local Dovecot installation. To me
> that's also the preferred approach for the future.
> 
> At this point in time I'm trying to find a TB based solution. Since this
> self signed certification problem has been around for a while there may be a
> solution or work-around (sometime in the near/far future).

Followed point 5 in Comment 10 by Andy Green and convinced TB to add an Exception for the self signed certificate. Works as expected and TB is usuable again with the Dovecot server.

Thanks.

FEDORA-2021-364e2809b8 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-364e2809b8

MK:
Seems my localbuild - test - commit - build script failed. I've prepared new build, together with latest security fixes recently released. Should be available in updates-testing repository soon

FEDORA-2021-364e2809b8 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-364e2809b8`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-364e2809b8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-154a1b4c19 has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-154a1b4c19`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-154a1b4c19

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-c90cb486f7 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.