-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Romain,
On 6/11/20 13:34, Romain Manni-Bucau wrote: > @Chris: https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/ java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java ? Thanks! Stupid GitHub. I searched all your repositories for "encrypt" and it didn't find "letsencrypt". I guess "search" means "prefix match". *facepalm* > it is more or less what we have in meecrowave except meecrowave > can hotreload whereas this (pre reloadSslHostConfig method) impl > does not. Your LetsEncryptManager seems to call reloadSslHostConfigs. What does Meecrowave do differently? - -chris > Le jeu. 11 juin 2020 à 19:20, Christopher Schultz > <ch...@christopherschultz.net > <mailto:ch...@christopherschultz.net>> a écrit : > > Merlin, > > On 6/10/20 12:32, Merlin Beedell wrote: >> Well thanks Christopher - that presentation link was just what I >> needed (well - it was your presentation after all!). Really >> good. Ideally this could be written into the Tomcat standard >> Documentation, as it will crop up quite a bit. > >> In summary, 3 steps: > >> 1. Fetch cert update (requires port 80). > >> – certbot-auto renew > >> 2. Reformat for Tomcat usage [might be natively handled in later >> Tomcat releases?] > >> – openssl pkcs12 -export -in [cert] -inkey [key] -certfile >> [chain] -out [p12file] > >> 3. Use JMX to flush/reload the SSH Host config (including cipher >> list & protocol level) at runtime. > >> https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl e > >> r,port=8443,address= > <https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl er,port=8443,address=>"127.0.0.1"&op=reloadSslHostConfigs > > While > > "[documentation] patches are always welcome", I don't think I'd > want to put this into the Tomcat user's manual. If we add > information about Let's Encrypt, why not DigiCert? VeriSign? > GoDaddy? WhoeeverElseCA ? > > I could see this being something useful in the Tomcat Wiki. > > At least one person who has seen my presentation has said "we, I > was hoping there was just a letsencrypt='true' configuration flag". > I like the outside-in approach certbot takes with their Apache > plugins, rather than an inside-out approach where the server > actually has a plug-in for let's encrypt (or similar). > > Romain @ TomEE has written a WAR file that implements this > inside-out approach as a generic ACME servlet (context listener?), > but I can't seem to find his code anywhere... > > -chris > >> -----Original Message----- > >> From: Christopher Schultz <ch...@christopherschultz.net > <mailto:ch...@christopherschultz.net>> > >> Sent: 08 June 2020 9:14 PM > >> To: Tomcat Developers List <dev@tomcat.apache.org > <mailto:dev@tomcat.apache.org>>; Merlin Beedell >> <mbeed...@cryoserver.com <mailto:mbeed...@cryoserver.com>> > >> Subject: Re: Support for LetsEncrypt certs, and update process, >> in Tomcat without restart. > > > >> Hash: SHA256 > > > >> Merlin, > > > >> On 6/8/20 10:17, Merlin Beedell wrote: > >>> I am getting a lot of flack from some senior devs who insist >>> that > >>> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which >>> will > >>> handle the SSL offloading etc. > > > >>> While this seems sensible for multi-server environments, they >>> want it > >>> for single server too. But Tomcat can do all the things that >>> are > >>> required: > > > >>> * Certificate handling. * TLS level and Cipher restrictions * >>> CORS > >>> handling (though this could be simpler!) > > > >>> But now with the requirement for LetsEncrypt certificates, we >>> find > >>> that Tomcat has to be restarted every 3 months. Indeed – any >>> changes > >>> to the above require tomcat restarts – and that is found to be > >>> unacceptable. > > > >> Nonsense. > > > >> http://tomcat.apache.org/presentations.html#latest-lets-encrypt > > > >> Updating CORS configuration may require a redeployment of your >> web application, but it does not require Tomcat to be shut-down. > > > >> There are other reasons to use a reverse proxy in front of >> Tomcat, but none of the above are good reasons. > > > >>> So what I really want to understand is if Tomcat has any plans >>> to > >>> include the ability to restart an https connector WITHOUT >>> needing to > >>> restart the whole of Tomcat. Better still, a hook that would >>> help > >>> refresh certificates – like LetsEncrypt. > > > > >> https://stackoverflow.com/questions/43571572/programmatically-update- c > >> ertificates-in-tomcat-8-without-server-restart > <https://stackoverflow.com/questions/43571572/programmatically-update- certificates-in-tomcat-8-without-server-restart> > > > > > > > >> There > > > >> are no currently-correct answers to that question. > > > >> I can fix that. > > > >> -chris > > > > - --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > <mailto:dev-unsubscr...@tomcat.apache.org> For additional commands, > e-mail: dev-h...@tomcat.apache.org > <mailto:dev-h...@tomcat.apache.org> > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ibIYACgkQHPApP6U8 pFirPQ//XcSOJVLFXJWaHLJRLWfyZD3r12uVET731o/ciz3NbTA38XkziYPwWwj1 XimI1KVExvWdbvY/FjS7k2fddtp8tIPm4NWvbxyTpvnLR20w1K1YNltiSuv4SUlJ rGO32XouKgE0u3vFP/bESgWSmuKgv6NHAiKlfVPsjadWyaqlG6+gQiq+QVokMcje UOmuRp+DF7UVJ9ZHRyz4qRLZaqBElaEJwhvJc1QrvWlWZeC5vFN3m2qoUCqmyHyw 7TVjcGnbL7DTjW8DBfiItL0EzNQxWiOLFoNOf4PvBZToUrw9EGRUBZU6Vg3XKKte vkXw+sTALXZtnHut9ObsywwMWjaMPI1HF5HKa88WwBKHlhCpmIeW0Noz5m9GXm7W gNbJQ317MrPql+6tdL31CjQLkeytIU3JgINHjHrUSUKoBYpd8aq0ESN9Lghx62YH MVGtgj4TQ7fW+lexeAnNhWCW0ap2h0F2uC2YeutrXUY4poC/5kKdJN1vtpprJ72D jWWGiyE/8o90IFx8O3XOv7Fpu8ISAvpCIzSbBJf2WmmLDksmPtDJtoMr2kNCQctn tYZHlq1+NXWcUxxsdGzZRhSB59LTxK3H09bXHNdfp2522RRk+C0MShYJBykmaTjd D473GqjZ7it5MndnTsQxEatcw4u5+/c+pGjcqTvMuL1ADz6WwgA= =KRBb -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org