I agree with Sönke that kerberos is a better choice here. SSL and JKS is
probably NOT the right choice of this short lived (48 hours) scenario.
Typically certs are valid in order of years.

On Tue, Mar 13, 2018 at 7:21 PM, Sönke Liebau <
soenke.lie...@opencore.com.invalid> wrote:

> Hi Alexander,
>
> I don't (yet) have any real suggestions for what you are trying to
> achieve, but I'd be interested to understand if you looked at the
> alternative forms of authentication instead of SSL. Namely Kerberos
> which is already available and delegation tokens which will be
> available in 1.1
> From reading your message it seems like Kerberos would be a near
> perfect fit for what you are trying to achieve, whereas I can't shake
> the impression that you are trying to "bend" SSL  a little to
> accomodate your specific use case.
>
> Best regards,
> Sönke
>
> On Mon, Mar 12, 2018 at 8:46 PM, Alexander Maniates <maniat...@gmail.com>
> wrote:
> > Our set up:
> >
> > Brokers on 0.10.1
> > Clients on 0.9
> >
> > -On startup, clients are dynamically issued a signed certificate that is
> > vaild for 48 hours. A JKS is created using this certificate.
> > -All brokers have a signed certificate in their JKS that is valid for
> some
> > years.
> >
> > The issue:
> >
> > Clients only load their JKS once on startup. After 48 hours when the
> > certificate expires, if a broker then restarts, clients are not able to
> > make a new SSL connection with the JKS and certificate that was loaded on
> > startup.
> >
> > We have thousands of clients running at any given time, and do not want
> to
> > need to restart every service each time the certificates expire. We could
> > also make our client certificates last longer but that seems like a
> > possible security flaw.
> >
> > Our first proposed solution was to just rewrite the underlying JKS with a
> > new certificate every hour or so. However, as I mentioned, the JKS is
> only
> > loaded once at startup, so clients will never load this new JKS with a
> new
> > vaild certificate.
> >
> > In the context of a producer, the solution we are thinking of is to
> develop
> > a wrapper that is essentially a rolling client. Every so often, you
> rewrite
> > the JKS with a new valid certificate, create a new client which will load
> > the new JKS, swap the main client with the old client, then close the
> > original client and repeat the process.
> >
> > Has anybody else run into this problem and found a good solution? I'm
> > interested to hear any other solutions for tearing down and rebuilding
> SSL
> > connections on the fly.
> >
> >
> > Thanks,
> > Alex
>
>
>
> --
> Sönke Liebau
> Partner
> Tel. +49 179 7940878
> OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
>



-- 
Kaufman Ng
+1 646 961 8063
Solutions Architect | Confluent | www.confluent.io

Reply via email to