[pfx] Re: TLS Library Problem
Thanks. Was just confirming , Yes self signed. I broke certbot > On May 12, 2024, at 4:55 AM, Viktor Dukhovni via Postfix-users > wrote: > > On Sat, May 11, 2024 at 11:55:14PM -0400, Jason Hirsh via Postfix-users > wrote: > >> I have they error message >> >> postfix/smtps/smtpd[39559]: warning: TLS library problem: >> error:14094416:SSL routines:ssl3_read_bytes: >> sslv3 alert certificate unknown: >> /usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1621: >> SSL alert number 46: > > The remote client was unable to validate your certificate. > MUAs connecting to port 465 typicall expect a trusted certificate. > > -- >Viktor. > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem
On Sat, May 11, 2024 at 11:55:14PM -0400, Jason Hirsh via Postfix-users wrote: > I have they error message > > postfix/smtps/smtpd[39559]: warning: TLS library problem: > error:14094416:SSL routines:ssl3_read_bytes: > sslv3 alert certificate unknown: > /usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1621: > SSL alert number 46: The remote client was unable to validate your certificate. MUAs connecting to port 465 typicall expect a trusted certificate. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem
On 11.05.24 23:55, Jason Hirsh via Postfix-users wrote: Still chasing ssl/tls issue I have they error message postfix/smtps/smtpd[39559]: warning: TLS library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1621:SSL alert number 46: simple search for "ssl alert 46" provides answer, that it is certificate unknown by client. Perhaps you have self-signed certificate or you fail to provide intermediate certificate from your CA. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
On Mon, May 08, 2023 at 04:22:29PM -0500, E R via Postfix-users wrote: > Thank you so much for the suggestion to review the crypto setting as this > indeed a RedHat based distribution. I confirmed it is set to "default" > which means “The default system-wide cryptographic policy level offers > secure settings for current threat models. It allows the TLS 1.2 and 1.3 > protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and > Diffie-Hellman parameters are accepted if they are at least 2048 bits long.” Right, but the meaning of "DEFAULT" (e.g., whether SHA-1 signatures are accepted in certificates and TLS messages) may vary from release to release. In Fedora 36 default allows SHA-1 signatures, but I've seen documentation that suggests that in RHEL the default policy is more strict. You should be able to set your policy to allow SHA1: # update-crypto-policies --set DEFAULT:SHA1 (no need to reboot, Postfix processes that use OpenSSL are not long-lived). > The [I assume client] system in question was located and is an older > than dirt system running a LONG obsolete version of Gentoo. My best > guess is that the system was accidentally powered on during a > generator test due to a former employee not properly decommissioning > the system many years ago. The configuration change that I wrote > about (disabling the STARTTLS keyword for the IP address) did allow my > Postfix gateways to route email without any issue. I am going to > guess the age or configuration of the system is to blame. I have > started the official process to pull the plug on the server so it can > be wiped and recycled. The system was very likely using TLS 1.0, and had no support for TLS 1.2 or later, so yes, quite old by now. You may still consider whether disabling SHA1 signatures is really the right policy for an MTA. If you've never seen that error message in your logs apart from the client in questions, perhaps the default is good enough. Otherwise, enabling SHA1 will in practice be fine, and enable some legacy systems to establish TLS connections that would otherwise have to fall back to cleartext (or fail to deliver mail). -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
The /usr/share/crypto-policies/DEFAULT/opensslcnf.txt on RHEL 9 looks identical to what you posted for Fedora. I am not a RHEL expert but I have not see any references to opt out of the crypto policy on a per application basis. You can customize an existing crypto policy or create your own. I think as long as people are follow best practices of running Postfix on a dedicated system they should be able to tweak the system-wide policy should they really need to do so, absent any options for granular application configuration. Comparing the DEFAULT policy with the LEGACY policy seems to reduce the security of the system by allowing "..SHA-1 in the TLS hash, signature and algorithm. CBC-mode ciphers are allowed to be used with SSH. Applications using GNUTLS allow certificates with SHA-1" Other than this the TLS, IKEv2, SSH2 protocols are the same as DEFAULT. The RSA keys and Diffie-Hellman parameters are also the same. On Fri, May 5, 2023 at 8:30 PM Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> wrote: > On Fri, May 05, 2023 at 08:28:48PM -0400, Viktor Dukhovni via > Postfix-users wrote: > > > You should of course also share ( > https://www.postfix.org/DEBUG_README.html#mail) > > > > $ postconf -nf > > $ postconf -Mf > > > > without any changes in whitespace, including line breaks. Attaching > > these as text files may be simplest if your mail client won't coöperate. > > And, if applicable, post the content of: > > /usr/share/crypto-policies/DEFAULT/opensslcnf.txt > > Which on a sample Fedora36 system holds: > > CipherString = > @SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > Ciphersuites = > TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256 > TLS.MinProtocol = TLSv1.2 > TLS.MaxProtocol = TLSv1.3 > DTLS.MinProtocol = DTLSv1.2 > DTLS.MaxProtocol = DTLSv1.2 > SignatureAlgorithms = > ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224 > > [openssl_init] > alg_section = evp_properties > > [evp_properties] > rh-allow-sha1-signatures = yes > > Postfix (at least in a default configuration) is not affected by: > > CipherString > TLS.MinProtocol > TLS.MaxProtocol > DTLS.MinProtocol > DTLS.MaxProtocol > > But currently has no controls to override: > > # TLS 1.3 ciphersuites (not a priority to fine-tune) > Ciphersuites = ... > > # TLS 1.2 signature algorithm negotiation (the RH list is fine) > SignatureAlgorithms = ... > > # If this is set to "no", TLS 1.0 key exchange is likely to break. > # In some cases certificate verification may break. > rh-allow-sha1-signatures = yes > > I don't even know whether RedHat exposes any mechanisms for applications > to opt-out of crypto policy and use only application-driven OpenSSL > configuration. This is should perhaps be looked into in the Postfix 3.9 > timeframe. > > -- > Viktor. > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org > ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
Thank you so much for the suggestion to review the crypto setting as this indeed a RedHat based distribution. I confirmed it is set to "default" which means “The default system-wide cryptographic policy level offers secure settings for current threat models. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 2048 bits long.” Source: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening The system in question was located and is an older than dirt system running a LONG obsolete version of Gentoo. My best guess is that the system was accidentally powered on during a generator test due to a former employee not properly decommissioning the system many years ago. The configuration change that I wrote about (disabling the STARTTLS keyword for the IP address) did allow my Postfix gateways to route email without any issue. I am going to guess the age or configuration of the system is to blame. I have started the official process to pull the plug on the server so it can be wiped and recycled. On Fri, May 5, 2023 at 7:29 PM Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> wrote: > On Fri, May 05, 2023 at 06:55:23PM -0500, E R via Postfix-users wrote: > > > postfix/smtpd[1234567]: SSL_accept error from > xxx.xxx.xxx[yyy.yyy.yyy.yyy]: -1 > > postfix/smtpd[1234567]: warning: TLS library problem: > > error:0398:digital envelope routines::invalid > digest:crypto/evp/m_sigver.c:343: > > postfix/smtpd[1234567]: warning: TLS library problem: > > error:0A0C0103:SSL routines::internal > error:ssl/statem/statem_srvr.c:2684: > > This problem may be worth further analysis. It appears that OpenSSL has > chosen a signature algorithm (public key algorithm + digest method, e.g. > RSA with SHA256, ...) at the TLS layer, but failed to initialise a > signature context at the crypto API layer. This is odd, because the > known TLS layer combinations should map to known crypto layer > primitives. > > Are you on a RedHat system perhaps? RedHat's latest releases have > turned up crypto policy to "11", and may refuse to, for example, support > RSA with SHA1. The remote client may have one of the really dated TLS > stacks that doesn't know how to do anything better. > > If your system is a RHEL or recent Fedora or similar system, or perhaps > by now other distributions have joined the club, then you'll to find the > relevant crypto policy file and dial it down a bit (on an MTA doing > opportunistic TLS, RSA with SHA1 is better than cleartext). > > Similar considerations may apply not only to MTAs but also to validating > DNS resolvers, and perhaps other applications. > > The various distributions may publish instructions on recommnded ways to > tune the crypto policy. > > If all the above is false lead, then the problem is more mysterious, and > perhaps a PCAP file capturing a failed handshake would be a good next > step. > > You should of course also share ( > https://www.postfix.org/DEBUG_README.html#mail) > > $ postconf -nf > $ postconf -Mf > > without any changes in whitespace, including line breaks. Attaching > these as text files may be simplest if your mail client won't coöperate. > > -- > Viktor. > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org > ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
I don't even know whether RedHat exposes any mechanisms for applications> to opt-out of crypto policy and use only application-driven OpenSSL> configuration. This is should perhaps be looked into in the Postfix 3.9> timeframe. from my notes dealing with new Fedora crypto-policies on a number of other issues RedHat provides system-wide policy overrides https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#switching-the-system-wide-crypto-policy-to-mode-compatible-with-previous-systems_using-the-system-wide-cryptographic-policies & https://redhatgov.io/workshops/rhel_8/exercise1.5/ https://access.redhat.com/articles/3666211 https://access.redhat.com/articles/3642912 general guidance on customizing policy https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 Oracle also has a good writeup https://docs.oracle.com/en/operating-systems/oracle-linux/8/security/security-ImplementingAdditionalSecurityFeaturesandBestPractices.html#system-crypto-policies note there's option to set per-application policies https://www.systutorials.com/docs/linux/man/8-update-crypto-policies/#lbAF with tool help https://gitlab.com/redhat-crypto/fedora-crypto-policies#user-content-generating-the-policies "... To generate the policies per application use the script python/build-crypto-policies.py policydir DESTDIR ..." some apps allow exclusion at launch https://computingforgeeks.com/configure-system-wide-cryptographic-policies/ "... #4. Excluding an application from system-wide crypto policies ..." for Postfix specifically, there was old discussion re: Postfix ignoring policy Re: postfix 3.5.4 centos 8 hardcoded crypto settings? https://marc.info/?l=postfix-users=159543275820835=2 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
On Fri, May 05, 2023 at 08:28:48PM -0400, Viktor Dukhovni via Postfix-users wrote: > You should of course also share > (https://www.postfix.org/DEBUG_README.html#mail) > > $ postconf -nf > $ postconf -Mf > > without any changes in whitespace, including line breaks. Attaching > these as text files may be simplest if your mail client won't coöperate. And, if applicable, post the content of: /usr/share/crypto-policies/DEFAULT/opensslcnf.txt Which on a sample Fedora36 system holds: CipherString = @SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256 TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3 DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2 SignatureAlgorithms = ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224 [openssl_init] alg_section = evp_properties [evp_properties] rh-allow-sha1-signatures = yes Postfix (at least in a default configuration) is not affected by: CipherString TLS.MinProtocol TLS.MaxProtocol DTLS.MinProtocol DTLS.MaxProtocol But currently has no controls to override: # TLS 1.3 ciphersuites (not a priority to fine-tune) Ciphersuites = ... # TLS 1.2 signature algorithm negotiation (the RH list is fine) SignatureAlgorithms = ... # If this is set to "no", TLS 1.0 key exchange is likely to break. # In some cases certificate verification may break. rh-allow-sha1-signatures = yes I don't even know whether RedHat exposes any mechanisms for applications to opt-out of crypto policy and use only application-driven OpenSSL configuration. This is should perhaps be looked into in the Postfix 3.9 timeframe. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
> > > > Because TLS/SSL things are very complex, you have to show us real > settings all. Like me: (yw-0919: inbound, yw-1204: outbound) > [1] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-0919 > [2] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-1204 > And Postfix TLS support, https://www.postfix.org/TLS_README.html -- https://kenpeng.pages.dev/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
On Fri, May 05, 2023 at 06:55:23PM -0500, E R via Postfix-users wrote: > I have setup Postfix so that internally I offer TLS to systems but do not > require it since I have no control over their configuration. I did > extensive testing to ensure that the mail gateway supports TLS and accepts > email from another Postfix system where TLS is disabled. But today I found > a system failing to route email through the Postfix gateway today that has > me baffled. > > My best guess based on searching the archives is that there may be a defect > in the remote system that is causing the issue. I looked at the > documentation and I think the next step would be to configure the > smtpd_discard_ehlo_keyword_address_maps option and use a CIDR file for the > mapping. (i.e. smtpd_discard_ehlo_keyword_address_maps = > cidr:/etc/postfix/smtpd_discard_ehlo_keyword_address_maps). The contents > of the file would be the IP address of the system and the STARTTLS keyword > if I want to disable TLS for this IP (i.e. 123.456.789.123 STARTTLS). I > tested this on my test system with good ole telnet and it seems to have the > effect I desired. > > Am I missing anything? > > [snippet from main.cf] > smtpd_tls_security_level = may > > [snippet from log] > May 05 16:27:59 zzz postfix/smtpd[1234567]: connect from > xxx.xxx.xxx[yyy.yyy.yyy.yyy] > May 05 16:27:59 zzz postfix/smtpd[1234567]: SSL_accept error from > xxx.xxx.xxx[yyy.yyy.yyy.yyy]: -1 > May 05 16:27:59 zzz postfix/smtpd[1234567]: warning: TLS library problem: > error:0398:digital envelope routines::invalid > digest:crypto/evp/m_sigver.c:343: > May 05 16:27:59 zzz postfix/smtpd[1234567]: warning: TLS library problem: > error:0A0C0103:SSL routines::internal error:ssl/statem/statem_srvr.c:2684: > May 05 16:27:59 zzz postfix/smtpd[1234567]: lost connection after STARTTLS > from xxx.xxx.xxx[yyy.yyy.yyy.yyy] Because TLS/SSL things are very complex, you have to show us real settings all. Like me: (yw-0919: inbound, yw-1204: outbound) [1] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-0919 [2] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-1204 Then we go to check things, IMHO. Sincerely, ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
On Fri, May 05, 2023 at 06:55:23PM -0500, E R via Postfix-users wrote: > postfix/smtpd[1234567]: SSL_accept error from xxx.xxx.xxx[yyy.yyy.yyy.yyy]: -1 > postfix/smtpd[1234567]: warning: TLS library problem: > error:0398:digital envelope routines::invalid > digest:crypto/evp/m_sigver.c:343: > postfix/smtpd[1234567]: warning: TLS library problem: > error:0A0C0103:SSL routines::internal error:ssl/statem/statem_srvr.c:2684: This problem may be worth further analysis. It appears that OpenSSL has chosen a signature algorithm (public key algorithm + digest method, e.g. RSA with SHA256, ...) at the TLS layer, but failed to initialise a signature context at the crypto API layer. This is odd, because the known TLS layer combinations should map to known crypto layer primitives. Are you on a RedHat system perhaps? RedHat's latest releases have turned up crypto policy to "11", and may refuse to, for example, support RSA with SHA1. The remote client may have one of the really dated TLS stacks that doesn't know how to do anything better. If your system is a RHEL or recent Fedora or similar system, or perhaps by now other distributions have joined the club, then you'll to find the relevant crypto policy file and dial it down a bit (on an MTA doing opportunistic TLS, RSA with SHA1 is better than cleartext). Similar considerations may apply not only to MTAs but also to validating DNS resolvers, and perhaps other applications. The various distributions may publish instructions on recommnded ways to tune the crypto policy. If all the above is false lead, then the problem is more mysterious, and perhaps a PCAP file capturing a failed handshake would be a good next step. You should of course also share (https://www.postfix.org/DEBUG_README.html#mail) $ postconf -nf $ postconf -Mf without any changes in whitespace, including line breaks. Attaching these as text files may be simplest if your mail client won't coöperate. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
