Javamail connection

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Javamail connection

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

Wietse Venema
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
>
Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

James B. Byrne


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

Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

James B. Byrne
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

Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

James B. Byrne


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

Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

Viktor Dukhovni
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.
Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

James B. Byrne
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

Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

James B. Byrne
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

Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

Viktor Dukhovni
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.
Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

James B. Byrne
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

Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

James B. Byrne
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

Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

Jaroslaw Rafa
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."
Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

Viktor Dukhovni
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.
Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

James B. Byrne
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

Reply | Threaded
Open this post in threaded view
|

Re: Javamail connection

James B. Byrne
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

12