Hi friends,
I’ve just set up my first Postfix/dovecot email server using Workaround Jessie Guide; now all works fine, except for the authentication user method, that work on plain text but not on encrypted mode.
/etc/shorewall/rules ACCEPT net $FW tcp 25 #POSTFIX
But, I’m unable to connect using “openssh”:
openssl s_client -connect server.sio4.org:25 -starttls smtp
I’m wondering if the issue could be the letsencrypt certificate, whom doesn’t include the correct domain or a bad Postfix configuration. Because all seem fine to me, but it is also true that this is the first time that I set an email server
Thanks for your help, even if the argument is not entirely relevant (perhaps)
I’ve check and the only closed port was 465, now open and now is possible to send using encrypted password, and a result we brought it home (I do not know if it says so in your country)
now remains the reception (pop and imap) problem of reception. Do it need a special port to handle encrypted login?
I appreciate the help you gave me in any case so far, hopefully I will open a specific request on the mailing list of postfix (although I don’t know how they’ll take with a beginner like me )
The cause of the “man in the middle” attack is that one party is unsure of the other’s identity. In TLS we solve this through certificates signed by a trusted third party, the Certificate Authority. A Certificate Authority’s job is to issue certificates only to the legitimate subjects of those certificates. The Web PKI (HTTPS web sites but also TLS in other places on the Internet) uses a group of public CAs which agree to follow some basic practices for how to validate the subjects of certificates they issue. Let’s Encrypt is one of those CAs. So, when the remote Dovecot server presents a certificate from Let’s Encrypt saying “I am really this Dovecot server imap.example.com, not an imposter” it is very reasonable to believe that is the case.
It would be tremendously difficult to forge the certificate (it is our intention that it should be impractical even for a nation state adversary, such as the NSA, with access to billions of dollars of equipment and very smart people) but it might be possible to influence a CA to issue without proper validation. If you have very sensitive information, you should consider that.
Most IMAP client software today offers a mode where it will prompt you if it is presented with a certificate that is not from one of the Web PKI Public CAs like Let’s Encrypt. For example a “self-signed” certificate produced locally. In this case you can only reasonably be assured that you’re really talking to the intended machine if you examine this certificate carefully to check it is exactly as expected. So long as you trust public CAs to do their job, you don’t need to perform this inspection on certificates they’ve signed, so by default most software will trust these implicitly.
When TLS is applied, the password travels encrypted yes. That's the whole purpose of TLS Everything inside the TLS secured channel is encrypted, the e-mail itself, the password before that.
Most commonly used protocols use just one connection, such as HTTP(S), SMTP, IMAP.. There are exceptions to this of course, such as FTP. FTP uses two TCP connections: one command and one data connection. With FTPS, """secure FTP""", many times only the command connection is secured with TLS. Luckily, the password is send through this secured command connection, but all the data subsequently send isn't secured. But as said, this isn't the case for the many common protocols we're talking about here (web/email).
I add a piece of information just received from the Dovecot mailing list, always in relation to the question object.
From the Dovecot mailing list, Steffen Kaiser, to enable the password encrypted mode (now, through you, I know that this is a feature even excessive, but I want to understand), suggest me to add the “ssl_ca” to the Dovecot configuration (/etc/dovecot/conf.d/10-ssl.conf:ssl_key I suppose).
Now the question is:
for Letsencrypt the “ssl_ca” correspond to chain.pem?
Thank you all again for all the time that you’re dedicating to me (and hope to all those who might be interested in this topic)
Client certificate verification/authentication
If you want to require clients to present a valid SSL certificate, you'll need these settings:
ssl_ca = </etc/ssl/ca.pem
(...)
So: no, you don’t need ssl_ca, as you don’t want to enable client certificate verification/authentication, because that’s impossible with DV certificates like Let’s Encrypt issues.
Also, the problem you’re mentioning in your question to the Dovecot mailing list (“Verify return code: 20 (unable to get local issuer certificate)”) has nothing to do with using encrypted passwords!
OpenSSL produced that error. OpenSSL is only the TLS client and it has nothing to do with the underlying protocol, such as IMAP or SMTP, which are in charge of the plaintext or encrypted password handling!
Also, my openssl outputs " Verify return code: 0 (ok)". So it’s probably more likely your OpenSSL can’t find the root certificate store of your OS. Try connecting to this forum:
)
