Error: com.sun.mail.smtp.SMTPAddressFailedException: 554 5.7.1 : Recipient address rejected: SASLUsername Domain and Sender Domain Are Differnet [closed] - ssl

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year.
This post was edited and submitted for review last year and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
I am tying to send email using JavaMailSender. I am able to send email to my gmail account using this configuration.
mail:
host: smtp.gmail.com
port: 587
username: xyz*****#gmail.com
password: ***************
protocol: smtp
properties.mail.smtp:
auth: true
starttls.enable: true
ssl.trust: smtp.gmail.com
But when I use another server with the following config I get this error : "com.sun.mail.smtp.SMTPAddressFailedException: 554 5.7.1 **********#gmail.com: Recipient address rejected: SASLUsername Domain and Sender Domain Are Differnet - Sender Blocked"
mail:
host: mail.xyz***xyz.com
port: 25 (or 587)
username: noreply#xyz***xyz.com
password: **************
protocol: smtp
properties.mail.smtp:
auth: true
starttls.enable: false
ssl.trust: mail.xyz***xyz.com
sockeFactory.class: javax.net.ssl.SSLSocketFactory
ssl.protocols: TLSv1
When I change starttls.enable: true I get error: javax.mail.MessagingException: Could not convert socket to TLS; nested exception is: javax.net.ssl.SSLHandshakeException: Certificates do not conform to algorithm constraints
After I remove sockeFactory.class: javax.net.ssl.SSLSocketFactory and ssl.protocols: TLSv1 I get Error : the-server-selected-protocol-version-tls10-is-not-accepted-by-client-preferences
Can anyone help me out resolving these configurational issues.

This is happening because Zimbra has a setting which ensures that the credentials used for sending and authentication need to be same. Please check your code to ensure that your javamail From and auth are using the same email address. This should solve the error.

Related

FTP Connection control connection closed with Handshake failure

I am facing issue while sending file from Sterling File Gateway to external FTP Server using FTPS Protocol setup. Recently the certificate on server side has been expired and we have added the renewed cert on our B2bi and SSP with Root,Intermediate, public cert.
From there we started to Handshake failures on Perimeter logs.
Error:
ERROR [TLSCheck.validCerta] validateErr not 0, failing check: 4
ERROR [TLSCheck. validCerts) error (s) is/are: ERR_CERT OTHER ERROR,
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
Caused by: java.security.cert.CertificateException: [TLSCheck.certificateCallback] toolkit level returns false
Please let me know what could be the issue.
Thanks in Advance

IBM MQ expects username and password when using SSL certificates (Error 2035)

I am stuck at using SSL in IBM Websphere MQ (9.2).
I am building a client library for MQ and to get more familiar with MQ on the server side I have installed IBM MQ Developer edition and ran the supplied scripts to create a 'default' MQ server instance.
Created an client connection for the DEV.APP.SVRCONN server connection
Created a personal certificate by using the IBM Key management tool and named it ibmwebspheremq
Enabled SSL on the Queue Manager (QM1) and labelled it ibmwebspheremq
Updated the SSL configuration for the DEV.APP.SVRCONN channel and set the cipherspec property to TLS 1.2, 256-bit Secure Hash Algorithm, 128-bit AES encryption (TLS_RSA_WITH_AES_128_CBC_SHA256) and made SSL required.
Tested my settings with:
amqssslc -l ibmwebspheremq -k C:\ProgramData\IBM\MQ\qmgrs\QM1\ssl\key -c DEV.APP.SVRCONN -x 127.0.0.1 -s TLS_RSA_WITH_AES_128_CBC_SHA256 -m QM1
And that gave me:
Sample AMQSSSLC start
Connecting to queue manager QM1
Using the server connection channel DEV.APP.SVRCONN
on connection name 127.0.0.1.
Using SSL CipherSpec TLS_RSA_WITH_AES_128_CBC_SHA256
Using SSL key repository stem C:\ProgramData\IBM\MQ\qmgrs\QM1\ssl\key
Certificate Label: ibmwebspheremq
No OCSP configuration specified.
MQCONNX ended with reason code 2035
Error details (from log):
The active values of the channel were 'MCAUSER(app) CLNTUSER(Wilko)
SSLPEER(SERIALNUMBER=61:9B:A4:3E,CN=DESKTOP-ROH98N2,C=NL)
SSLCERTI(CN=DESKTOP-ROH98N2,C=NL) ADDRESS(DESKTOP-ROH98N2)'. The
MATCH(RUNCHECK) mode of the DISPLAY CHLAUTH MQSC command can be used to
identify the relevant CHLAUTH record.
ACTION:
Ensure that the application provides a valid user ID and password, or change
the queue manager connection authority (CONNAUTH) configuration to OPTIONAL to
allow client applications to connect which have not supplied a user ID and
password.
----- cmqxrmsa.c : 2086 -------------------------------------------------------
22/11/2021 15:51:37 - Process(15880.45) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(DESKTOP-ROH98N2) Installation(Installation1)
VRMF(9.2.3.0) QMgr(QM1)
Time(2021-11-22T14:51:37.594Z)
CommentInsert1(DEV.APP.SVRCONN)
CommentInsert2(15880(1112))
CommentInsert3(127.0.0.1)
AMQ9999E: Channel 'DEV.APP.SVRCONN' to host '127.0.0.1' ended abnormally.
EXPLANATION:
The channel program running under process ID 15880(1112) for channel
'DEV.APP.SVRCONN' ended abnormally. The host name is '127.0.0.1'; in some cases
the host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
----- amqrmrsa.c : 630 --------------------------------------------------------
I am kind of stuck, I also saw in the log that there is PEER related info dumped, but I am not sing the SSLPEER settings (I just want to let everyone connect with the same certificate).
EDIT 2:
Output from RUNMQSC QM1 and command DISPLAY QMGR CONNAUTH:
1 : DISPLAY QMGR CONNAUTH
AMQ8408I: Display Queue Manager details.
QMNAME(QM1) CONNAUTH(DEV.AUTHINFO)
Output from RUNMQSC QM1 and command DISPLAY AUTHINFO(name-from-previous-command):
3 : DISPLAY AUTHINFO(DEV.AUTHINFO)
AMQ8566I: Display authentication information details.
AUTHINFO(DEV.AUTHINFO) AUTHTYPE(IDPWOS)
ADOPTCTX(YES) DESCR( )
CHCKCLNT(REQDADM) CHCKLOCL(OPTIONAL)
FAILDLAY(1) AUTHENMD(OS)
ALTDATE(2021-11-18) ALTTIME(15.09.20)
Output from DISPLAY CHLAUTH(*):
4 : DISPLAY CHLAUTH(*)
AMQ8878I: Display channel authentication record details.
CHLAUTH(DEV.ADMIN.SVRCONN) TYPE(USERMAP)
CLNTUSER(admin) USERSRC(CHANNEL)
AMQ8878I: Display channel authentication record details.
CHLAUTH(DEV.ADMIN.SVRCONN) TYPE(BLOCKUSER)
USERLIST(nobody)
AMQ8878I: Display channel authentication record details.
CHLAUTH(DEV.APP.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
CHCKCLNT(REQUIRED)
AMQ8878I: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878I: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
I was expecting not having to provide username and password when using certificates. What am I missing here?
Your queue manager is configured to mandate passwords for any client connections that are trying to run with a resolved MCAUSER that is privileged. That is what CHCKCLNT(REQDADM) on your AUTHINFO(DEV.AUTHINFO) does.
In addition, your CHLAUTH rule for the DEV.APP.SVRCONN channel has upgraded this further to mandate passwords for ALL connections using that channel.
If your intent is to have channels that supply a certificate not be subject to this mandate, then you should add a further, more specific, CHLAUTH rule, something along these lines:-
SET CHLAUTH(DEV.APP.SVRCONN) TYPE(SSLPEERMAP) +
SSLPEER('SERIALNUMBER=61:9B:A4:3E,CN=DESKTOP-ROH98N2,C=NL') +
SSLCERTI('CN=DESKTOP-ROH98N2,C=NL') CHCKCLNT(ASQMGR) USERSRC(CHANNEL)
Bear in mind that if this connection is asserting a privileged user id, it will still be required to supply a password from the system-wide setting of CHCKCLNT(REQDADM).
Remember, if you are ever unsure which CHLAUTH rule you are matching against, all those details you saw in the error message can be used to form a DISPLAY CHLAUTH command to discover exactly which rule you have matched. Read more about that in I’m being blocked by CHLAUTH – how can I work out why?

Puppet agent fail to connect to master [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 7 years ago.
Improve this question
I'm struggling since 2 days with signing of Puppet-Agents now. The Problem is as follows:
On the master I delete all existing signatures with
puppet cert clean esx-poc-1.xxx.de
On the agent I delete the whole ssl directory with
rm -rf /var/lib/puppet/ssl/
After running one of the following commands on the agent...
puppet certificate generate esx-poc-1.xxx.de --ca-location remote
puppet agent --server puppetmaster.int.xxx.com --waitforcert 60 --test
...I can list the certificates on the master with:
puppet cert list --all
The output is:
"esx-poc-1.xxx.de" (SHA256)
71:72:D8:3E:09:9E:B1:5C:DA:78:A8:B8:A1:2B:E4:09:B8:00:8A:AF:49:02:CC:B2:B5:C3:25:79:59:0D:A8:F5
+ "puppetmaster.int.xxx.com" (SHA256) 7B:00:8C:4F:CE:B2:0D:2F:A1:BB:A7:C4:25:B0:11:01:2B:EC:90:46:D1:CB:BE:AA:AD:3F:B4:70:0C:83:3F:78
(alt names: "DNS:puppet", "DNS:puppet.xxx.de",
"DNS:puppetmaster.int.xxx.com")
After signing the agent with:
puppet cert sign esx-poc-1.xxx.de
The fingerprint differs from the one above:
"esx-poc-1.xxx.de" (SHA256) 49:F6:59:FD:3C:28:C6:54:7F:6E:A7:56:56:DB:64:9A:E2:08:10:90:11:83:7A:A6:0E:E1:CD:39:F0:E0:1C:25
Is that correct?
Performing an agent-run aferwards results in the following error:
Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 400 on SERVER: Could not retrieve facts for esx-poc-1.xxx.de: Failed to submit 'replace facts' command for esx-poc-1.xxx.de to PuppetDB at puppetmaster.int.xxx.com:8081: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppetmaster.int.xxx.com] Info: Retrieving plugin Info: Loading facts in /var/lib/puppet/lib/facter/last_run.rb Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb Info: Loading facts in /var/lib/puppet/lib/facter/puppi_projects.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Loading facts in /var/lib/puppet/lib/facter/iptables.rb Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for esx-poc-1.xxx.de to PuppetDB at puppetmaster.int.xxx.com:8081: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppetmaster.int.xxx.com] Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run
Thx for any help!
Ran into this exact same issue myself. The problem ended up being that the puppetdb-terminus package was at version 1.1.0 while puppetdb itself was still at 1.0.5.
After downgrading puppetdb-terminus down to 1.0.5 everything operated normally.
In puppet 3.4 I noticed that if the hostnames are not set this error could be thrown.
For example; I had two debian boxes; one was named debian1 and the other debian2 in the hosts file. But, both of their /etc/hostname settings where debian; after I changed their name with hostname and set their names in /etc/hostname they worked just fine.
This might be a dumb question, but, do you have a node definition for this machine? I.e.,
node 'esx-poc-1.xxx.de' {
.....
}
I had this error after changing permission of files in /etc/puppet.
Changing them back to 'pe-puppet' (for an enterprise version) solved it for me
After completely reinstalling puppetdb it's finally working...

Connection failing with pop3 using java mail api to Exchange server

I am facing issue, connecting clients Exchange server via JAVAMAIL api using pop3. It works fine with gmail. Please look into this, if is something familiar.
Following exception we get while trying to connect on client's Exchange server
javax.mail.MessagingException: Connect failed;
nested exception is:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connecti
on?
at com.sun.mail.pop3.POP3Store.protocolConnect(POP3Store.java:210)
at javax.mail.Service.connect(Service.java:295)
at TestPOP3Connection.run(TestPOP3Connection.java:23)
Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext conne
ction?
at com.sun.net.ssl.internal.ssl.InputRecord.handleUnknownRecord(Unknown
Source)
at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Un
known Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Sou
rce)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Sou
rce)
at com.sun.mail.util.SocketFetcher.configureSSLSocket(SocketFetcher.java
:507)
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:238)
at com.sun.mail.pop3.Protocol.<init>(Protocol.java:107)
at com.sun.mail.pop3.POP3Store.getPort(POP3Store.java:261)
at com.sun.mail.pop3.POP3Store.protocolConnect(POP3Store.java:206)
... 2 more
Thanks in advance
Rohit
You're trying to connect using SSL, but you're connecting to a port that doesn't support SSL.
Gmail requires SSL, so your program is probably set up to do that, but then when changing to use your Exchange server you probably changed the host name and set the port number to 110. The SSL port number for POP3 is 995. Of course, make sure your Exchange server is configured to accept SSL requests on that port.

Unable to connect because your certificate is not yet valid. Check that your system time is correct [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
I don't know what i did wrong. My time is correct, i even updated it from microsoft.
client config:
tls-client
client
dev tun
proto udp
remote xx.xxx.xxx.xxx 80
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
comp-lzo
verb 3
reneg-sec 0
route-method exe
route-delay 2
ca ca.crt
auth-user-pass
Server config:
local xx.xxx.xxx.xxx
port 80
proto udp
dev tun
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so /etc/pam.d/login
client-cert-not-required
username-as-common-name
server 10.8.0.0 255.255.0.0
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
comp-lzo
persist-key
persist-tun
#status /etc/openvpn/logs/serverstatus-tcp.log
#log /etc/openvpn/logs/serverlog-tcp.log
verb 3
float
duplicate-cn
#Limit server to a maximum of n concurrent clients.
max-clients 15
keepalive 20 300
I had this problem too... Check and update (if necessary) the date/time on both client and server. In my case the server clock was NOT correct when the certificate was created. Just correct the clock (date and time) on server, then DELETE old certificates and RE-ISSUE all certificates.