In article
you write:
>-=-=-=-=-=-
>
>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
>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!
On Wed, Jan 09, 2019 at 01:28:29PM -0700, Grant Taylor wrote:
> 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
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
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
In article <01r1svv1718u000...@mauve.mrochek.com> you write:
>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.
> On 8 Jan 2019 15:59:30 -0500
> "John R Levine" 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
In article <20190109164709.6f869d92@computer> you write:
>On 8 Jan 2019 15:59:30 -0500
>"John R Levine" 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
Hi,
Sorry for the delay in reviewing this. I reviewed it in 2018, but needed
to work on expanding/decoding my notes so that they become useful for
other readers.
The document needs to specify line length increase and whether the
extension is allowed for SMTP Submission and LMTP (I think
On 8 Jan 2019 15:59:30 -0500
"John R Levine" 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.
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,
>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.
Yeah, we're not allowed to do that.
It's one of the
On 1/9/19 6:22 AM, John Levine wrote:
In article
you write:
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
In article
you write:
>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
In article <9361f00f-3962-7611-c55d-e01208488...@domblogger.net> you write:
>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
In article you write:
>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?
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.
A new meeting session request has just been submitted by Valery Smyslov, a
Chair of the uta working group.
-
Working Group Name: Using TLS in Applications
Area Name: Applications and Real-Time Area
Session Requester: Valery Smyslov
On 1/9/19 3:15 AM, Daniel Margolis wrote:
*snip*
/
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
18 matches
Mail list logo
