Subject: [Uta] MTA-STS with lots of domains

From: "John R Levine" <[email-masked]>
Date: 8 Jan 2019 15:59:30 -0500

I have about 80 domains pointed at my mail server.  I control the DNS for 
all of them but I can't see any reasonable way to make MTA-STS work.

I can set up the TXT records easily enough, but it looks like I need an 
HTTPS server with 80 names and 80 certficates, or one certificate with 80 
alt names.  That doesn't scale very well.

Adding to the excitement, every domain has its own name for the mail 
server, e.g., for foo.com the mail server name is mx1.foo.com, all 
pointing at the same IP address.  (This is not unusual; Tucows hostedemail 
does the same thing with much longer names.)  So I'll need 80 names on the 
mail server certificates, too.

Am I missing anything here?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

PS: On the domains where I have access to the registrars, they're DNSSEC 
signed and there are _25._tcp.<mx> TLSA records.

---

From: "A. Schulze" <[email-masked]>
Date: Tue, 8 Jan 2019 22:19:29 +0100

Am 08.01.19 um 21:59 schrieb John R Levine:
> I have about 80 domains pointed at my mail server.  I control the DNS for all of them but I can't see any reasonable way to make MTA-STS work.
> 
> I can set up the TXT records easily enough, but it looks like I need an HTTPS server with 80 names and 80 certficates, or one certificate with 80 alt names.  That doesn't scale very well.
> 
> Adding to the excitement, every domain has its own name for the mail server, e.g., for foo.com the mail server name is mx1.foo.com, all pointing at the same IP address.  (This is not unusual; Tucows hostedemail does the same thing with much longer names.)  So I'll need 80 names on the mail server certificates, too.
> 

my (not yet deployed at scale) setup looks like this. Hope, this is not entirely broken :-)

 - assumption: many customer domains have a shared MX

 - use https://github.com/danmarg/sts-mate as Webserver

 - setup 3 instances announcing my MX set, one instance per policy "none/testing/enforce"
 - name them mta-sts-policy-none.example.net, mta-sts-policy-testing.example.net and mta-sts-policy-enforce.example.net
 - setup 3 instances _mta-sts-policy-none|testing|enforce.example.net
   they propagate a policy date

to enable a MTA-STS on a customer domain, you only add 2 CNAMEs 
 - mta-sts.customer.example CNAME mta-sts-policy-enforce.example.net
 - _mta-sts.customer.example CNAME _mta-sts-policy-enforce.example.org

Daniels sts-mate fetch LE certificates on demand.

Andreas

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 8 Jan 2019 16:35:33 -0500

> Am I missing anything here?

That's OK, you have working DANE, you mostly don't need MTA-STS.
MTA-STS is is aimed at receiving domains that face obstacles signing
their *own* domain.  There's little excuse for not being able to
do DNSSEC validation, if a sending system is at all serious about
outbound SMTP security, it'll do both MTA-STS and DANE.

-- 
	Viktor.

---

From: "A. Schulze" <[email-masked]>
Date: Tue, 8 Jan 2019 22:57:53 +0100

Am 08.01.19 um 21:59 schrieb John R Levine:
> Adding to the excitement, every domain has its own name for the mail server, e.g., for foo.com the mail server name is mx1.foo.com, all pointing at the same IP address. 

Oh, just re-read that.

this makes it really hard. So you could only automate the setup of 80 webservers + certificate management.
But you already have 80 certificated for the MX server in place, so adding 80 WebServer is work, but not impossible.

(This is not unusual; Tucows hostedemail does the same thing with much longer names.)  So I'll need 80 names on the mail server certificates, too.

well, years ago, we decided to setup all our hosted domains using _one_ set of MX server names.
Benefit today: mta-sts deployment is easier :-)

Andreas

---

From: Jim Fenton <[email-masked]>
Date: Tue, 8 Jan 2019 14:01:37 -0800

On 1/8/19 12:59 PM, John R Levine wrote:
> pointing at the same IP address.  (This is not unusual; Tucows
> hostedemail does the same thing with much longer names.)  So I'll need
> 80 names on the mail server certificates, too.

You said that you control the DNS for the 80 domains. Is there any
reason you can't use a common MX name for them?

---

From: Grant Taylor <[email-masked]>
Date: Tue, 8 Jan 2019 15:02:21 -0700

> That's OK, you have working DANE, you mostly don't need MTA-STS. 

Wait a minute.

Maybe it's the "mostly" qualifier there, but I thought first S was one 
of the critical parts of MTA-STS (or HSTS for that matter).

Where by the "Strict" meas that "Transport Security" *MUST* be used.  As 
in *NEVER* send email *WITHOUT* transport security.  Further, treat any 
situation where you could send email without transport security as an error.

> their *own* domain.

I view the signal that transport security *MUST* /strictly/ be used as 
distinctly different than things like DANE.  (Perhaps I'm misremembering 
DANE.)

I'm not aware of anything else that provides the signal that MTA-STS 
provides.

> There's little excuse for not being able to do DNSSEC validation,

Agreed.

I also think there is little reason for not signing your own zones.

> if a sending system is at all serious about outbound SMTP security, 
> it'll do both MTA-STS and DANE.

Agreed.

-- 
Grant. . . .
unix || die

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 8 Jan 2019 17:18:14 -0500

> On Jan 8, 2019, at 5:02 PM, Grant Taylor <gtaylor=[email-masked]> wrote:
> 
> Maybe it's the "mostly" qualifier there, but I thought first S was one of the critical parts of MTA-STS (or HSTS for that matter).
> 
> Where by the "Strict" meas that "Transport Security" *MUST* be used.  As in *NEVER* send email *WITHOUT* transport security. Further, treat any situation where you could send email without transport security as an error.

DANE for SMTP as defined in RFC7672 as strictly stronger than MTA-STS.
For clients that implement the DANE spec, TLS and authentication are
mandatory with receiving MX hosts that publish TLSA records, and unlike
MTA-STS the signalling is downgrade-resistant even on first contact.

>> MTA-STS is is aimed at receiving domains that face obstacles signing their *own* domain.
> 
> I view the signal that transport security *MUST* /strictly/ be used as distinctly different than things like DANE.  (Perhaps I'm misremembering DANE.)

You're misremembering or never looked closely at DANE for SMTP.

-- 
	Viktor.

---

From: Grant Taylor <[email-masked]>
Date: Tue, 8 Jan 2019 15:23:01 -0700

> You're misremembering or never looked closely at DANE for SMTP.

Thank you for the clarification.

I'll go back and re-read DANE /for/ SMTP.

-- 
Grant. . . .
unix || die

---

From: "A. Schulze" <[email-masked]>
Date: Tue, 8 Jan 2019 23:24:00 +0100

Am 08.01.19 um 23:02 schrieb Grant Taylor:
> I'm not aware of anything else that provides the signal that MTA-STS provides.

Oh, it's DANE, as I understand it. 
A DANE aware sender will not transmit a message if validation for a DANE aware recipient domain fail.

And there are already some (unintended) proofs that DANE work.
Mostly because the recipient did not properly handled a MX certificate rollover.

Andreas

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 8 Jan 2019 17:37:20 -0500

> On Jan 8, 2019, at 5:24 PM, A. Schulze <[email-masked]> wrote:
> 

https://github.com/danefail/list :-(

-- 
	Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 9 Jan 2019 02:11:41 +0000

>https://github.com/danefail/list :-(

Woah, that's taking a DNSSEC mechanism back to the state of HOSTS.TXT from the
1980s.  Once dane_fail_list.dat gets too big to be hand-edited, will someone
create a global distributed database that can be queried for entries?  You
could call it the DANE Nonfunctionality Selector, or DNS.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 8 Jan 2019 21:36:05 -0500

> On Jan 8, 2019, at 9:11 PM, Peter Gutmann <[email-masked]> wrote:
> 

The reason this exists is that today only a minority of senders check DANE TLSA
records (none of the really big ones like Google, Microsoft, Yahoo, ...), and
so some of the vanity domain hobbyists who turn on DANE may not realize they've
messed up.

This is a stop-gap measure until botching cert rollover has a sufficiently
dramatic impact to make the list redundant.  Anyone who still wants to receive
email will need to implement a robust rollover process and monitoring, or
outsource hosting of their DANE domain to professionals.

Another reason for the list, is that tools like "certbot" do cert rollover
blissfully unaware that they may breaking the mail server's TLSA records,
and indeed a large fraction of the listed domains are Let's Encrypt users.
This is slated to change.  I'm in conversation with the maintainers of
certbot, and should become DANE SMTP aware in the not too distant future.
If there are other popular ACME clients that need to be improved, please
ask the maintainers to get in touch with me.

The list will not be maintained at scale.  There are 777k DANE domains,
of which ~300 are broken.  A problem rate < 0.05% is not at all bad.

Best practices around cert rollover are not yet well understood by users
who find some random HOWTO on the internet and implement that.  I would
hope that over time, better HOWTO guides will be nearer the top of Web
search results.

-- 
	Viktor.

P.S.  If any of the large providers reading this are not yet getting ready
      to pilot DANE outbound, please do make plans.  What would be especially
      helpful is well publicized policies to enforce and not whitelist except
      in large-scale emergencies where a similarly large peer screws up, and
      queueing a billion messages would not be viable.  This is not different
      from essentially similar risks with MTA-STS.

      Otherwise, giving users the ability to opt-out per-message (along the
      lines of REQUIRETLS=NO) should be sufficient, if coupled with reasonably
      timely delay notices.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 9 Jan 2019 12:15:47 +0100

Yeah, same question as Jim's. If you switched to a common MX, deployment
would be very easy.

To restate your question slightly--because I believe the HTTPS part is in
fact easy (as Andreas noted, it's fairly trivial to automatically serve the
"right" server cert for the desired identity, though I don't claim my
sts-mate is production ready ;) )--your problem is

*Given a large number of domains that share the same physical MTA, but
where each domain has its own in-zone MX record, how do I have the MTA
serve the right certificate, as required by MTA-STS?*

I think this is hard. You probably could get a single cert with SANs for
all of your 80 domains, or one for each new domain, but you will have to
figure out how to automate this (and I guess use SNI to pick the right cert
on the server side--note that the RFC does require SMTP clients to support
SNI, so as to enable this).

As an interesting anecdote, in draft versions of the RFC we specified that
the "mx" patterns in the policy had to match a SAN on the cert, but that
the cert did not in fact have to match the hostname itself, which would
have supported your use case. But we removed it for simplicity.

Since you can achieve the same indirection by sharing an MX host (i.e., a
fixed host, like "mx.provider.com") across all your users, I would
recommend that approach. Is there a specific reason to avoid that, or is
this just the current setup that you have?

On Tue, Jan 8, 2019 at 11:01 PM Jim Fenton <[email-masked]> wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

-- 
How's my emailing? http://go/dan-email-slo

---

From: Alice Wonder <[email-masked]>
Date: Wed, 9 Jan 2019 03:25:16 -0800

On 1/9/19 3:15 AM, Daniel Margolis wrote:
*snip*
> /
> figure out how to automate this (and I guess use SNI to pick the right 
> cert on the server side--note that the RFC does require SMTP clients to 
> support SNI, so as to enable this).
*snip*

Note that you can use certbot to submit a CSR with multiple alternative 
names and if desired re-uses the private key to reduce DANE rollover 
issues. That's what I do with Let's Encrypt, only change the private key 
once a year so DANE is easier.

I've never tried it with 80 domains in single cert, I do not know if 
they have a limit, but I have tried it with four or five and it works. 
They do a challenge for each alternative name but that should succeed if 
they resolve to same IP address.

---

From: "John Levine" <[email-masked]>
Date: 9 Jan 2019 08:09:31 -0500

>reason you can't use a common MX name for them?

I don't want to.  The current setup works fine, and the separate MX names make
it somewhat easier to track down some kinds of problems.

---

From: "John Levine" <[email-masked]>
Date: 9 Jan 2019 08:11:42 -0500

>once a year so DANE is easier.

Yes, I know.  The chances of verifying 80 names in a row without one
of them glitching does not seem high.  I'd probably get rate limited
first.  The usual LE rollover for a single cert starts quite a long
time before the old cert expires so if it fails, you can try again
tomorrow.

R's,
John

PS: I lied, it's actually more than 80.
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 9 Jan 2019 09:22:27 -0500

>SNI, so as to enable this).

I use the standard gnutls library which supports SNI, so I suppose I
could put 80 certs into a folder and pick out the right one.  I wonder
how many SMTP clients send the name they expect -- until STS came
along there was no expectation that the name the client used matches
the cert.  I can certainly write a stunt https server that invents a
suitable policy document on the fly,

The larger issue is that this is the same unfortunate road that SPF
and DMARC went down.  Oh, our magic bullet can't handle your totally
standard but slightly unsusual setup, so we will retroactively redefine
it as broken.

---

From: Alice Wonder <[email-masked]>
Date: Wed, 9 Jan 2019 06:27:05 -0800

> standard but slightly unsusual setup, so we will retroactively redefine

If MTA-STS isn't suited for you then just use DANE. It's better (IMHO) 
anyway.

Seems many MTA clients do not query OCSP servers so DANE is going to be 
more secure in the event of a private key compromise.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 Jan 2019 14:32:16 +0000

Yeah, we're not allowed to do that.

It's one of the thing that make our job hard.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 9 Jan 2019 16:35:24 +0100

Well, like I said, STS requires clients to provide SNI, so they should not
consider it an STS violation if they don't send SNI and consequently get
the wrong cert.

I am not claiming your setup is broken--just that among possible fixes (a
cert with many SANs, using SNI to serve one cert of many, renaming the MX),
renaming the MX may be the easiest. Whether that's worth it is your call,
not mine. :)

Dan

On Wed, Jan 9, 2019 at 3:22 PM John Levine <[email-masked]> wrote:

> In article <CANtKdUee4d=bexpAUj-9+qGLO1ght=
> [email-masked]> you write:
> cert

---

From: Hanno Böck <[email-masked]>
Date: Wed, 9 Jan 2019 16:47:09 +0100

On 8 Jan 2019 15:59:30 -0500
"John R Levine" <[email-masked]> wrote:

> I can set up the TXT records easily enough, but it looks like I need
> an HTTPS server with 80 names and 80 certficates, or one certificate
> with 80 alt names.  That doesn't scale very well.

I believe the thing you want is automation.

There's no technical scalability issue here, a certificate is just a
bunch of bytes you get for free. The only issue is that configuring 80
hosts and certs manually is a lot of work. Take the "manually" out and
you don't have a problem.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: "John Levine" <[email-masked]>
Date: 9 Jan 2019 11:34:26 -0500

>I believe the thing you want is automation.

I already have automation to renew all my certs.  But I can tell you
that DNS based renewals are slightly flaky because of server update
delays and caches.

>There's no technical scalability issue here, ...

If you have to validate 80 names, and each validation works 98% of the
time, validating all 80 alt names in a row only works 19% of the time.
That's the scalability issue.

If I can set up SNI so the certs are independent, that scales a lot
better, since a renewal failure in one doesn't affect the other 79.

R's,
John

---

From: [email-masked]
Date: Wed, 09 Jan 2019 08:38:52 -0800 (PST)

> you don't have a problem.

Agreed, but to be fair, there is a 500 domain per IP limit with Let's Encrypt.
But 500 is a lot more than 80, and if you're servicing over 500 domains that
sounds like a fairly commercial enterprise to me, with all that implies.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 9 Jan 2019 12:14:17 -0500

>sounds like a fairly commercial enterprise to me, with all that implies.

Hmmn.  I do LE validation with DNS records.  How do they even know what IPs
the certs will be served on?

---

From: Grant Taylor <[email-masked]>
Date: Wed, 9 Jan 2019 13:28:29 -0700

On 01/09/2019 06:11 AM, John Levine wrote:
> Yes, I know.  The chances of verifying 80 names in a row without one of 
> them glitching does not seem high.  I'd probably get rate limited first. 
> The usual LE rollover for a single cert starts quite a long time before 
> the old cert expires so if it fails, you can try again tomorrow.

I thought the rate limit was the number of certs /issued/ a week.  So I 
would expect that validation failure before issuance wouldn't count 
against the rate limit.

-- 
Grant. . . .
unix || die

---

From: Grant Taylor <[email-masked]>
Date: Wed, 9 Jan 2019 13:33:48 -0700

On 01/09/2019 07:22 AM, John Levine wrote:
> until STS came along there was no expectation that the name the client 
> used matches the cert.

I've been seeing MUAs complain about the CN or SAN(s) not matching the 
FQDN for years.  Completely independent of MTA-STS.

-- 
Grant. . . .
unix || die

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 9 Jan 2019 23:07:25 +0200

On Wed, Jan 09, 2019 at 01:28:29PM -0700, Grant Taylor wrote:
> would expect that validation failure before issuance wouldn't count against
> the rate limit.

AFAIK, the relevant Let's Encrypt limits are:

- Maximum of 50 certificates per eTLD+1 per 7 days (each certificate
  counts once per eTLD+1 in it, regardless of if there are 1 or 100 such
  names).
- Maximum of 100 names per certificate.
- Maximum of 5 failed validations per name per hour.
- Maximum of 300 orders in 3 hours (IIRC, any order counts, not just the
  new ones). Each order gives maximum of 1 certificate.

The way transient glitches should be handled is that next validation only
revalidates the ones that failed last time, giving pretty high chance of
success if the faults were indeed tranisent (and since this happens in
>1h, the previous failed validations expire). It is the non-transient
failures that are more annoying.

However, the many ACME clients are just too primitive to get the
previous right. And very few can get the last one right if one uses
pre-canned CSRs.

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 Jan 2019 22:37:18 +0000

>    AFAIK, the relevant Let's Encrypt limits are:
  
That might be right, it might not.  Making deployment policies based on soft guidelines is probably not going to scale well.

Yes, if we made everyone use TLS for all inter-node transport, things would be better.  But we can't.  Next!

---

From: "John Levine" <[email-masked]>
Date: 9 Jan 2019 22:04:20 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-

Since MUAs don't talk to MXes, I have no idea what this is supposed to mean.

R's,
John

---

From: [email-masked]
Date: Thu, 10 Jan 2019 08:20:03 -0800 (PST)

> That might be right, it might not.

It's the value they document. Here's a link:

   https://letsencrypt.org/docs/rate-limits/

I also note that I missed the point that this limit only applies on creation,
not renewal. So it doesn't look like it it's even relevant.

> Making deployment policies based on soft guidelines is probably not going to
> scale well.

Let me guess - you haven't operated a high end messaging system recently that
sends lot of mail, have you? Because if you had, you'd know that setting
deployment policies based not just on completely squishy guidelines, but based
on constantly changing operational data is an absolute requirement.

Compared to other stuff the rules for using Let's Encrypt might as well be
chiseled in stone.

> be better.  But we can't.  Next!

Of course we can't. But I fail to see what that has to do with the scalability
of MTA STS.

				Ned

---

From: Grant Taylor <[email-masked]>
Date: Thu, 10 Jan 2019 10:31:05 -0700

> Since MUAs don't talk to MXes, I have no idea what this is supposed to mean.

MUAs talk to MSA's, which in my experience are usually also an MTA. 
Even if inbound and outbound MTAs are separated, they are usually 
administered in the same manner.  So if you need to do something on an 
MSA, chances are good that the same thing will be done on an inbound MTA 
that is an MX.

-- 
Grant. . . .
unix || die

---

From: "A. Schulze" <[email-masked]>
Date: Thu, 10 Jan 2019 18:37:05 +0100

> That's the scalability issue.

I run a webserver for > 1000 domains. Fully automated, with one guiding principle: "one FQDN -> one certificate"
Even $domain and www.$domain are two independent certs. No issue since ~ a year

Andreas

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Jan 2019 17:41:30 +0000

I never said MTA STS did not scale.  IF somehow I gave that impression, I apologize.

---

From: [email-masked]
Date: Thu, 10 Jan 2019 09:34:50 -0800 (PST)

> administered in the same manner.

Not in my experience, they aren't. In fact it's pretty much the opposite -
changes that are needed on both often only get made on one of them.

If they are separate it's for a reason, and implementing that typically
requires different configurations.

> So if you need to do something on an

Only if they happen to be the same system and the person running them is
careless, incompetent, or both.

				Ned

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Jan 2019 12:48:34 -0500

> I never said MTA STS did not scale.  IF somehow I gave that impression, I apologize.

I did not hold firm on the MX pattern as SAN constraint rather than
MX name constraint, yielding to EKR's objection.  So as a result,
deployment is more complex in some cases...

-- 
	Viktor.

---

From: [email-masked]
Date: Thu, 10 Jan 2019 09:48:55 -0800 (PST)

> would expect that validation failure before issuance wouldn't count

Yes, and I missed the /issued/ part in my original response; sorry.

There's also a limit on validation failures that probably applies. But
it's per-host and should not be a problem.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 10 Jan 2019 14:09:02 -0500

It is a poor idea to assume that everyone else's setup is like yours.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 10 Jan 2019 19:10:24 -0000

In article <[email-masked]>,
>Even $domain and www.$domain are two independent certs. No issue since ~ a year

I do more or less the same thing except that it uses the same cert for www.x.y and x.y.

So you can see why I would not be happy to maintain one cert with 80 names on my mail server.
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Grant Taylor <[email-masked]>
Date: Thu, 10 Jan 2019 13:40:39 -0700

Agreed.

Similar with experience.

That's why I try to always articulate when I'm saying things based on my 
experience / configuration and give ample amounts of room for people to 
have experienced / done otherwise.

Though when they have experienced / done otherwise, I do like to try to 
vicariously learn from them.

-- 
Grant. . . .
unix || die

---

From: [email-masked]
Date: Fri, 11 Jan 2019 08:54:44 -0800 (PST)

> the certs will be served on?

DNS validation still starts with a request from an ACME client. That's the IP
that matters. And as I have subsequently noted, I misread the text; the limit
only applies when creating an account for the first time, so it's actually
irrelevant.

>From what I can tell there is no limit that would prevent you from maintaining
as many domains as you want, even in the presence of a 2% valiation failure
rate - a rate which, if I had it, I would consider unacceptable and would
consider fixing it a top priority. And I'm speaking as someone who also uses
DNS validation for a bunch of domains on a Frontier DSL connection that doesn't
exactly deliver world-class performance or reliability.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 11 Jan 2019 12:51:30 -0500

> exactly deliver world-class performance or reliability.

In my case the problem is that I swap DNS secondary service with the ISP 
down the road, and his name servers don't always pick up changes when I 
poke it.  If I could give LE a hint about which NS to look at, the 
flakiness would go away.

Today's project is to see how hard it is to add SNI to my STARTTLS plugin 
so I can use separate certs. Assuming the gnutls documentation is correct, 
it doesn't look too bad.

Regards,

---

From: Grant Taylor <[email-masked]>
Date: Fri, 11 Jan 2019 10:57:41 -0700

On 01/11/2019 10:51 AM, John R Levine wrote:
> poke it.

Nice trade.

> If I could give LE a hint about which NS to look at, the flakiness would 
> go away.

How often do you need to update DNS records for Let's Encrypt?

I'm fairly certain that I've not needed to change my verification data 
in quite a while.

> Today's project is to see how hard it is to add SNI to my STARTTLS 
> plugin so I can use separate certs. Assuming the gnutls documentation is 
> correct, it doesn't look too bad.

Good luck.

-- 
Grant. . . .
unix || die

---

From: "John Levine" <[email-masked]>
Date: 11 Jan 2019 14:28:59 -0500

>How often do you need to update DNS records for Let's Encrypt?

I use acme.sh which inserts them every time it renews the cert.  I
haven't looked to see whether the record changes.  Everything's
automated and the renewals start a while before the cert expires so if
it flakes today, it'll work tomorrow which has been good enough.

R's,
John

---

From: Grant Taylor <[email-masked]>
Date: Fri, 11 Jan 2019 12:45:03 -0700

On 01/11/2019 12:28 PM, John Levine wrote:
> I use acme.sh which inserts them every time it renews the cert.  I haven't 
> looked to see whether the record changes.  Everything's automated and 
> the renewals start a while before the cert expires so if it flakes today, 
> it'll work tomorrow which has been good enough.

I also use acme.sh.  I'll do some playing with it as time permits in the 
next few days and see what I'm doing differently.  Maybe it's that I 
don't let it have access to DNS and have to make the changes manually. 
¯\_(ツ)_/¯

-- 
Grant. . . .
unix || die