surely public <ssl> loadbalancer with acme SAN
loadbalancer <internal ssl> process with its own internal cert thus 2 separate connections same as would be used if internal process was http without ssl (aka 3) or if as you imply internal ssl is unvalidated (process names are not known to callers thus CA trusted but individual identity unvalidated) then simply obtain SAN from LE (via loadbalancer) have each process(that can be externally reached) only use a copy of this SAN+private-key have all internal callers trust this SAN (via trusting its CA as well as the internal) as it will be equally unvalidated for internal callers but will match all public names for external (validating) callers (web browsers) At 21:15 17/08/2017 Thursday, Mike Danese wrote: >*Resending after joining the list.* Thanks for clarifying that for me. It's >the answer I expected. I have a very different use case which I believe has >gotten somewhat less attention than the public CA use case. I am studying >large orchestration systems (some internal and some external like Kubernetes) >that have very similar APIs to ACME. In these systems, the CAs are not >publicly trusted. All communication secured by these CAs is internal. These >APIs are used to provide credentials to processes running in the system. >Processes use these credentials to establish (essentially) mutual TLS >authentication with other processes. In these systems, there is a very loose >coupling between the process and the TCP loadbalancers that might front the >process. A process exposes a secured network endpoint and doesn't know or care >where connections are coming from. A process only knows it's own identifier. >This poses a problem when trying to talk to a process through a named >loadbalancer. Standar d TLS validation will fail if a client talks through a named loadbancer to a process that presents a certificate with a DN of the process's identifier and without a SAN of the loadbalancer identifier. Possible solutions I can think of are: 1. Have the CA add SANs to the process's CSR for the loadbalancer identifiers the process backs. This is out of ACME spec, but we aren't going to get a ticket :) 2. Have the process fetch which loadbalancer identifiers it will back before building and sending a CSR to ACME. This has some performance implications. We like processes to start rapidly. This has some architecture implications. The loose coupling is quite handy. 3. Terminate/re-establish TLS in the loadbalancers. This has some performance and security implications. 4. Relax TLS and have processes consult a central, trusted map of loadbalancer identifiers to process identifiers to validate server authentication. This solves the problem and has some other nice properties but is (fairly radically) out of TLS spec. One of these solutions is less bad than the others and we can figure out how to workaround if we decide ACME satisfies this use case. On Thu, Aug 17, 2017 at 11:26 AM, Salz, Rich <[email protected]> wrote: > Thereâs compliant and thereâs compliant. J The IETF has no protocol police, > and you will not get a ticket for issuing a cert âwrongly.â Will anyone > complain if you change the CSR to say âS.A.â or âPtyâ instead of âIncâ or > âLtdâ? Of course not. > > > > Will people be upset if you add other random SAN fields they didnât want or > ask for? Yes. This is the internet, someone is bound to be upset. J > > > > Itâs great to see commercial interest. If there are real roadblocks we can > issue errata, updates, new challenges, or whatever it takes. > > > > /r$ > > > > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
