I guess the 465 ("movement") is too big to fail...
Now even Gmail supports it:
4 Likes
WTF???
"Non-SSL Setings" for port 587 ?!?!?!
The entire point of 587 was to require TLS.
Leave it to GD!
4 Likes
Even on port 25, they serve the short chain:
openssl s_client -connect mail.griffin.software:25 -servername mail.griffin.software -starttls smtp | head
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = griffin.software
verify return:1
250 HELP
CONNECTED(00000005)
---
Certificate chain
0 s:CN = griffin.software
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
4 Likes
Some of their design decisions are truly mind-boggling.
3 Likes
This shouldn't be "discouraged" - it shouldn't be allowed!
2 Likes
Caught that, huh?
3 Likes
I've just always been installing the ca.cer that was given to me by the acme.sh client. I assumed this was coming from Let's Encrypt. And I figured Let's Encrypt knew what to properly install. I know the ca.cer bundle has changed over the years, but never caused any issues as long as you always installed it's full contents along side the certificate.
It wasn't until... October 2 according to my logs, that this issue started.
I had read about some root certificate expiring, I honestly didn't pay a whole lot of attention to it, because I figured again as long as I was installing the ca.cer that was being sent, I'd be fine.
With the DST Root CA X3 root certificate expiring around this time, that can't really be a coincidence. Although I'm having trouble getting the dates to really line up (if the root expired on September 30 why did it take until October 2 for issues to pop up? I installed certificates just fine using this same method on October 1).
The DST Root CA X3 intermediate certificate having the same name as the root certificate certainly doesn't help in trying to clear up any confusion.
I guess my reliance on just always using what acme.sh sends as ca.cer as the valid ca bundle is just wrong?
1 Like
The story here is actually a bit complicated. I believe it goes like this:
People wanted SMTP over TLS - obviously. So they choose port 465 for that. The port was also officially assigned for that, but only for a very short time. After that it was revoked, because STARTTLS was put into SMTP. STARTTLS means that you're starting plaintext first, and then upgrade to TLS. This was initially seen as the "best" way to handle things, making STARTTLS the new standard - usually running as an optional feature on port 25.
However, port 25 became a legacy burden, because STARTTLS could not be mandated (not all MTA's talked it, this is even the case today). However, for sending email (where you usually talk to MUA's with better protocol support) things looked better, so a "submission" protocol was created, where MUA's can send their mail to, separating this from the MTA traffic on port 25. This also enabled server operators to require more strict security settings for the MUA's, mandating STARTTLS on port 587 (note that port 587 is by a definition a plain SMTP port, like 25, which must be upgraded via STARTTLS if desired).
Port 465 never died though. People apparently liked the concept of directly speaking TLS, without upgrade. This was reinforced, especially as later many attacks on STARTTLS (for example the STRIPTLS attack) became known.
This is the reason why many mailservers today support both: The official STARTTLS standard on submission, and the unoffical 465 port.
8 Likes
I think you meant "ISRG Root X1" there.
If you were using the short/alternate chain, you wouldn't be having this trouble since it is identical to the long/default chain other than not including the ISRG Root X1 intermediate certificate. By stripping that intermediate certificate from the end of your ca.cer, you've just created the short/alternate chain. 
4 Likes
So that becomes...:
The "ISRG Root X1" intermediate certificate having the same name as the root certificate certainly doesn't help in trying to clear up any confusion.
Which I still find confused.
It has the same name because it is the same thing (as you have a name and you might be someone's spouse, parent, child, employee, employer - you don't change your name because of that [pay no attention to stage names for this point]).
So the fact that one can sit in a wheelbarrow, and thus call it a chair, doesn't stop it from being a wheelbarrow.
"ISRG Root X1" was cross-signed and thus it can be used as an intermediate.
But the name of it won't change.
And the obvious fact that "Root" is in the name means it is a "Root" (now being used as an intermediate).
3 Likes
The ISRG Root X1 signed by DST Root CA X3 DST Root CA X3 intermediate certificate.
See the DST Root CA X3 name is used too many times to know what one is talking about.
1 Like
Ah...
I've just heard of some people trying to serve the self-signed ISRG Root X1 root certificate as part of their bundles, which is really silly.
3 Likes
Yep! Clear as mud.
1 Like
Are port 993 for secure IMAP and port 995 for secure POP3 held in the same regard?
Shouldn't they technically be retired along with port 465 in favor of STLS for POP3 and IMAP?
It gets really confusing when dealing with some clients. "Are you using TLS on connect or are you using opportunistic TLS?" and they have no idea. They just click SSL or TLS in Outlook and nobody knows exactly what any of that means.
If you are using TLS on connect then you can't issue STARTTLS or STLS - because the connection is already secure. If your connecting on a TLS on connect port expecting to use STARTTLS or STLS you'll never get that far the servers's expecting a TLS handshake that it's not getting.
3 Likes
There are two "versions" of "ISRG Root X1".
- One says "I'm a root" and it should be in your trust store and never sent by any server (no roots are accepted that way by any client)
- Another says "I'm an intermediate" and it can be sent by your server (because it doesn't claim to be a Root (although it actually is one).
R3 doesn't say I was signed by this version of "ISRG Root X1" - it can't do that.
R3 just says: I was signed by "ISRG Root X1", go see it for proof.
Where clients find "ISRG Root X1" depends on many things.
The point is for those that don't know "ISRG Root X1" is a root (not in their trust store), they can be sent the version that says "I'm an intermediate and I was signed by "DST Root CA X3" go see it for proof".
4 Likes
Cpanel SSL issuance bugs https://forums.cpanel.net/threads/cpanel-33077-letsencrypt-transition-to-isrgs-root-important.673981/
3 Likes
@eva2000
There are currently 185 posts in that thread... 
"Where's the beef?"
3 Likes
Related to this is cpanel's understanding of the issue at https://forums.cpanel.net/threads/cpanel-33077-letsencrypt-transition-to-isrgs-root-important.673981/post-2880033
2 Likes
Post #185 say:
"...We'll be shipping a fix soon..."
3 Likes