Description of problem: After upgrading to Fedora 34 the Evolution cannot connect to Exchange server. The previous version of Evolution worked OK. Evolution cannot connect to the Exchange mail server. It states that the "SSL certificate is ... not trusted. Reason: Error performing TLS handshake: One of the involved algorithms has insufficient security level." Then, when I click the "ViewCertificate" button it shows the window with certificate and options to accept the certificate temporarily or permanently. However, none of these accepting options does not work. The certificate is not accepted and connection not established. Version-Release number of selected component (if applicable): 3.40 How reproducible: Always Steps to Reproduce: 1. Let Evolution connect to exchange server 2. Click ViewCertificate and then click AcceptPermanently 3. Certificate is not accepted Actual results: No connection to Exchange server. Expected results: Connection to exchange server. Additional info:
Thanks for a bug report. Could you state the exact version of the Evolution, please? In can be copied out of the Help->About, or by running from a terminal: $ rpm -q evolution evolution-data-server There had been some changes in the code regarding save of the certificate trust, which were not part of the 3.40.0 of the evolution-data-server. Also, as the error message says: > Error performing TLS handshake: One of the involved algorithms has insufficient security level. It seems to me like the problem is not with the certificate as such, but with hardened crypto policy in the Fedora. Try to follow: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings#Upgrade.2Fcompatibility_impact whether it'll help. Note that some processes run in background, thus either restart the machine or run `evolution --force-shutdown` after changing the crypto policies.
Thanks for the answer. You are right that the problem is (at least partly) connected with the system-wide policies. Switching them to the LEGACY mode solved the problem. For the sake of completeness the exact version of evolution here: evolution-3.40.0-1.fc34.x86_64 evolution-data-server-3.40.0-3.fc34.x86_64 Do I understand it well that the system-wide policies completely prevents applications from accepting weak certificates? That application cannot override this setting? Was this the reason the certificate couldn't be manually accepted? If true, we can close the thread and change the state to Not-a-Bug.
(In reply to Honza Valenta from comment #2) > Thanks for the answer. You are right that the problem is (at least partly) > connected with the system-wide policies. Switching them to the LEGACY mode > solved the problem. Nice. > For the sake of completeness the exact version of evolution here: > > evolution-3.40.0-1.fc34.x86_64 > evolution-data-server-3.40.0-3.fc34.x86_64 Good. I've been afraid you use a Flatpak version, which had an issue with saving certificate/trust prompt responses. > Do I understand it well that the system-wide policies completely prevents > applications from accepting weak certificates? That application cannot > override this setting? It looks like that, though I do not know for sure. It's confusing to offer to accept the certificate while it cannot be accepted by the underlying libraries. @mcatanzaro maybe you know, does glib-networking work with "Error performing TLS handshake: One of the involved algorithms has insufficient security level." in a different way than with other certificate errors, especially whether this cannot be ignored by the user like the other errors, please? It looks like this error is specific and Evolution should not offer to "Accept Certificate" for this error. One of the most common errors is a self-signed certificate, which can be "accepted" by the user.
(In reply to Milan Crha from comment #3) > @mcatanzaro maybe you know, does glib-networking work with "Error performing > TLS handshake: One of the involved algorithms has insufficient security > level." in a different way than with other certificate errors, especially > whether this cannot be ignored by the user like the other errors, please? It > looks like this error is specific and Evolution should not offer to "Accept > Certificate" for this error. One of the most common errors is a self-signed > certificate, which can be "accepted" by the user. I don't think you should *ever* allow users to accept invalid TLS certificates. But yes, you are probably correct. That error message is coming from GNUTLS_E_INSUFFICIENT_SECURITY, which is a fatal error because that generally indicates a protocol problem rather than a certificate problem. If GnuTLS were to instead return GNUTLS_CERT_INSECURE_ALGORITHM, then we convert that to G_TLS_CERTIFICATE_INSECURE and Evolution would be able to ignore it if desired.
I see. How do I find out when I can offer to ignore the error and when not, seeing the GNUTLS_E_INSUFFICIENT_SECURITY (and possibly others) do not map to anything? Is it when the errors set contains the G_TLS_CERTIFICATE_GENERIC_ERROR? It can contain more than that, but I suppose once there's an unmapped error it means it cannot be ignored by the user, right?
GNUTLS_E_INSUFFICIENT_SECURITY is a fatal error: it's not something you can ignore. If you *really* want to allow the user to ignore this error, you would need to change GnuTLS to return GNUTLS_CERT_INSECURE_ALGORITHM rather than GNUTLS_E_INSUFFICIENT_SECURITY.
BTW I hope your UI for ignoring certificate errors is *very* scary. Users should clearly understand that ignoring a certificate error allows their email to be read by an unauthorized third party, not their email provider. Legitimate email providers do not use invalid certificates.
(In reply to Michael Catanzaro from comment #6) > GNUTLS_E_INSUFFICIENT_SECURITY is a fatal error: it's not something you can > ignore. > > If you *really* want to allow the user to ignore this error, you would need > to change GnuTLS to return GNUTLS_CERT_INSECURE_ALGORITHM rather than > GNUTLS_E_INSUFFICIENT_SECURITY. I meant how to recognize that and possibly other fatal errors, to not offer to ignore the certificate error, when it has no impact. You do not have a special error code for the fatal errors, or at least I did not find it. If it's safe to use G_TLS_CERTIFICATE_GENERIC_ERROR to recognize them, then I'm fine.
If GTlsConnection::accept-certificate is called with nonzero GTlsCertificateFlags, then you have an ignorable certificate verification error, indicating a possible MITM attack. Errors elsewhere cannot be ignored.
Honzo, by any chance, do you have a command to create a certificate, which will use weak algorithm, please? I'd like to try to reproduce it here, to see what values glib-networking/gnutls returns. I suppose when it's a self-signed certificate _and_ a weak crypto is used, then the certificate errors will be non-zero, thus the code cannot know the prompt to ignore the certificate error is void.
Milane, sorry, I don't have and I have never done it.
No problem, I'll try to figure it out. To make it simple for me, do you know what algorithm the certificate uses, please? It can be seen when connecting to it using gnutls-cli command like. When I run it as: $ gnutls-cli www.google.com then it says (apart of other things): - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `CN=www.google.com,O=Google LLC,L=Mountain View,ST=California,C=US', issuer `CN=GTS CA 1O1,O=Google Trust Services,C=US', serial 0x00ed92fe51b1d16c910300000000cbf7b1, EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2021-04-13 10:17:32 UTC', expires `2021-07-06 10:17:31 UTC', pin-sha256="Vkrf/SvIz5+u+SKwCI2/S2PedtV3eUPV+6/5Zt9CX0U=" Public Key ID: sha1:56d9d6d8b4dcb4803676111b4a39da5dea9489fc sha256:564adffd2bc8cf9faef922b0088dbf4b63de76d5777943d5fbaff966df425f45 Public Key PIN: pin-sha256:Vkrf/SvIz5+u+SKwCI2/S2PedtV3eUPV+6/5Zt9CX0U= - Certificate[1] info: - subject `CN=GTS CA 1O1,O=Google Trust Services,C=US', issuer `CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R2', serial 0x01e3b49aa18d8aa981256950b8, RSA key 2048 bits, signed using RSA-SHA256, activated `2017-06-15 00:00:42 UTC', expires `2021-12-15 00:00:42 UTC', pin-sha256="YZPgTZ+woNCCCIW3LH2CxQeLzB/1m42QcCTBSdgayjs=" - Status: The certificate is trusted. I do not want the private details, which describe the certificate, I only would like to know the algorithms, like in the case of the first certificate above: "EC/ECDSA key 256 bits, signed using RSA-SHA256". The gnutls-cli is part of the gnutls-utils package.
OK. Is the following enough? Or do you need a complete listing? RSA key 2048 bits, signed using RSA-SHA384
This is fine, thanks. I'll report back once I know more.
Hrm, I've a certificate with even weaker RSA-SHA256, but it doesn't trigger gnutls' "insufficient security" error. I get many other, as expected: Reason: The signing certificate authority is not known. The certificate does not match the expected identity of the site that it was retrieved from. The certificate has expired. Detailed error: Failed to issue REPORT: HTTP error code 6 (Unacceptable TLS certificate) but not the error you see.
OK, how can I help you more?
I do not know. All what I want this for is to verify what glib-networking does. The only outcome would be to hide buttons to accept/reject the certificate when they do not make sense. Maybe there's a way to test this on your side. When you change the crypto policy back to the 'DEFAULT' and connect to the server, which will offer you the error with the "View Certificate" button, then when you click that button, what will be at the top, please? It's the 'Reason' section and the 'Detailed error' section, as I showed above (comment #15). The text there can be selected and copied out.
What a coincidence, trying to setup a Fedora 33 (yes, 33) machine I receive this prompt: The signing certificate authority is not known. The certificate does not match the expected identity of the site that it was retrieved from. The certificate’s algorithm is considered insecure. I can accept this certificate permanently with no problem. Maybe the original problem is elsewhere.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.