+1 for connectors IMHO

Le mer. 27 juin 2018 18:21, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Romain,
>
> On 6/27/18 11:50 AM, Romain Manni-Bucau wrote:
> > up? any hope we have live reloading of certs in tomcat?
>
> Yup. Recent versions allow you to reload the SSLHostConfigs.
>
> I was getting ready to update my presentation on Let's Encrypt,
> actually, so this was a good nudge to actually do that.
>
> I thought the operation would be exposed via JMX, but it does not
> appear to be so. It's in the Manager application.
>
> Have a look at what ManagerServlet.sslReload() does.
>
> markt, any objection to taking this code and putting it into the
> Connector under the public method reloadSSLHostConfig to make it (a)
> accessible via JMX and (b) easy to access?
>
> We have several options when it comes to JMX operations:
>
> 1. Connector
> 2. ProcotolHandler
> 3. SSLHostConfig
>
> #3 doesn't make much sense, since SSLHostConfigs are the ones that
> were loaded, and presumably will be replaced when a "reload" happens.
>
> #2 would work fine, except that:
>
> a. Everyone will look on the Connector first
> and
> b. The ProtocolHandler doesn't know if SSLEnabled=true on the connector
>
> So I think this is best-done on the Connector.
>
> Any comments or suggestions?
>
> - -chris
>
> >
> > Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> |
> > Blog <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-ee-8-high-perfo
> rmance>
> >
> >
> >
> > Le mar. 2 janv. 2018 à 17:00, Romain Manni-Bucau
> > <rmannibu...@gmail.com> a écrit :
> >
> >> Yes, if tomcat can supports hot reloading of certs it is very
> >> feasible:
> >> https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/ma
> in/java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.ja
> <https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.ja>
> va
> >>
> >>
> >>
> >>
> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github
> >> <https://github.com/rmannibucau> | LinkedIn
> >> <https://www.linkedin.com/in/rmannibucau>
> >>
> >> 2018-01-02 16:56 GMT+01:00 Emmanuel Bourg <ebo...@apache.org>:
> >>
> >>> Le 02/01/2018 à 09:40, Romain Manni-Bucau a écrit :
> >>>> up?
> >>>
> >>> I haven't got much time to look into this yet. However since
> >>> Let's Encrypt client implementations in Java are starting to
> >>> appear [1] I wonder if the certificate renewal process could be
> >>> directly integrated into Tomcat instead of relying on an
> >>> external client such as certbot.
> >>>
> >>> Emmanuel Bourg
> >>>
> >>> [1] https://github.com/shred/acme4j
> >>>
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlszuY4ACgkQHPApP6U8
> pFgxRA//Zsf+/zHUtTx1bVLFtJM7pYSHbdxepQRTCnEN4IS5dAeBSx7zI7w/OSV/
> Dt3Fd8dglDrimoYNEt4EWCAo0HNJjJkEsW9UbJPx0riyHQjqW4/wrSFFoWyDLmUg
> IEalbxZ++9MYlIcRAVwJRQ4lfze9g+e1CmkEyN3j3CZuq7mQp+5U9EEX8QkuI3Ig
> cRZfjztWST6Nsec88Y08w7VE+HYvTDQGG/0rzaeeJrQJ7zANxy2YtyBujzCTV3LK
> 2wzOMrc63X4VMGISwbimhFWRwfzwkwYmUZXOhCa0OW5/Ob56x/LVYtlRykfQAYbT
> xTIyaY+hc3cdbbDNEWymef6FbILbA7lOUOy0qhH2Aiv47gPCTIYyvDkYPr+tjoYo
> 5F+gqfTmy3qfBOBbRpcWcC9ySu5CdGvwP9YIMY8Q6ko8y/ySw26CK2XQH8Nm4yca
> os0zhOu2GzI0P202yGVavoSjLYsdJxDHCIcIRLowbCVBnp6bY1kL/dgGtyQoC7oi
> K9Yoz9LmjDJC+DkLSidZEugyGRCihI5fEAH9f1ftSDoCjMeYUMJ5dcOeiU2Vu5Ix
> CyYmiIgIDeWOitJJOOV38ogdGo8pGWJvFWymOt41BROtiS7OOTnURcc3Nx65C5mE
> odkio+xWznTt09a4Fb4cE9s1CoUIZ79ZkjFf2L4PY+xc27T5xvs=
> =8dT7
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Reply via email to