It's worth also mentioning MTA-STS [1], currently a draft. It provides a mechanism for domains to declare a STARTTLS requirement via a file at https://<domain>/.well-known/mta-sts.txt. It's backwards compatible and opt-in. There seems to be some testing already going on [2].
I am curious as for why they would use https for that. It sounds like something that should be better stored in DNS. Unencrypted but your MX entries are not more encrypted.
Agree and I am not saying it’s good. Just saying that you pulled the MX domain you are connecting to from an unsecure DNS entry so if DNS is mitm-ed, the attacker might as well make you submit the email to its own server then deliver it to the recipient.
[edit] actually looking at the RFC it relies on a TXT record before the https policy is even fetched.
You're requesting https://<domain>/.well-known/mta-sts.txt. If you've got that info, then A dns record was correct and you must use STARTTLS on MX record. Even if attacker replaced MX record, he can't MITM TLS session, so connection is safe. I think that it's pretty secure setup. But yes, so much hoops instead of deploying dnssec everywhere, it's a shame. DNS is hierarchical and it's very natural to use cryptography there.
Port 465 is for mail submission. It's there for authenticated communication between clients and servers. It has never been used for communication from server to server and was never intended to be. Port 587 has the same purpose (mail submission), but has a plain text protocol specific negotiation at the beginning which matches that for server to server mail transfer on port 25.
True, but the underlying question is still interesting: why isn't there a similar TLS-only port for MTA-MTA and we all agree to try to connect there first
Port 465 is unnecessary once STARTTLS was invented. It has exactly the same upside / downside but it wastes an entire TCP port and an entire RTT plus maybe a timeout to signal (non-)availability.
So it makes sense to deprecate this use of port 465 and just tell people to use STARTTLS.
The STARTTLS vulnerability to downgrade attacks is a significant downside that port 465 doesn't have (if using modern TLS protocols at least). My opinion is that perhaps the severity of the STARTTLS downgrade attack wasn't that much considered when port 465 was deprecated.
Downgrade attacks are no easier for STARTTLS than for TLS-on-connect. If you were deploying TLS-on-connect you'd have to do it in one of two ways:
1. Senders should first try TLS-on-connect, and if it's not available, fall back to STARTTLS.
2. Senders should only do TLS-on-connect with no fallback
If you do #1, then a downgrade attack still exists because an attacker can just block port 465 and then interfere with the traffic on port 25 (or put a fake SMTP server on that port if one doesn't exist).
If you do #2, that's no easier than just mandating that STARTTLS on port 25 is required.
The alternative to all of this is to find some out of band method for a receiver to state that TLS should be available (TLSA / MTA-STS), and if it's not then something is being tampered with. That way, a sender can look up that information and then choose to do #2 for that particular receiver. Again, in that scenario it makes no difference if we're talking TLS-on-connect or STARTTLS. Given we can't make the whole World switch to "must always be encrypted" at the same time, this is the only practical way forward.
I wrote "It has exactly the same upside / downside" and yet almost immediately I get a reply in which the author with no self-reflection has imagined there are additional downsides to STARTTLS.
As others have explained an on-path adversary who'd be able to rewrite packets in order to stop STARTTLS can even more trivially block port 465 altogether. In fact cheap appliances can do the latter but can't do the former, so if anything STARTTLS very slightly improves this.
If you are imagining "Well I could have a policy of only using port 465" well, sure, but you could just as easily have a policy of requiring STARTTLS. In both cases an adversary can deny you, and your only options are to re-think your policy or give up and not deliver email.
The only (weak) argument I can find is that since servers that had a port 465 open also had to keep a port 25 open for compatibility, you could perform the same downgrade attack by blocking connections to port 465, which would result in a submission to the port 25. But that's a "if it's broken let's make sure it remains broken" kind of argument.
Yes - it's a weak argument, and one that's probably been debunked by looking the way https lifted off recently. My view is if port 465 was still around today, it would probably get the same level of attention as port 443 has. We could have been at a stage where port 25 could be made intentionally unavailable (same way we move browsers from http to https) and everything forced to 465. Email agent developers would be forced to update their practices as well, no email should be sent over plaintext. At present, there is no good way to tell your clients you're not accepting plaintext. STARTTS is from a world where 99% of emails were plaintext.
You've confused the submission port (which is usually TLS encrypted on 587) with SMTP relay (done via port 25 with optional STARTTLS)
It's OK, lots of people don't know about this. Really the only problem is that you've assumed since you know nothing about this you're an expert, that'd be Dunning-Kruger or a related effect at work.
For submission it really can work to upgrade end user mail agent software. We're a long way from useful encryption capable agents being ubiquitous, but we've made progress and most popular systems today ship with such a client. These systems also use TLS directly for IMAP (to receive email) and can share a lot of logic across the two systems, so that's nice. In maybe a decade we'll be where HTTPS is today. For submission.
What distinguishes a submission port is that it's authenticated. You can only send email via the submission server as Alice if you prove to the submission server that you're Alice.
But SMTPS (obsolete SMTP over TLS on port 465) and the STARTTLS SMTP (on port 25) are for email relay. Authentication makes no sense in this scenario because the relays are neither sender nor recipient, the transmitting relay can't prove that it's Alice, and the receiving relay can't prove that it is Bob, because they're not, they are merely relays.
These are servers, so they upgrade much more slowly (often only on hardware replacement) and the priority is reliability of delivery, not security, if your proposed solution drops 1% of email on the floor that's far too much and nobody would adopt it.
Hence the situation we have today, and hence STARTTLS Everywhere. Your imagined alternate universe makes no sense except because you've misunderstood how email works.
Additionally, MTA-STS has recently been approved as Proposed Standard, so we may see increased support for it in the near future. [1]
The key advantage of MTA-STS is that it can be deployed quickly, without almost any disruption of the already-deployed infrastructure. Of course DNSSEC and DANE already solve the same problem, but MTA-STS is the designed by and for people who don't want to use DNSSEC.
The EFF's efforts are complementary to MTA-STS. As schoen mentioned elsewhere on this thread, in the early days it's probably useful to have a preload list. (That said, I am not sure why they feel it necessary to cast MTA-STS in negative light: "[...] so the sender will never know the recipient supports STARTTLS." [2] They should explain that there MTA-STS is trust on first use and has a memory effect, exactly like the well-accepted HTTP Strict Transport Security.)
We added support for MTA-STS testing to Hardenize just today, along with a blog post that explains the background and explains how to deploy it. [3] (Disclaimer: Hardenize founder.)
This is interesting, I have been wondering for a while if I could disable plaintext email delivery on port 25 and just leave encrypted submission on port 465.. Would I be losing mail ?
Yes, unfortunately you'd be losing email. Port 465 has been deprecated a while back (1997).
I guess that's the problem - there is no practical way to disable plaintext email from the start. You may always need to accept the connection, see if the client will STARTTLS, disconnect if they do not and hope they don't re-try and keep hammering your servers with the same message, the error message "hey, i'm not accepting plaintext" will most likely get ignored.
You need to have a correctly formatted DNS TXT record at _mta-sts.example.com first. They'll check for that, and only if it exists will they bother attempting to fetch your mta-sts policy from https://mta-sts.example.com/.well-known/mta-sts.txt
* The SMTP RFC says that mail servers MUST NOT require STARTTLS to receive mail. Postfix (and I imagine most other production grade SMTP servers) has an option to require STARTTLS anyway, so if you really want STARTTLS you can already require that clients have it enabled, despite the braindead standard.
* STARTTLS ensures that mail was encrypted only in the final hop, from the last server to your server. That usually means it transited the public internet encrypted, but it definitely does not assure it.
There are interesting email security efforts afoot, notably the draft standard called "SMTP Require TLS": https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-... . Unfortunately the reality is that the internet mail infrastructure evolves at an incredibly glacial pace. The entire SMTP protocol would benefit greatly from the adoption of an SMTP/2 protocol, rethought with modern security practices in mind.
How did these committees think that optional, downgradable encryption was preferable to a standalone, encrypted only port (465)? Were they trying to save server ports, like if it was a precious resource? Any design decision I have seen regarding email since 2000 defies common sense. Like I heard most SMTP implementations do not validate certificates. What good is an unvalidated certificate? SPF is treated as indicative only or ignored.
We are managing to replace http1.1 with http2, it will take time but it is on the way. I am not even aware that an actual SMTP2 draft protocol that would solve all these design flaws (unverified sender, unencrypted).
And SMTP has a benefit http didn’t have. Most people access their emails through webmails, smartphones or enterprise outlook/exchange servers. For webmails and exchange only the server needs to be updated, and for smartphones, their short life ensures that older versions are pretty much all retired within 5 years. In addition, a handful of big players (google yahoo apple msft) have such a concentration of recipient accounts (retail users) that they can force a change on the market with the threat of your mail being classified as junk by them. So we could achieve a pretty quick transition.
Apparently 465 is only for mail submission, not MTA-MTA -- but of course that still leaves the obvious questions of a) why? b) if it must be a different port, why not make that TLS-only?
SPF, of course, should be used everywhere so that we reach the point of complete balkanization and collapse, and people realize that we can (and in fact in some ways already have) switch wholesale to different systems, faster. (-:
Not that I think that SPF is the ultimate solution (it is merely a thin layer of lipstick on the pig) but I don't agree with many of the assertion of your "spf is harmful" link.
- pre-delivery forwarding servers just need to be added to spf. If you use random third party smtp relays, then this is precisely what spf is trying to avoid.
- the way internal servers implement aliases is their problem, there is not necessarily a need to go through an smtp relay (my mail server doesn't)
- failover mail servers should check spf on incoming email and then have a trusted relationship with the primary server so that spf isn't enforced when the failover delivers to the primary (that's the way my mail server works)
- spf uses DNS. So what?
- ISP lock-in. If you control the domain/DNS entries, there is no lock in. If you don't, then you are already locked in anyway.
- doesn't allow dynamic IPs. I'd argue that 1) it is a good thing 2) it's not really the case, you can specify a domain in spf, and this domain can be a dyndns style domain with a short lived TTL resolving to your current dynamic ip. And in theory you could also dynamically update your spf as your ip changes with a short TTL (like a dyndns-style entry).
[edit] and actually what is going to kill you with a dynamic IP is not so much spf than the fact that the reverse dns of that IP won't resolve to your domain which is a big spam red flag for most smtp servers.
> pre-delivery forwarding servers just need to be added to spf. If you use random third party smtp relays, then this is precisely what spf is trying to avoid.
The huge problem here is "forward all e-mail I receive to my gmail account" or similar. If you do that pre-delivery, you break SPF. If you do it post-delivery, gmail makes you responsible for any junk that gets through. If you make your filters harsher, the user complaints some e-mails are lost. What is your solution to this problem?
> the way internal servers implement aliases is their problem, there is not necessarily a need to go through an smtp relay (my mail server doesn't)
Now you send an e-mail to contact@yourbank.tld and the message is rejected because of your SPF policy and their usage of internal relays. You can (a) fight the corporate shitshow to get someone to fix the bank's relay; or (b) relax your SPF policy. You may be willing to pursue (a), but a company that sells e-mail services to thousands of clients just cannot enter those fights and still be economically viable.
Don't get me wrong. I use SPF (DMARC actually) on my personal server and it actually helps (as a low volume sender), but the moderate volume senders' problems are different from those of personal e-mail servers, and SPF works much worse there.
> gmail makes you responsible for any junk that gets through
I'd argue this is the fair and correct behavior. Effectively you created a kind of open relay server. Since you accept external traffic, you should be filtering for spam there.
> the message is rejected because of your SPF policy and their usage of internal relays
I'd assume that if it is an internal relay server, then it shouldn't be checking for spf internally. Only the server receiving incoming external traffic should check spf. Sounds like a misconfiguration.
> I'd argue this is the fair and correct behavior.
A behavior that breaks how the mail system has been working since forever, and that people expect and use all the time.
It may not be right, but it is used and not even the big players (such as gmail) are willing to break it (hence why gmail actually tells other admins to use pre-delivery forwards disregarding SPF, but respecting DKIM wich is broken if you use post-delivery aliases) [1].
A misconfiguration you cannot fix (because it is on the receiver end, not on your end). But the client pays you for the service, and understandably asks you for a solution. What would you tell them?
I understand your points, and mostly agree with them. However, this approach only works in an ideal world where users understand that e-mail should have some limitations it hasn't had for the last 30 years, and all administrators are "good citizens" (they know their stuff, acknowledge their issues and work to quickly fix them).
The real world is different: clients will demand solutions, and other admins will oftentimes be either ignorant, powerless or even adversarial.
I don't think it makes sense to classify an individually set-up, per-account redirect an "open relay server". It can't be used to do anything the user didn't intend.
Maybe it would help to allow users to whitelist such cases.
The email RFCs require supporting a lot of things that are now horrendously outdated, and forbid doing a lot of things that should now be best practices.
See, at surface value I agree. But at a deeper level I don't. The problem is too many broken protocols exist via RFC only (dns, smtp, etc). Rather than violate that, or force it into something it's not, we should be writing newer, better protocols. The friction against this is huge, mainly by those who capped out at the previous RFCs, though. Email(well, smtp) itself is so outdated and broken, I can't believe it's still so widely used.
Fair point, but I was thinking something like Signal, WhatsApp, or the like. So, I like to think of email as a bit dated, not only in security but in model.
That said, the beauty of email is that you have a unique identifier that doesn't force the other party into your walled garden.
If we could develop something akin to Signal, but that didn't require the second party to have to sign up explicitly for that service, I think that could finally start the process. Which, of course, would also require some level of initial adoption, probably the hard part.
smtp might be broken, but it would be extremely hard to replace it to something incompatible, as it's a very core of the nowadays internet.
Moreover it has the advantage no other popular communication service has: people somehow managed to agree on protocol standard so anyone is able to run own smtp server. In modern days of huge corporations a new popular standard like this seems impossible.
Except it’s not like let’s encrypt at all. This appears to test your mail server for starttls functionality, but it doesn’t issue certs or anything like that.
I think the title of the submission is mis-editorialized. The comparison that my colleagues working on this project make is that it's like HTTPS Everywhere, or even more like the HSTS preload list, rather than like Let's Encrypt. I don't think you'll find the comparison to Let's Encrypt on the site itself.
(Edit: in addition to the site tester that you noticed, there is also a public policy list and some forthcoming tools to enforce STARTTLS on the client MTA side when delivering e-mail, preventing downgrade and MITM attacks.)
However, you can also use Let's Encrypt to make this more useful by getting a publicly-trusted certificate for the TLS service on your mail server, and then listing your mail server with this list!
The introductions my colleagues posted about this today are at
I'm sorry, but the problem is more complicated than that.
SSL is not mandatory on either port 25 or 587, and SSL can not be made mandatory if you follow the RFCs (it can be made mandatory if you tweak your MTA, but you may lose some mail). Advertising for SSL over DNS means you trust the DNS records - which you shouldn't without DNSSEC. Even with it, there can be workarounds that in practice will allow MITMs.
The only real solution is making SSL mandatory, and doing SMTP over SSL as in the good old days of using stunnel on port 465 to decrypt, then netcat to forward the output to the MTA running on localhost:25
But that is not standard. Maybe the efforts would be better invested by changing the standards to have a port where SMTP can not happen at all without SSL - just like port 465 was, over 10 years ago.
> SSL is not mandatory on either port 25 or 587, and can not be made mandatory if you follow the RFCs.
I'm well-aware of the RFC difficulty, but I don't think that the current approach of STARTTLS Everywhere is really a problem because it's effectively opt-in on both ends. The enforcement is requested by the receiving side and then implemented by the sending side.
* The receiving MTA has to proactively choose to be listed.
* The sending MTA has to proactively choose to make use of the list.
So, with the current version of STARTTLS Everywhere, only sites that deliberately choose to enforce STARTTLS will do so, and they will only do it when communicating with sites that have specifically asked them to enforce it! This would only be an RFC violation if we thought that the RFC meant to categorically forbid sites from separately agreeing to a stricter security policy.
This approach might have its scalability limitations, but I won't try to speak for my colleagues about any future steps.
I agree with you, STARTTLS Everywhere is not "a problem". It is not a solution either - at best a minor improvement.
The problem is not the MTA who will chose to be listed, but those who won't be listed - the immense majority. "Scalability limitation" is certainly a more polite way to say that.
I'm sorry if my message was too blunt, but I am not sure it was worth downvoting my technical explanation just for this.
Ok, we've changed the title above to the hopefully least controversial part of the article's original title. (Submitted title was "STARTTLS Everywhere: HTTPS Everywhere, but for SMTP".)
Out of ~6.5 million SMTP servers [1] on the Internet roughly 2.7 million support STARTTLS [2]. However, 1 million of them also support SSLv3 and ~200,000 still allow SSLv2.
Since proper email transport encryption is finally getting some momentum with DANE and MTA-STS, I'm surprised that STARTTLS Everywhere doesn't mention them.
DANE is being recommended (mandated?) by the European Union, and is on the rise. MTA-STS is backed by Gmail, Microsoft and many others, which is likely to give it traction.
To sum up from that post, we think STARTTLS Everywhere is a stop-gap measure until DNSSEC is fully deployed, and STARTTLS Everywhere can act as a preload list for MTA-STS (to prevent DNS downgrade attacks).
From my understanding, this is pretty much the same thing as the HSTS preload list[1], except for SMTP servers instead of HTTPS servers. It has two main goals. First, encourage cert validations. If you don't validate a cert, it means nothing. Second, help prevent MITM downgrade attacks. If your server is on the list, it means it should always use a secure cert. If it isnt, then don't connect. Same thing as HSTS preload list.
You write that "If you don't validate a cert, it means nothing". I should clarify that in this situation you get opportunistic encryption. I think you understood that, but the way it's phrased isn't clear. The situation is that we get secrecy, but we don't actually know who we're talking to since we didn't validate the cert. This genuinely is better than nothing.
If we were talking to a bad guy then we're screwed. But if we are talking to our intended recipient, even if their cert is bogus, our connection is protected from bad guys on the path. The bad guys can't choose later to access that communication after all, their only opportunity is to guess we're doing opportunistic encryption and intercept the original connection to play MitM, and if they guessed wrong their hand is shown by doing that.
This situation is unpalatable even for nation state adversaries like the NSA, because they would prefer not to be seen to be meddling. Even for something like the FSB, which scarcely cares if it's seen to be meddling, it does force them to make a decision they'd rather leave until after the fact. MitM everybody (and be known to do it) or leave them alone and maybe regret that later.
> If we were talking to a bad guy then we're screwed. But if we are talking to our intended recipient, even if their cert is bogus, our connection is protected from bad guys on the path.
You acknowledge that you don't know who you are talking to. That alone proves my point. If the cert is bogus/unvalidated then its trivial for the bad guy to intercept and supply their own bogus cert instead. You are correct that its encrypted, but that means nothing when you do not know who you are talking to. It could even be a string of bad guys all capturing and injecting another bad cert. Encryption without validation means nothing.
> they would prefer not to be seen to be meddling
Time and time again ISPs have been caught injecting javascript/cookies/html inside unencrypted traffic. If ISPs are willing to do that, then why should nation states be afraid to? The point of 'bad guys' is that they can't be trusted to not do bad things.
Besides the point that bogus/unvalidated certs do nothing, it would be easier to just perform a downgrade attack if the client isn't doing any validations. Downgrade to unencrypted and easily see everything. That is why they are creating a list of services that should only allow valid encrypted connections.
Under 'about', the rationale for STARTTLS is listed, which includes, but isn't exclusive to the HSTS like list:
- Increase STARTTLS adoption
- Increase the number of mailservers that actually validate certificates
- Maintain a STARTTLS Policy List to help prevent downgrade attacks on email services.
States "Couldn't connect to grepular.com. We couldn't find any MX records for grepular.com! Did you make a typo or enter the wrong email domain? Make sure to enter the part of your email address after the @!"
Then proceeds to show results for the MX anyway. With a single error: "Does not use a secure TLS version Error: Could not establish connection with hostname %!s(MISSING)"
The main problem with this is that STARTTLS is not anywhere near good enough, but if it sees high adoption, nobody may bother with something better in the future because they'll all think "Mission Accomplished."
There is never something that is "good enough" to solve all problems. In addition, stronger approaches are often harder to adopt (which is why they often don't get adopted). This effort to encourage STARTTLS everywhere provides reasonable protection against bulk passive monitoring, at very low effort. I think encouraging the use of TLS for all email traffic is a good idea.
I find it odd that the tester gets mad if it can't connect to the naked domain, even when the naked domain has MX records.
Other than that this is really cool!
It made me sad though -- I checked all the domains that I used to run mail for at some point in my career, and not one of them passed all the tests. When I managed email, I always made sure that our servers met all the current standards.
My email server passed, but the test mentioned, it could be better by adding it to the EFF's STARTTLS policy list [1].
The only problem being that that list is currently practically empty.
So while I was considering adding that email server which I maintain, when I saw the items on the list it makes me reconsider.
The only email servers currently on the list are : google, yandex, yahoo, icloud, outlook, comcast, eff, qq and facebook.
So while it might be an opportunity to get your server on the list early, personally I worry more about what it will break as to what it will help.
In conclusion, it looks like a great initiative, but it will have to be in production for a while before I would recommend anybody to add their server to that list.
One of the nice features of the policy list is that you can put your server on it in testing mode. In testing mode, any failure in TLS negotiation is logged and reported, but the message is sent over the insecure communication. So it shouldn't cause any breakage.
The checker concludes that because my server doesn't allow TLSv1.0 and TLSv1.1 it “Does not use a secure TLS version”, when in fact it does allow/require TLSv1.2 (and the checker does connect via TLSv1.2 later on). Is that an intentional conclusion or a bummer?
I appreciate what they're trying to do, and it may improve the status quo, but we've learned that the push away from implicit SSL/TLS and towards STARTTLS was wrong. Using one insecure aspect (DNS) to note that you SHOULD be able to do TLS with my mail server isn't a great solution.
We need to revisit the STARTTLS vs implicit TLS debate in light of the obvious vulnerability and overhead of starting with plain TCP connections and then hopefully signalling towards security. HTTPS is obviously implicit TLS and it works great. We know STARTTLS has issues. Can we not keep going down the STARTTLS road for email, while going down the implicit TLS road for other things?
The problem is partly because we don't have an assigned port for MTA2MTA implicit TLS. Otoh DANE also already provides a way to have mandatory TLS for MTA2MTA traffic.
I'm surprised to see the opposition to self-signed certificates from the EFF. Pushing people towards centralized certificate authorities seems to be anti-freedom. Maybe there is a decentralized approach instead.
We spent a lot of time thinking about this before we started building Let's Encrypt. In the case of the Web we didn't think there was a way to make self-signed certificates workable for anything because older browsers will always error on them. In the case of mailservers, self-signed certificates work for enabling TLS, and that's great, but you're extremely vulnerable to MITM attacks. So this project offers a way to prevent the MITMs, if you want it.
If there aren't major technical obstacles we might be willing to take pull requests for STARTTLS Everywhere that allow mailservers to announce self-signing policies, but it hasn't been a priority thus far because LE certs are so easy to get and are slightly more authenticated.
The problem with STARTTLS is a mitm downgrade attack. Self-signed certs are exposed to the same kind of mitm attack.
Mail is very sensitive communication. It is reasonable for the EFF to worry the risk of evedropping. Some websites are still sending passwords by email!
But you can chose to disregard the RFCs and disallow servers that will not encrypt to send you any mail. No downgrade attack then. It requires some manual changes. It may cause you to not receive email from some servers.
You can also only accept mail on port 465, which in practice is used for SMTP over SSL. You will receive even less mails.
465 used to be deprecated since 1998 when STARTTLS was created, and it was only kept in use since older Microsoft applications (including Entourage v10.0 and its successor, Outlook for Mac 2011) did not support STARTTLS.
However in January this year, the proposed RFC 8314 reinstate the registration of port 465 for implicitly encrypted mail submission. I think it is a bit early to close down port 25, but a great idea to make sure 465 is correctly configured if it isn't already.
The starttls-everywhere IP connects, tries a bunch of commands which don't look at all like a regular mail connection. It cycles through a bunch of tls settings and never sends an email.
In short, it got itself blocked by anti-spam measures.
My server was dropping the connection after EHLO because they were connecting from a different IP address and specified -all in the SPF record. Maybe you are seeing a different issue.
He's entering "fastmail.com" into the form on the web site then the EFF's server is trying to connect to (at least one of) FastMail's MX hosts but is unable to establish a connection.
As OP said, what he is seeing has nothing to do with SPF.
(Side note: I'm a mail admin and I'm pretty strict, but even I don't drop anyone after HELO/EHLO. I'm not surprised you're having issues.)
Cool. This tool made me realize that my domain's DNS records were messed up. Everything worked most of the time, but sometimes people wouldn't receive my emails! It turns out I was missing the latest MX and SPF records from my provider (Kolabnow).
Hmm. X.509 subject names aren't meant to be case-sensitive, right? I just realised one of the domains I manage have MX records in all-caps, and the cert checker fails on that, even though Gmail's SMTP servers have valid certs.
X.509 subject names are human readable text and probably you shouldn't try to reason about them beyond the simplest exact bit-for-bit comparison.
Where the subject name is the name of a something on the Internet it should use the Internet's defined "Subject Alternative Name" (SAN) mechanism, rather than trying to squeeze into the X.500 system's hierarchical directory. For compatibility, and to save the X.509 subject being empty which confuses some software, you may write one of the DNS names or IP addresses into the X.509 Subject's Common Name (CN) field as human readable text, but you should always write all DNS names and IP addresses into SANs.
The dnsName SAN is defined like a DNS record, so it's case-insensitive and (if it's an IDN) Punycoded, it's also deliberately defined with a single encoding that is too narrow for anything much beyond an actual (Punycoded if appropriate) DNS name, to avoid people trying to write "extended ASCII" characters into this field by mistake.
I'm still using a self-signed certificate because I'm using DANE / DNSSEC. I don't know of any tool that can properly help me automate the rollover of a let's encrypt certificate.
There are multiple ways to set it up:
- Reuse the key, set up the TLSA record using the public key. Certbot really doesn't seem to support this in an automated way. It requires that you generate a CSR, but there doesn't seem to be a way to renew this automatically.
- Generate a new key for each certificate, which is what certbot. You would first need to add both the old and the new certificate to DNS, wait for the TTL of the old to expire, change to the new certificate, remove the old from DNS. There doesn't seem to be a tool to do this.
- Set up the TLSA record to say you trust the CA.
Perhaps I miss your point but if you use one of the supported DNS providers [1] can't you use certbot with DNS authorization and export the key and certificate to your mail server? Otherwise the acmev2 protocol isn't horrible to implement if you want to integrate it with a custom infrastructure.
You can put a hash of your public key in the TLSA record (TLSA 3 1 1). Unlike the full certificate hash (TLSA 3 0 1,) the public key hash shouldn't change when your LE certs rollover.
Note that if doing this you may need to explicitly tell Certbot (or whatever client you use) not to keep replacing your key pair when renewing certificates.
If you set things up to involve CSRs this problem goes away because the CSR binds to a key pair, just don't change the CSR unless your DNS names change. But if you use CSRs, Certbot forces you to take charge of ensuring the renewal schedule etcetera, since it has no way to be sure if the same CSR can be used next time.
Mail servers can do more here to help automate this. Also, maybe we can imagine that TLS-ALPN-01 (a forthcoming Let's Encrypt proof of control method) could work with SMTP STARTTLS. That would let a mail server take responsibility for getting its own certs (port 25 is on the short list of "Authorized ports" for the Ten Blessed Methods) by telling its own TLS implementation "Hey, when asked for ALPN, offer this extra ALPN feature and repeat everything I tell you" to prove it is really who it says it is.
I think the above could work, but it would need effort from Let's Encrypt and TLS-ALPN-01 itself isn't finished yet.
[1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-21
[2] https://mta-sts.gmail.com/.well-known/mta-sts.txt