So I set up a mail server on my VPS with cyberpanel and I can send emails manually through rainloop. I also have a program based on the lettre crate for Rust which runs perfectly fine on my own devices and correctly sends emails out through code. However when I try to run the program on my VPS, I get the following messages in my syslog.
globalfun postfix/smtps/smtpd[24656]: connect from localhost[::1]
globalfun postfix/smtps/smtpd[24656]: SSL_accept error from localhost[::1]: -1
globalfun postfix/smtps/smtpd[24656]: warning TLS library problem: error 14094418:SSL routines:ssl3_resl3_read_bytes: tlsv1 alert unknown ca:../ssl/rec/layer_s3.c:1543:SSL alert number 48:
globalfun postfix/smtps/smtpd[24656]: lost connection after CONNECT from localhost[::1]
globalfun postfix/smtps/smtpd[24656]: disconnect from localhost[::1] commands=0/0
I don't really understand why I can't send out emails through my program but it seems to have something to do with SSL. For reference, I have two servers on the same domain - one for my website which has an SSL installed through Let's Encrypt and another for the mail server which doesn't have SSL on it. That said, I don't think that's the issue as I can send emails through the mail server manually completely fine. Does anyone have any ideas as to what's wrong? Thanks in advance.
globalfun postfix/smtps/smtpd[24656]: warning TLS library problem: error 14094418:SSL routines:ssl3_resl3_read_bytes: tlsv1 alert unknown ca:../ssl/rec/layer_s3.c:1543:SSL alert number 48:
Your client refuses to connect to your mail server since it does not trust the CA which issued the mail servers certificate. It notifies the server about this problem by sending a unknown ca TLS alert.
There can be various reasons for this. Typically it is either the use of a CA which is not trusted by the client which need to be fixed at the client (trust this CA) or at the server (use a certificate from a CA trusted by the client). Or the root CA is actually trusted but the server is not sending the intermediate certificates needed by the client to build the trust chain to this trusted root CA. This need to be fixed at the server.
Related
CocoaMQTT client is running on iOS15 with the SSL enabled as shown in this example. The cert_key.p12 file was merged from the client.crt and client.key files signed by the same (self-created) CA that was used for the MQTT server/broker certificate generation. The MQTT broker is configured to require client's certificate and use its CN as the username. The handshake does not go well - the log complains about the unknown certificate:
New connection from 192.168.1.87 on port 8883.
OpenSSL Error[0]: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
Based on the above error research, the broker does not like the client's certificate, right? In fact, looking at the wireshark's log, it seems like the client does not send the certificate to the server. Is that something I need to enable in the App configuration? Does the Swift CocoaMQTT package even support this feature (provide the cert to the broker)?
EDIT:
I tried running a client with the same cert/key with paho mqtt implemented in python, which also allows to provide the client with the CA certificate, and everything runs ok:
Trying using the same client's cert/key in CocoaMQTT implemented in iOS15 shows the MQTT broker log error message as above and the fatal alert shows up the the wireshark log:
Initially, I thought that the sever did not like (or did not receive) the client's certificate, but that fatal alert package destination is port 8883. So now I tend to believe that it's the client, who does not like the server's certificate. This is expected if the client uses the pool of official CAs to verify the certificate instead of recognizing that its own certificate was issued by the same CA as the server's one. This is further confirmed by setting the allowUntrustCACertificate = true and seems like the handshake is suspended and no more communication occurs:
There's also a debug message on the client's side:
Call the SSL/TLS manually validating function
So it looks like the client will not continue the communication until this validation process occurs. As #Brits mentioned in his comment, there's a callback to validate the cert manually but it is implemented as a part of the delegate. I do see that there's a method mqtt.didReceiveTrust which I assume should be used for cert validation, and I wish to use the closures approach as stated on the README page as giving an example for the didReceiveMessage methond:
Now you can use closures instead of CocoaMQTTDelegate:
mqtt.didReceiveMessage = { mqtt, message, id in
print("Message received in topic \(message.topic) with payload \(message.string!)")
}
With a weak understanding of Swift Closures, I am not able to figure out how to make that function all, so the question now becomes: how to convert that function from the delegate definition into the closure?
I am connecting to an HIE in two interfaces using Direct Messaging - one to send messages and one to retrieve messages. The first uses a protocol of SMTP connecting on port 587 without SSL/TLS and then issuing a STARTTLS. All outbound Direct messages goes to this protocol; the HIE forwards the messages to the designated recipient. This works 100% of the time.
The retrieval interface also uses Direct Messaging, but connects with IMAP protocol on port 993. SSL/TLS is used, but there is no STARTTLS issued. This used to work 100% of the time. Now it fails on every connect attempt.
The error message is:
[java:java:ERR /1:fr_RHIO_direct_2:--/--/---- --:--:--] Catch Execption:
[java:java:ERR /1:fr_RHIO_direct_2:--/--/---- --:--:--] javax.mail.MessagingException: com.ibm.jsse2.util.h: PKIX path building failed: com.ibm.security.cert.IBMCertPathBuilderException: unable to find valid certification path to requested target;
Last week both interfaces failed at the same time with this PKIX path building error. The HIE sent us an updated digital certificate. The old one was removed from the keystore and the new one was imported. Upon recycling of the interfaces, the SMTP sending interface was restored to working order. However the retrieving interface is still failing with the same error.
Both interfaces use the same keystore. The configuration screens for both interfaces include a "keystore validation" function - both validate successfully, proving the location of the keystore and its password are correct in both interfaces.
Before last week, both interfaces worked correctly. Now only one works. The HIE uses Mirth Mail.
How is it possible that the same certificate path is correct in one interface but incorrect in another?
That was the right direction. it turns out that we were the only client to use IMAP; everyone else uses XDR. They had forgotten what to do with the IMAP service when a certificate is replaced. They had to restart a service called DOVECOT. Thanks for looking.
I don't know if I am asking this in the right place.
I have an SSL cert for my website, and I am trying to setup a mail server (same domain) using the same cert.
I am using Postfix and Dovecot. When I try logging in from Evolution mail client, I get an error "Peer failed to perform TLS handshake". When I try an online service to verify I get "Recipient address rejected: User unknown in local recipient table."
I guess my actual question is, can I actually use the same SSL cert for my website and my email server?
What do I do to debug next?
You can use a certificate you have for the web server also for your mail server as long as it matches the hostname you use to access your mail server. Of course the certificate need to properly setup at the mail server, i.e. include the necessary intermediate certificates similar to how it is (hopefully) setup on the web server.
I am using Postfix and Dovecot.
This means you need to take care of multiple configurations, both for SMTP in Postfix and IMAP/POP3 (whatever you use) in Dovecot. And in all cases the certificates subject/SAN must match the hostname you use to connect to the server.
When I try logging in from Evolution mail client, I get an error "Peer failed to perform TLS handshake".
There are not enough information about this setup to find out what exactly is causing the TLS error. It is not even clear if the error is caused when retrieving mail (IMAP/POP3, i.e. Dovecot) or while sending (Postfix).
When I try an online service to verify I get "Recipient address rejected: User unknown in local recipient table."
This has nothing to do with TLS at all. The test server simply tried to use a recipient which your mail server (Postfix) will not accept.
What do I do to debug next?
The next steps would probably be to check if the certificate matches the names you use in the first place and to look into log files for error messages or warnings. Following steps depend on what the result of these steps is.
I am using google apps for email. I can send email out through c# code fine with smtp.gmail.com.
I would like to be able to use the name smtp.mydomain.com instead, but still have it go to smtp.gmail.com. I tried just seeing a CNAME in my DNS settings, but I get this error:
"The remote certificate is invalid according to the validation procedure."
Any ideas?
Thanks.
Yes, you can't, the TLS certificate used to communicate privately with the remote SMTP server is signed with smtp.gmail.com. The only solution is to create a SMTP relay with sendmail for example on your own server.
I've godaddy's 2048bit certificate for domain and 4 subdomains.
[www.site.com, mail.site.com, e.t.c.]
Standard Multiple Domain (UCC) SSL Up to 5 Domains - 1 year (annual)
That certificate works fine in Apache, ssl web checker says OK and browser shows green line in address string.
I've added this certificate to mail daemon, it has been accepted by Exim too.
When some client tries to send mail with SSL/TLS connection through mail server, mail program says "Certificate is BAD" though shows correct trusted info.
Client connects to hostname: mail.server.com, server's hostname is: ns1.server.com (not added to certificate), mail server says: 220 ns1.site.com ESMTP Exim 4.73
Mail clients tested: iPAD mail client, Mozilla Thunderbird, Mac mail client
Please help.
UPDATE:
Godaddy's ssl checker says: SSL Chain of Trust is Broken!
Here are a couple of things to check:
Is the hostname that the mail client uses in the TCP connect, listed in the server certificate as the Common Name (CN) of the subject distinguished name?
If not, is it listed using type "DNS:" in the Subject Alternative Name X509 v3 certificate extension?
If neither of the above, you might be getting "Remote Certificate Name Mismatch" (or similarly named error.)
If it is listed, then look for the Issuer of the certificate, and Issuer of the Issuer, etc., all the way to the root certificate of the chain. The root certificate should be installed on the client machine, in the "Trusted Root" certificate store for whatever client you are using (Windows, Mozilla, Java keystore, etc.)
If the root certificate is installed, then look at the intermediate certificates, if there are any in the chain (between root and server certificates). They have to either be installed locally, or arrive from the server alongside the server certificate -- either the server sends them each time or you've got the intermediate certificates already installed on the client end. Either way, they have got to be in hand to accept the server certificate.
Do the clients which reject the certificate have the appropriate root certificates in their cert store?