Why SSL Is So Slow to Catch On................

[Anthony Parsons]

What documentation have you found that states that governmental entities won't accept an approved global CA issued certificate.

Not what I said. If a mail server requires a trusted TLS connection in order to send to, then Lets Encrypt (LE) will fail, as they are not considered trusted. Some Government organisations and large corporate networks often require their outgoing mail connections to only connect with TRUSTED TLS connections. Smaller organisations seem to be slowly opting only for TRUSTED TLS connections too.

I would put it down to a sign of our times, more than anything.

Yes, you can send with LE, you can receive too, you can establish a TLS connection for websites and such... BUT, if you want to receive mail and not bounce anyone sending to you, then LE is not the TLS you use for your mail server FQDN. It will fail validation from any org that has set their mailer to require a TRUSTED TLS connection.

Use it on your website -- DON'T USE IT ON YOUR MAIL FQDN -- not if you want to accept all email without issue.

The issue is now becoming more common -- and for business, you can't afford for current or potential customers to have their email bouncing all because you opted for a free vs $10 per annum trusted CA.

Honestly, if you ran a large website that the FQDN did a lot of mail receiving, you would have people using their work email that would likely be bouncing if your incoming FQDN is registering as untrusted connection. They've probably shifted to an online email account with less strict rules (gmail, yahoo, hotmail, etc).

 

[eva2000]

Not what I said. If a mail server requires a trusted TLS connection in order to send to, then Lets Encrypt (LE) will fail, as they are not considered trusted.

I think you may have mixed up the definition of TLS Trusted connection or mixed Letsencrypt staging test certs with live ssl certificates. Letsencrypt staging ssl certs won't be trusted but Letsencrypt live ssl certificates are trusted at CA root level. Only time you email connections will be TLS untrusted is if you mail MTA config's CAFile definition is out dated or MTA i.e. Postfix not configured properly (i.e. at least for Postfix setup for opportunistic TLS configuration via smtp_tls_security_level & smtpd_tls_security_level as both these default to none for no encryption so TLS untrusted connections would exist) or if you specifically remove IdentTrust/Letsencrypt CA root stores from your server system CAfile used by your MTA i.e. postfix.

i.e. Postfix the TLS connection trust is established provided appropriate tls security level is set from smtp_tls_CAfile and smtp_tls_CApath settings of which most system's CA file/path has IdentTrust/Letsencrypt CA trusted unless you specifically remove them.

 

[Rusty Snippets]

Just read about this new security product..................... what do you all think?


CloudLinux Releases Imunify360 to Help Web Hosts Secure Linux Servers

Hosting OS developer CloudLinux announced on Wednesday the release of an all-in-one automated security product for web hosting providers, called Imunify360.

Imunify360 works on CentOS, Red Hat, and CloudLinux OS 6 and 7, and protects Linux VPS, dedicated, and shared servers. Its dashboard is integrated with cPanel, with DirectAdmin, Plesk, and no-panel support coming soon. It includes smart intrusion detection and protection systems (IDS/IPS), and intelligent sandboxing is among the features coming soon, the company said this week at World Hosting Days in Germany.

Web hosting providers can benefit from Imunify360’s sophisticated threat detection, provided by its self-learning firewall with herd immunity, as well as its malware scanning engine for detecting and removing malware from websites before they are delisted and blocked, CloudLinux said. Imunify360 also provides cost efficiency with automation and a single management dashboard, and live kernel patching with KernelCare, providing security updates without impacting customer satisfaction with reboots.............................

http://www.thewhir.com/web-hosting-...ify360-to-help-web-hosts-secure-linux-servers

http://imunify360.com/

 

[Anthony Parsons]

Only time you email connections will be TLS untrusted is if you mail MTA config's CAFile definition is out dated or MTA i.e. Postfix not configured properly (i.e. at least for Postfix setup for opportunistic TLS configuration via smtp_tls_security_level & smtpd_tls_security_level as both these default to none for no encryption so TLS untrusted connections would exist) or if you specifically remove IdentTrust/Letsencrypt CA root stores from your server system CAfile used by your MTA i.e. postfix.

Hmmm... have you logged this with trusted tls in your logs using LE?

Hosting OS developer CloudLinux announced on Wednesday the release of an all-in-one automated security product for web hosting providers, called Imunify360.

Just looked. Honestly.... an easy solution outsource for what you can do yourself, and freely. I left cpanel and its costs because a server shouldn't be bloated with nonsense and cost an arm and a leg. Money is better at the server than throwing it at other solutions IMHO.

 

[eva2000]

Hmmm... have you logged this with trusted tls in your logs using LE?

Just tested on Centmin Mod issued Letsencrypt SSL live certificate via DNS domain validation with Amazon AWS Route53 and switched default Postfix MTA configured opportunistic tls encryption mode from self-signed ssl cert to Letsencrypt issued SSL certificate and did a test email send from server to Gmail

works fine as long as you properly configure Postfix MTA

tail -6 /var/log/maillog
Apr  4 23:16:29 host postfix/cleanup[15803]: 50245400CB1: message-id=<20170405031629.50245400CB1@host.domain.com>
Apr  4 23:16:29 host postfix/qmgr[15791]: 50245400CB1: from=<root@host.domain.com>, size=476, nrcpt=1 (queue active)
Apr  4 23:16:30 host postfix/smtp[15805]: Trusted TLS connection established to aspmx.l.google.com[209.85.144.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Apr  4 23:16:31 host postfix/smtp[15805]: 50245400CB1: to=<email@gmail.com>, relay=aspmx.l.google.com[209.85.144.27]:25, delay=1.8, delays=0.01/0.02/1.5/0.27, dsn=2.0.0, status=sent (250 2.0.0 OK 1491362191 g31si16770347qtd.289 - gsmtp)
Apr  4 23:16:31 host postfix/qmgr[15791]: 50245400CB1: remove

Email MTA TLS Trust is only verified via CA File match of ssl certificates common name/SANs match to CA authority. As long as Letsencrypt/IdenTrust CA roots are in CA file on your server system + properly configured MTA i.e. Postfix, then email should establish a Trusted TLS connection.

 

[Anthony Parsons]

What about sending into your mail server FQDN using LE? That is the issue. Your sending to Gmail, using trusted CA, is your mail server considered the same when sending into it?

This is the test I did between two mail servers. Not sending out, but sending in to the mail server. Other providers deemed the mail server CA as untrusted sending to my FQDN using LE live cert, and yes, setting up the capath correctly.

It was people sending INTO my mail server FQDN using LE. That is where people where bouncing.

If you SEND from your MTA which requires TRUSTED TLS at the receiver, LE failed as the receiver and bounced as untrusted TLS CA. Changing LE out fixed the issue.

 

[eva2000]

I use Google Gsuite/Google App for inbound emails - Postfix is only for outbound server sent emails. I have better things to do with my time than manage my own local server for inbound mail/spam/anti-virus management and mail server ip reputation management and monitoring

For server level Postfix inbound tls security level needs to be set separately and appropriately from outbound tls security level as it defaults to none (no encryption out of the box). You can't set it to require only secure connections as your user's client may not support it so your server's Postfix would reject email - so at best use opportunistic tls encryption.

 

[Anthony Parsons]

I use Google Gsuite/Google App for inbound emails

Ok. Which is utilising Googles FQDN CA trust to return that message to you.

I'm not denying that LE is trusted sending. LE is NOT TRUSTED when used as the FQDN mail server (receiver). You're using Google (receiver CA trusted), which is what provides the trusted notification when requiring implicit trust as the sender (from postfix or such) to your receiving server.

I could not get LE to produce TRUSTED TLS as the FQDN receiving server.

My issue arose when I was using a cpanel instance as a mail server for clients. I've progressively shifted away from cpanel, apache, and to simple / performance solutions. When using cpanel I had a positivessl cert as the WHM FQDN, thus all receiving TLS connections where being trusted. (went and tested this to confirm)

When I switched out to use iredmail for clients mail, I just installed an LE cert with script for renewal, thinking that was nice and easy, no more hassle or having to worry about renewals. Clients began ringing me that their clients email where bouncing. So I went digging. It was that LE CA bundles do not (I do not know why) resolve as TRUSTED TLS when used as the receiving mailer. I had played with this Zhang at iredmail... and he put me onto the ca path components and such, did all of that, swapped around the LE chain, full chain, so forth, no go.

Thought I would try a positive ssl cert with CA bundle, did that, boom... suddenly my FQDN was now receiving as a TRUSTED TLS mail receiver. Suddenly anything that had soft bounced started coming through from clients clients.

Sending is not a problem for trust. Receiving as the mail server FQDN seems to be the problem with LE if the sender requires trusted TLS to deliver the mail to.

 

[eva2000]

it's probably your setup/configuration. One common issue is folks accidentally used Letsencrypt staging ssl cert and not live trusted ssl certificate. Might want to ask folks on official Letsencrypt support forum https://community.letsencrypt.org/

 

[Anthony Parsons]

I thought that... I googled, I read, I asked... I experimented, I was given some good advice that was needed, but still did not work with LE when used as a mail receiving FQDN. All I had to do is swap the cert and CA bundle, nothing else, it changed the receiving message sent to senders, just as you did above, from untrusted to trusted tls.

I had an email guy take a look through it, just to verify I hadn't missed something. LE is not trusted. Even sending from LE to LE when both are used as the sending and receiving FQDN, did not trust itself. Positive SSL CA bundle, immediately trusted and fixed the problem.

I'm with you -- LE should technically be trusted as the FQDN receiver, but it isn't. When I went looking there was actually a whole lot I found on thawte and other big providers certs having trust issues, especially from Google. It was a learning experience.

I expected it to work perfectly once all settings were confirmed and correct. They were. I couldn't understand it either, but when LE didn't trust its own issuing cert at another server, that got me super curious. Purely a CA trust problem.

 

[TPerry]

Not what I said. If a mail server requires a trusted TLS connection in order to send to, then Lets Encrypt (LE) will fail, as they are not considered trusted.

The point being since it's a recognized global CA, it should be "trusted". It's in the same trust file as any of the other. There certs are also cross-signed by IdenTrust.
What they will NOT work with is the actual encryption for use.
And, as I have said, I have absolutely no issues delivering to anyone I have had to send to - Google, Hotmail, Yahoo, ComCast, etc.

Received: from whiskey.redneckhost.com (whiskey.redneckhost.com. [149.56.33.156]) by mx.google.com with ESMTPS id w10si16460089itf.37.2017.04.04.21.11.05 for <masked@ride-texas.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 21:11:05 -0700 (PDT)

 

[Anthony Parsons]

it should be "trusted"

Totally agree with you. It "should" be trusted. But it isn't. Even by itself sending from LE FQDN to LE FQDN servers -- returns untrusted TLS between both. Free and all... say hey, they're good for most things, just not as the FQDN of a mail server (not if you want to receive all legit mail being sent to it).

 

[TPerry]

Totally agree with you. It "should" be trusted. But it isn't. Even by itself sending from LE FQDN to LE FQDN servers -- returns untrusted TLS between both. Free and all... say hey, they're good for most things, just not as the FQDN of a mail server (not if you want to receive all legit mail being sent to it).

Well, all I know is that the checkers DO recognize it as a VALID certificate (if the MTA is configured correctly). In the first image, the "TO" fail is due to the sender being hitting the grey list in PostFix.

 

[Anthony Parsons]

Yer, I've not had any issue with the cert verification, just the CA aspect, specifically mail hosting only.

 

[TPerry]

Yer, I've not had any issue with the cert verification, just the CA aspect, specifically mail hosting only.

That server is doing mail. It's fully configured using PostFix, Dovecot, OpenDKIM, etc in addition to doing the HTTP services aspect.
Here's another test of the MTA verifying that it is a valid certificate issued from a trusted CA
(yes, the "errors" are because SSL v3 are enabled - forgot to tweak the main.cf)

I won't belabor the point other than it works fine for me and for a few others that I know that deliver mail utilizing it.

 

[Anthony Parsons]

Do you have an email address hosted on that I can send a message to, to see what my mail log says about it?

 

[TPerry]

Do you have an email address hosted on that I can send a message to, to see what my mail log says about it?

Yep... I'll PM it to you, but you should see similar to this (actually, this is the log in attempts which are rejected - but you should still see TLS if your system uses it to connect with)

Apr  5 01:08:13 whiskey dovecot: pop3-login: Aborted login (tried to use disallowed plaintext auth): user=<>, rip=71.176.118.18, lip=149.56.33.159, session=<eCC7N2VMxABHsHYS>
Apr  5 01:08:17 whiskey postfix/smtpd[23657]: lost connection after STARTTLS from ssl-tools.net[185.55.116.145]
Apr  5 01:08:17 whiskey postfix/smtpd[23657]: disconnect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:17 whiskey postfix/smtpd[23657]: connect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:18 whiskey postfix/smtpd[23657]: Anonymous TLS connection established from ssl-tools.net[185.55.116.145]: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (112/128 bits)
Apr  5 01:08:18 whiskey postfix/smtpd[23657]: lost connection after STARTTLS from ssl-tools.net[185.55.116.145]
Apr  5 01:08:18 whiskey postfix/smtpd[23657]: disconnect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:18 whiskey postfix/smtpd[23657]: connect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:19 whiskey postfix/smtpd[23657]: Anonymous TLS connection established from ssl-tools.net[185.55.116.145]: TLSv1 with cipher ECDHE-RSA-RC4-SHA (112/128 bits)
Apr  5 01:08:19 whiskey postfix/smtpd[23657]: lost connection after STARTTLS from ssl-tools.net[185.55.116.145]
Apr  5 01:08:19 whiskey postfix/smtpd[23657]: disconnect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:19 whiskey postfix/smtpd[23657]: connect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:19 whiskey postfix/smtpd[23657]: Anonymous TLS connection established from ssl-tools.net[185.55.116.145]: SSLv3 with cipher ECDHE-RSA-RC4-SHA (112/128 bits)
Apr  5 01:08:19 whiskey postfix/smtpd[23657]: lost connection after STARTTLS from ssl-tools.net[185.55.116.145]
Apr  5 01:08:19 whiskey postfix/smtpd[23657]: disconnect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:20 whiskey postfix/smtpd[23657]: connect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:20 whiskey postfix/smtpd[23657]: Anonymous TLS connection established from ssl-tools.net[185.55.116.145]: TLSv1.2 with cipher EXP-RC4-MD5 (40/128 bits)
Apr  5 01:08:20 whiskey postfix/smtpd[23657]: lost connection after STARTTLS from ssl-tools.net[185.55.116.145]
Apr  5 01:08:20 whiskey postfix/smtpd[23657]: disconnect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:20 whiskey postfix/smtpd[23657]: connect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:21 whiskey postfix/smtpd[23657]: Anonymous TLS connection established from ssl-tools.net[185.55.116.145]: TLSv1.2 with cipher RC4-SHA (112/128 bits)
Apr  5 01:08:21 whiskey postfix/smtpd[23657]: lost connection after STARTTLS from ssl-tools.net[185.55.116.145]
Apr  5 01:08:21 whiskey postfix/smtpd[23657]: disconnect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:21 whiskey postfix/smtpd[23657]: connect from ssl-tools.net[185.55.116.145]
Apr  5 01:08:21 whiskey postfix/smtpd[23657]: Anonymous TLS connection established from ssl-tools.net[185.55.116.145]: TLSv1.2 with cipher EDH-RSA-DES-CBC-SHA (56/56 bits)
Apr  5 01:08:22 whiskey postfix/smtpd[23657]: lost connection after STARTTLS from ssl-tools.net[185.55.116.145]

The only time I've seen issues if the server is using an older CA bundle.

 

[Rusty Snippets]

I nosed around the Longview app on my Linode console........................ holy crap! This cPanel install IS a bloated pig lol!! I had no idea it used so much of my resources!

 

[Anthony Parsons]

Yep. As does Apache compared to NGINX. I was a bit scared moving away from apache, at first, having used it for so long and the unknown and all... but OMG, how much simpler it is and FAST... just WOW. I wish I had shifted sooner.

 

[Rusty Snippets]

I think I'll spin up another node tonight and check out using the nginx. It looks very interesting!