You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@kafka.apache.org by Alexander Maniates <ma...@gmail.com> on 2018/03/12 19:46:41 UTC
Solution for clients with long-lived sustained SSL connections using JKS
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
Re: Solution for clients with long-lived sustained SSL connections
using JKS
Posted by Kaufman Ng <ka...@confluent.io>.
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.liebau@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 <ma...@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
Re: Solution for clients with long-lived sustained SSL connections
using JKS
Posted by Sönke Liebau <so...@opencore.com.INVALID>.
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 <ma...@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