Javamail connection
Locked
12
12
 
|
I am attempting to configure a Javamail client embedded in a Jetty application
to send outgoing email through our outgoing MX. I have the following variables available to me: Mail Host: 192.168.216.32 SMTP Authentication: Set to on SMTP SSL/TLS: Set to on SMTP Port: 465 Request Email: My personal email Request User: My imap mailbox id Request User Password: My imap mailbox password. The gateway MX runs postfix-sasl-3.5.8,1. postconf -n alias_database = hash:/etc/mail/aliases alias_maps = hash:/etc/mail/aliases broken_sasl_auth_clients = yes command_directory = /usr/local/sbin compatibility_level = 2 content_filter = smtp-amavis:localhost:10024 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 delay_warning_time = 15m disable_vrfy_command = yes header_checks = regexp:$config_directory/header_checks.regexp html_directory = /usr/local/share/doc/postfix ignore_mx_lookup_error = no inet_interfaces = localhost, 192.168.216.32, 216.185.71.32 inet_protocols = ipv4 local_transport = smtp mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man message_size_limit = 134217728 meta_directory = /usr/local/libexec/postfix milter_default_action = accept milter_protocol = 2 mydestination = mydomain = harte-lyne.ca myhostname = mx32.harte-lyne.ca mynetworks = 216.185.71.0/24, 192.168.199.0/24, 192.168.216.0/24, 192.168.209.0/24, 192.168.8.0/24, 192.168.7.0/24, 192.168.6.0/24, 127.0.0.0/8 mynetworks_style = subnet myorigin = $mydomain newaliases_path = /usr/local/bin/newaliases non_smtpd_milters = $smtpd_milters policyd-spf_time_limit = 3600 postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/postscreen_access.cidr postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 dun.dnsrbl.net*1 escalations.dnsbl.sorbs.net*1 postscreen_dnsbl_threshold = 2 queue_minfree = 201326592 rbl_reply_maps = hash:/usr/local/etc/postfix/rbl_reply readme_directory = /usr/local/share/doc/postfix recipient_delimiter = + relay_clientcerts = hash:/usr/local/etc/postfix/relay_clientcerts relay_domains = hash:/usr/local/etc/postfix/relay_domains sample_directory = /usr/local/etc/postfix sender_canonical_maps = hash:/usr/local/etc/postfix/canonical sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop shlib_directory = /usr/local/lib/postfix smtp_dns_support_level = dnssec smtp_host_lookup = dns, native smtp_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt smtp_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx32.crt smtp_tls_ciphers = high smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, 3DES, RC4, SEED, IDEA, RC2, RC5 smtp_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx32.key smtp_tls_mandatory_ciphers = high smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, !SSLv3, !SSLv2 smtp_tls_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, !SSLv3, !SSLv2 smtp_tls_security_level = dane smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_scache smtp_tls_session_cache_timeout = 3600s smtpd_client_connection_count_limit = 5 smtpd_client_connection_rate_limit = 6 smtpd_client_restrictions = permit smtpd_data_restrictions = permit_mynetworks, reject_multi_recipient_bounce, reject_unauth_pipelining, permit smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, check_helo_access pcre:/usr/local/etc/postfix/helo_checks.pcre, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, permit smtpd_milters = inet:localhost:8891 smtpd_proxy_timeout = 300s smtpd_recipient_restrictions = reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unauth_pipelining check_policy_service inet:10023 check_policy_service unix:private/policyd-spf permit smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_path = smtpd smtpd_sender_restrictions = permit_mynetworks, check_sender_access hash:/usr/local/etc/postfix/sender_access, check_sender_mx_access hash:/usr/local/etc/postfix/sender_mx_access, check_sender_ns_access hash:/usr/local/etc/postfix/sender_ns_access, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, permit smtpd_starttls_timeout = ${stress?10}${stress:120}s smtpd_timeout = ${stress?10}${stress:120}s smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt smtpd_tls_ask_ccert = no smtpd_tls_auth_only = yes smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx32.crt smtpd_tls_ciphers = high smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem smtpd_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, 3DES, RC4, SEED, IDEA, RC2, RC5 smtpd_tls_fingerprint_digest = sha256 smtpd_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx32.key smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, !SSLv3, !SSLv2 smtpd_tls_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, !SSLv3, !SSLv2 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache smtpd_tls_session_cache_timeout = 3600s strict_rfc821_envelopes = yes tls_preempt_cipherlist = no tls_random_source = dev:/dev/urandom transport_maps = hash:/usr/local/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/usr/local/etc/postfix/virtual, regexp:/usr/local/etc/postfix/virtual.regexp postconf -M . . . smtps inet n - n - - smtpd -v -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject -o smtpd_recipient_restrictions=permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination -o smtpd_sender_restrictions=permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination -o milter_macro_daemon_name=ORIGINATING -o syslog_name=postfix-p465 . . . What I see in the MX maillog is this: Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: connection established Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: master_notify: status 0 Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: name_mask: resource Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: name_mask: software Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: connect from accounting-2.internal.harte-lyne.ca[192.168.216.88] Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: match_list_match: accounting-2.internal.harte-lyne.ca: no match Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: match_list_match: 192.168.216.88: no match Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: match_list_match: accounting-2.internal.harte-lyne.ca: no match Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: match_list_match: 192.168.216.88: no match Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: smtp_stream_setup: maxtime=120 enable_deadline=0 Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: auto_clnt_open: connected to private/tlsmgr Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: send attr request = seed Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: send attr size = 32 Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: private/tlsmgr: wanted attribute: status Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: input attribute name: status Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: input attribute value: 0 Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: private/tlsmgr: wanted attribute: seed Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: input attribute name: seed Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: input attribute value: akW6ri3JY/r6LEFzcDcB+MTgdqI3fKU6n2wU7jUYiPk= Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: private/tlsmgr: wanted attribute: (list terminator) Dec 17 13:03:15 mx32 postfix-p465/smtpd[47327]: input attribute name: (end) Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: SSL_accept error from accounting-2.internal.harte-lyne.ca[192.168.216.88]: lost connection Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: match_hostname: smtpd_client_event_limit_exceptions: accounting-2.internal.harte-lyne.ca ~? 216.185.71.0/24 Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: match_hostaddr: smtpd_client_event_limit_exceptions: 192.168.216.88 ~? 216.185.71.0/24 Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: match_hostname: smtpd_client_event_limit_exceptions: accounting-2.internal.harte-lyne.ca ~? 192.168.199.0/24 Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: match_hostaddr: smtpd_client_event_limit_exceptions: 192.168.216.88 ~? 192.168.199.0/24 Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: match_hostname: smtpd_client_event_limit_exceptions: accounting-2.internal.harte-lyne.ca ~? 192.168.216.0/24 Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: match_hostaddr: smtpd_client_event_limit_exceptions: 192.168.216.88 ~? 192.168.216.0/24 Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: lost connection after CONNECT from accounting-2.internal.harte-lyne.ca[192.168.216.88] Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: disconnect event to all milters Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: disconnect from accounting-2.internal.harte-lyne.ca[192.168.216.88] commands=0/0 Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: free all milters Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: free milter inet:localhost:8891 Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: master_notify: status 1 Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: connection closed Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: auto_clnt_close: disconnect private/tlsmgr stream What is Postfix asking for or is waiting on? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:[hidden email] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 |
|
|
James B. Byrne:
[ Charset ISO-8859-1 converted... ] > I am attempting to configure a Javamail client embedded in a Jetty application > to send outgoing email through our outgoing MX. I have the following variables > available to me: > > Mail Host: 192.168.216.32 > SMTP Authentication: Set to on > SMTP SSL/TLS: Set to on > SMTP Port: 465 > Request Email: My personal email > Request User: My imap mailbox id > Request User Password: My imap mailbox password. > Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: SSL_accept error from > accounting-2.internal.harte-lyne.ca[192.168.216.88]: lost connection How is your port 465 service configured in master.cf? Next email, DO NOT include debug logging. Wietse |
|
|
Wietse Venema:
> James B. Byrne: > > I am attempting to configure a Javamail client embedded in a Jetty application > > to send outgoing email through our outgoing MX. I have the following variables > > available to me: > > > > Mail Host: 192.168.216.32 > > SMTP Authentication: Set to on > > SMTP SSL/TLS: Set to on > > SMTP Port: 465 > > Request Email: My personal email > > Request User: My imap mailbox id > > Request User Password: My imap mailbox password. > ... > > Dec 17 13:03:35 mx32 postfix-p465/smtpd[47327]: SSL_accept error from > > accounting-2.internal.harte-lyne.ca[192.168.216.88]: lost connection > > How is your port 465 service configured in master.cf? Very likely, tls_wrappermode is turned on as it should be on port 465, which requires the client to speak first (no server greewting, no client EHLO and STARTTLS). Apparently, the client is configured to expect "port 578" server where a server speaks first and sends a greeting before the client sends EHLO and STARTTLS. Wietse > Next email, DO NOT include debug logging. > > Wietse > |
|
|
On Thu, December 17, 2020 14:28, Wietse Venema wrote: > Wietse Venema: > > Very likely, tls_wrappermode is turned on as it should be on port > 465, which requires the client to speak first (no server greewting, > no client EHLO and STARTTLS). > > Apparently, the client is configured to expect "port 578" server > where a server speaks first and sends a greeting before the client > sends EHLO and STARTTLS. > > Wietse Did you mean port 587? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:[hidden email] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 |
|
|
James B. Byrne:
[ Charset ISO-8859-1 converted... ] > > > On Thu, December 17, 2020 14:28, Wietse Venema wrote: > > Wietse Venema: > > > > Very likely, tls_wrappermode is turned on as it should be on port > > 465, which requires the client to speak first (no server greewting, > > no client EHLO and STARTTLS). > > > > Apparently, the client is configured to expect "port 578" server > > where a server speaks first and sends a greeting before the client > > sends EHLO and STARTTLS. > > > > Wietse > > Did you mean port 587? Of course. Have you looked into the service type mismatch, wthere the client expects a service like "submission" where the server speaks first (plaintext SMTP before the client sends STARTTLS), whereas Postfix is configured for the "smtps" service where the client speaks first (as part of the TLS handhake, there is no plaintext SMTP phase). Wietse |
|
|
In reply to this post by Wietse Venema
I have gotten to the point that the keystore used by the jetty application is
properly configured: JAVA_VERSION="12" java -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore -Djavax.net.ssl.trustStorePassword=testing SSLPoke mx32.harte-lyne.ca 465 Successfully connected This means that the server's certificate is properly recognized by the client host. However, we nonetheless get this error from Postfix when we send a test email through the application: Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: 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:1544:SSL alert number 46: Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: lost connection after STARTTLS from accounting-2.internal.harte-lyne.ca[192.168.216.88] I believe that this is telling me that the application is attempting to establish an SSL connection using STARTTLS. However, the error referencing the certificate is mystifying to me. Can someone explain to me what this error means? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:[hidden email] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 |
|
|
On Mon, December 21, 2020 12:30, James B. Byrne wrote: > I have gotten to the point that the keystore used by the jetty application is > properly configured: > > JAVA_VERSION="12" java > -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore > -Djavax.net.ssl.trustStorePassword=testing SSLPoke mx32.harte-lyne.ca 465 > Successfully connected > > This means that the server's certificate is properly recognized by the client > host. > > However, we nonetheless get this error from Postfix when we send a test email > through the application: > > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: 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:1544:SSL alert number > 46: > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: lost connection after STARTTLS > from accounting-2.internal.harte-lyne.ca[192.168.216.88] > > I believe that this is telling me that the application is attempting to > establish an SSL connection using STARTTLS. However, the error referencing the > certificate is mystifying to me. > > Can someone explain to me what this error means? > Let me guess. We do not allow SSLv3. The application uses SSLv3. Our settings: smtpd_tls_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, !SSLv3, !SSLv2 smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, !SSLv3, !SSLv2 And submission requires encryption: smtpd_tls_security_level = may smtpd_tls_auth_only = yes So no fallback is possible. If this is the problem. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:[hidden email] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 |
|
|
James B. Byrne:
> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: 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:1544:SSL alert number > > 46: > > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: lost connection after STARTTLS > > from accounting-2.internal.harte-lyne.ca[192.168.216.88] Results from A web search suggest that this may be a certificate verification problem. What is the output from these commands: postconf -n |grep 'smtpd.*tls' postconf -P |grep 'smtpd.*tls' Which of your three smtpd services is the client connecting to? How can you tell that from Postfix logging? In master.cf we recommend using a distinct syslog_name setting: master.cf: submission inet n - n - - smtpd -o syslog_name=postfix/submission ... smtps inet n - n - - smtpd -o syslog_name=postfix/smtps ... Taking some of the mystery out of Postfix troubleshooting. Wietse |
|
|
In reply to this post by James B. Byrne
On Mon, Dec 21, 2020 at 12:30:57PM -0500, James B. Byrne wrote:
> Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: 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:1544: > SSL alert number 46: > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: > lost connection after STARTTLS > from accounting-2.internal.harte-lyne.ca[192.168.216.88] > > I believe that this is telling me that the application is attempting to > establish an SSL connection using STARTTLS. Yes, the application and the Postfix server are attempting to complete a TLS handshake, indeed after STARTTLS. > However, the error referencing the > certificate is mystifying to me. > > Can someone explain to me what this error means? - The Postfix SMTP server is reporting an error from the underlying OpenSSL library. - That error is receipt of a fatal "SSL alert", i.e. a courtesy message from the *client* that it cannot complete the handshake, and is giving up. - Instead of just disconnecting, the client indicates the reason why it can't go on. - The specific reason is that the clien is unhappy with the server's certificate. SSLv3 is a red herring, the TLS protocol (1.0 through 1.2) evolved from of SSLv3 and shares much code with the original (now deprecated) SSLv3. While TLS 1.3 is a significant departure, it too still shares some of the underpinnings, so you'll see "sslv3" in error messages for all protocol versions from SSLv3 through TLS 1.3. -- Viktor. |
|
|
In reply to this post by Wietse Venema
On Mon, December 21, 2020 13:46, Wietse Venema wrote: > James B. Byrne: >> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: 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:1544:SSL alert >> number >> > 46: >> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: lost connection after >> STARTTLS >> > from accounting-2.internal.harte-lyne.ca[192.168.216.88] > > Results from A web search suggest that this may be a certificate > verification problem. That is what I have been trying to confirm. And after a lot of poking around with Java's keystore/cacrets implementation I think that I have ruled that out: JAVA_VERSION="12" java -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore -Djavax.net.ssl.trustStorePassword=idempiere-2020-ksadmin SSLPoke 192.168.216.32 465 Successfully connected The file /opt/idempiere/idempiere-server/jettyhome/etc/keystore is the java keystore used by the Jetty application. 192.168.216.32 is the host that the application is trying to send email through. I cannot connect to TCP25 with SSLPoke because SSLPoke does not do STARTTLS. Likewise for TCP587. But TCP465 does not do STARTTLS and so the certificate handshake gets initiated and accepted by the client: Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: SSL_accept:before SSL initialization Dec 21 14:19:45 mx32 syslogd: last message repeated 1 times Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: SSL_accept:SSLv3/TLS read client hello Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: SSL_accept:SSLv3/TLS write server hello . . . Dec 21 14:19:45 mx32 syslogd: last message repeated 1 times Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: SSL_accept:SSLv3/TLS read finished Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: accounting-2.internal.harte-lyne.ca[192.168.216.88]: Issuing session ticket, key expiration: 1608578588 Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: accounting-2.internal.harte-lyne.ca[192.168.216.88]: save session 7E720D7E3D4A5307C7CB9D260FCD393FA066ED895E350B36F67322E61C0F0C32&s=smtps&l=269488207 to smtpd cache Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: send attr request = update Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: send attr cache_type = smtpd Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: send attr cache_id = 7E720D7E3D4A5307C7CB9D260FCD393FA066ED895E350B36F67322E61C0F0C32&s=smtps&l=269488207 Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: send attr session = [data 119 bytes] Dec 21 14:19:45 mx32 postfix/tlsmgr[93660]: put smtpd session id=7E720D7E3D4A5307C7CB9D260FCD393FA066ED895E350B36F67322E61C0F0C32&s=smtps&l=269488207 [data 119 bytes] Dec 21 14:19:45 mx32 postfix/tlsmgr[93660]: write smtpd TLS cache entry 7E720D7E3D4A5307C7CB9D260FCD393FA066ED895E350B36F67322E61C0F0C32&s=smtps&l=269488207: time=1608578385 [data 119 bytes] . . . Dec 21 14:19:45 mx32 postfix-p465/smtpd[38338]: SSL_accept:SSLv3/TLS write session ticket > > What is the output from these commands: > > postconf -n |grep 'smtpd.*tls' smtpd_starttls_timeout = ${stress?10}${stress:120}s smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt smtpd_tls_ask_ccert = no smtpd_tls_auth_only = yes smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx32.crt smtpd_tls_ciphers = high smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem smtpd_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, 3DES, RC4, SEED, IDEA, RC2, RC5 smtpd_tls_fingerprint_digest = sha256 smtpd_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx32.key smtpd_tls_loglevel = 2 smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, SSLv3, !SSLv2 smtpd_tls_protocols = TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, SSLv3, !SSLv2 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache smtpd_tls_session_cache_timeout = 3 Note that SSLv3 has only been enabled to carry out these tests. Ihe application would not successfully connect otherwise. > postconf -P |grep 'smtpd.*tls' smtp/inet/smtpd_tls_security_level = may submission/inet/smtpd_recipient_restrictions = permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination submission/inet/smtpd_sender_restrictions = permit_sasl_authenticated,permit_tls_clientcerts,reject submission/inet/smtpd_tls_security_level = encrypt smtps/inet/smtpd_recipient_restrictions = permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination smtps/inet/smtpd_sender_restrictions = permit_sasl_authenticated,permit_tls_clientcerts,reject_unauth_destination smtps/inet/smtpd_tls_wrappermode = yes localhost:2626/inet/smtpd_tls_security_level = none > > Which of your three smtpd services is the client connecting to? > How can you tell that from Postfix logging? > > In master.cf we recommend using a distinct syslog_name setting: > > master.cf: > submission inet n - n - - smtpd > -o syslog_name=postfix/submission > ... > smtps inet n - n - - smtpd > -o syslog_name=postfix/smtps > ... > > Taking some of the mystery out of Postfix troubleshooting. > > Wietse > We use the actual connection port to id the log entries: grep syslog /usr/local/etc/postfix/master.cf -o syslog_name=postfix-p25 -o syslog_name=postfix-p587 -o syslog_name=postfix-p465 -o syslog_name=postfix-p2626 TCP2626 DKIM. I do not believe that this issue is fundamentally a Postfix problem. But to get any traction with the application development team I have to narrow down what exactly is going on between their application and Postfix. The SSLv3 requirement is likely indicative respecting other possible variances from expected behaviour in their email client. Although there is a reference given to a tweak-ssl.xml file which is supposed to allow alterations to SSL protocols and Cyphers the URL to the example given in the documentation is defunct. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:[hidden email] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 |
|
|
In reply to this post by Viktor Dukhovni
On Mon, December 21, 2020 14:20, Viktor Dukhovni wrote: > > - The Postfix SMTP server is reporting an error from the underlying > OpenSSL library. > - That error is receipt of a fatal "SSL alert", i.e. a courtesy message > from the *client* that it cannot complete the handshake, and is giving up. > - Instead of just disconnecting, the client indicates the reason why it > can't go on. > - The specific reason is that the clien is unhappy with the server's > certificate. I agree. And for the past ten days that is what I have been trying to resolve. I finally did that this morning and successfully connected to the mx service host using the exact keystore file that the application uses. JAVA_VERSION="12" java -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore -Djavax.net.ssl.trustStorePassword=testing SSLPoke 192.168.216.32 465 So, there has to be something in the application that is causing this to break. But I am not a Java programmer. I am simply trying to get this messaging feature to work so that we can proceed with our evaluation of idempiere. > > SSLv3 is a red herring, the TLS protocol (1.0 through 1.2) evolved from > of SSLv3 and shares much code with the original (now deprecated) SSLv3. > While TLS 1.3 is a significant departure, it too still shares some of > the underpinnings, so you'll see "sslv3" in error messages for all > protocol versions from SSLv3 through TLS 1.3. > In this case, the connection from the client could not get past the protocol handshake until after SSLv3 was re-enabled. But the advice about misleading error messages is duly noted. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:[hidden email] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 |
|
|
In reply to this post by James B. Byrne
James B. Byrne:
[ Charset ISO-8859-1 converted... ] > > > On Mon, December 21, 2020 13:46, Wietse Venema wrote: > > James B. Byrne: > >> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: 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:1544:SSL alert > >> number > >> > 46: > >> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: lost connection after > >> STARTTLS > >> > from accounting-2.internal.harte-lyne.ca[192.168.216.88] > > > > Results from A web search suggest that this may be a certificate > > verification problem. > > That is what I have been trying to confirm. And after a lot of poking around > with Java's keystore/cacrets implementation I think that I have ruled that out: > > JAVA_VERSION="12" java > -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore > -Djavax.net.ssl.trustStorePassword=idempiere-2020-ksadmin SSLPoke > 192.168.216.32 465 > Successfully connected That proves nothing. This test uses port 465, but your Javamail is connecting to port 25. Also no need to turn on -v logging at all. It just makes the problem harder to see: the client does not like the server certifcate from the service on port 25. Wietse Wietse |
|
|
In reply to this post by James B. Byrne
On Mon, Dec 21, 2020 at 03:11:13PM -0500, James B. Byrne wrote:
> JAVA_VERSION="12" java > -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore > -Djavax.net.ssl.trustStorePassword=testing SSLPoke 192.168.216.32 465 This is largely a non-Postfix issue. You're struggling to configure and use some Java software, and this is not the forum for support with that. It is, however, fair to ask here for clarification of Postfix error messages, and any issues with configuring the certificates/keys for a Postfix SMTP server or client. The particular error is unequivocally the client not liking the server certificate chain. If the server certificate chain (which you can test with: posttls-finger -cC -F /some/CAfile -l secure "[server-name]:25" is as expected, then debugging the client's unhappiness is a proper topic for a different forum. -- Viktor. |
|
|
In reply to this post by Wietse Venema
On Mon, December 21, 2020 15:22, Wietse Venema wrote: > James B. Byrne: > [ Charset ISO-8859-1 converted... ] >> >> >> On Mon, December 21, 2020 13:46, Wietse Venema wrote: >> > James B. Byrne: >> >> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: 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:1544:SSL alert >> >> number >> >> > 46: >> >> > Dec 21 12:25:21 mx32 postfix-p25/smtpd[62565]: lost connection after >> >> STARTTLS >> >> > from accounting-2.internal.harte-lyne.ca[192.168.216.88] >> > >> > Results from A web search suggest that this may be a certificate >> > verification problem. >> >> That is what I have been trying to confirm. And after a lot of poking around >> with Java's keystore/cacrets implementation I think that I have ruled that >> out: >> >> JAVA_VERSION="12" java >> -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore >> -Djavax.net.ssl.trustStorePassword=idempiere-2020-ksadmin SSLPoke >> 192.168.216.32 465 >> Successfully connected > > That proves nothing. This test uses port 465, but your Javamail is > connecting to port 25. > I disagree. What it shows is that Java, using the keystore belonging to the application, can connect and verify an SSL connection to postfix on the target host. The port is immaterial as that does not affect whether or not the client/server certificates are acceptable to the Trust Store. I have just spent two weeks getting to this point. Up until this morning I could not get SSLPoke to successfully connect to the mail service at all. And the error was always to do with the certificate chain. SSLPoke cannot do STARTTLS and thus it will always fail on ports 25 and 587 whether or not the certificate chain was acceptable because it gets an unexpected SSL message. openssl s_client -starttls smtp from the application host has always been able to successfully connect to TCP25 on the target, but openssl does not use the keystore file. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:[hidden email] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 |
|
|
James B. Byrne:
> >> JAVA_VERSION="12" java > >> -Djavax.net.ssl.trustStore=/opt/idempiere/idempiere-server/jettyhome/etc/keystore > >> -Djavax.net.ssl.trustStorePassword=idempiere-2020-ksadmin SSLPoke > >> 192.168.216.32 465 > >> Successfully connected > > > > That proves nothing. This test uses port 465, but your Javamail is > > connecting to port 25. > > I disagree. This test connects to a DIFFERENT Postfix service than the Javamail client. This proves NOTHING about the service that the Javamail client connects to. Wietse |
|
|
In reply to this post by Viktor Dukhovni
On Mon, December 21, 2020 15:42, Viktor Dukhovni wrote: > > This is largely a non-Postfix issue. You're struggling to configure and > use some Java software, and this is not the forum for support with that. I understand that. Java support is not what I am asking for. I am trying to understand what the error messages are telling me. > > It is, however, fair to ask here for clarification of Postfix error > messages, and any issues with configuring the certificates/keys for > a Postfix SMTP server or client. > > The particular error is unequivocally the client not liking the server > certificate chain. If the server certificate chain (which you can > test with: > > posttls-finger -cC -F /some/CAfile -l secure "[server-name]:25" > > is as expected, then debugging the client's unhappiness is a proper > topic for a different forum. > I have used openssl s_client to effect that same test. It has always passed. The problem being that openssl, as postfix, does not use a java keystore to verify certificates. I have finally gotten to the point that the certificate errors are not the Java issue, or at least they should not be, since I can use Java and the keystore to successfully connect to Postfix, albeit on port 465. So, the error is somewhere in the application. But, I did not write it. So I need to pin down what is happening and understand it. Otherwise I will not be able to get anything done with fixing it. If indeed it is is a programing error and not some obscure configuration setting. The help I receive here is invaluable. Thank you. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:[hidden email] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 |
|
|
Dnia 21.12.2020 o godz. 16:33:57 James B. Byrne pisze:
> I have finally gotten to the point that the certificate errors are not the Java > issue, or at least they should not be, since I can use Java and the keystore to > successfully connect to Postfix, albeit on port 465. If you are able to connect via 465, then maybe the application just isn't designed to use "inline" TLS, but rather uses only SMTP-over-TLS? The latter is supported on port 465, while submission via port 587 requires first plaintext connection and then dynamic in-session switchover to TLS, using STARTTLS command. Maybe your application just does not support that? -- Regards, Jaroslaw Rafa [hidden email] -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." |
|
|
On Tue, Dec 22, 2020 at 02:00:27AM +0100, Jaroslaw Rafa wrote:
> If you are able to connect via 465, then maybe the application just isn't > designed to use "inline" TLS, but rather uses only SMTP-over-TLS? The latter > is supported on port 465, while submission via port 587 requires first > plaintext connection and then dynamic in-session switchover to TLS, using > STARTTLS command. Maybe your application just does not support that? It clearly supports STARTTLS, since it is actually performing the TLS handshake, and abandons it after receiving certificates it is not happy with. -- Viktor. |
|
|
In reply to this post by Wietse Venema
On Mon, December 21, 2020 16:12, Wietse Venema wrote: > > This test connects to a DIFFERENT Postfix service than the Javamail client. > This proves NOTHING about the service that the Javamail client connects to. > We are discussing this at cross-purposes. I understand that the service at 465 is not the STARTTLS postfix service. The software I am using to test the SSL connection does not do SMTP in any case. The initial problem was simply getting javamail to recognize the validity of the PKI certificate presented by Postfix. A successful connection to 465 with the certificate chain proves that the certificate Postfix presents is accepted and nothing else. However, up to yesterday, that was the problem. Now I can move on to the next, which is why the application cannot negotiate a STARTTLS with Postfix. The next problem uncovered was that the application insists on using SSLv3 and Postfix was configured with that disabled. Now with SSLv3 enabled on Postfix, albeit temporarily, I need to discover what else is preventing a successful STARTTLS connection. It is like peeling an onion, every problem solved reveals another difficulty. But, eventually one runs out of layers and obtains the desired result. The application is in widespread use so the difficulty has to be local to my set up. I just have to discover what that is. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:[hidden email] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 |
|
|
In reply to this post by Jaroslaw Rafa
On Mon, December 21, 2020 20:00, Jaroslaw Rafa wrote: > > If you are able to connect via 465, then maybe the application just isn't > designed to use "inline" TLS, but rather uses only SMTP-over-TLS? The latter > is supported on port 465, while submission via port 587 requires first > plaintext connection and then dynamic in-session switchover to TLS, using > STARTTLS command. Maybe your application just does not support that? That is a possibility. However, having looked at the example configurations and discussions on the application support groups, it appears to me that connecting to port 25 with STARTTLS is the accepted practice. The problem I had with the certificate negotiation is not uncommon with this application, due to Java's rather idiosyncratic PKI certificate handling. I had reason to believe that when I finally solved that problem then everything else would just work. The SSLv3 problem was a surprise, but was easily compensated for. But, I still cannot get this application to send email so there must be something else that I have done, or not done, which is preventing this from working. And it seems that I am past the SSL problems and into SMTP, I hope. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:[hidden email] Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 |
«
Return to Postfix Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |