Side note: using a servlet generally does not work if you have any security
on the webapp + requires a webapp whereas using a valve solves these two
issues.

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-performance>


Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <mladen.adamo...@gmail.com> a
écrit :

> As I haven't received more replies on this topic, I'm guessing project
> maintainers are not interested in reviewing and including the code for
> simpler Letsencrypt integration and discussing the mentioned SSL
> documentation improvements?
>
> Enabling AMCE response servlet (good idea by default) would be a good step
> in my opinion?
>
> My procedure is explained here:
>
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> and the step "Configure HTTP redirect application with support to ACME
> challenge" could be integrated into Tomcat easily.
>
> In the case that is integrated, I can write a new improved
> tutorial/process.
>
>
>
>
> On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> mladen.adamo...@gmail.com>
> wrote:
>
> > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> It moves the problem elsewhere, how would the CLI communicate with
> tomcat?
> >> JMX, HTTP uses a port, a file based communication would be probably
> worse
> >> because of perms and other admin issues (and just not working in k8s).
> >>
> >
> > I don't see other sane ways actually. So it seems a web-based manager
> with
> > curl is there to stay (for the time being at least).
> >
> > To Chris: It's somewhat weird that the user needs a web manager just for
> > curl-ing certification renewal.
> >
> > To everyone:
> > I have a suggestion on improving Documentation regarding SSL.
> > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > Currently, it states
> > Configuration
> > Prepare the Certificate Keystore
> > Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores.
> >
> > ...
> >
> >
> > I think it should start with
> > Configuration
> > Option 1) Use Tomcat Native
> > which would showcase a path to something like:
> >
> > <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
> > <Connector
> >     protocol="org.apache.coyote.http11.Http11NioProtocol"
> >     port="8443"
> >     maxThreads="150"
> >     SSLEnabled="true" >
> >   <SSLHostConfig>
> >     <Certificate
> >         certificateKeyFile="conf/localhost-rsa-key.pem"
> >         certificateFile="conf/localhost-rsa-cert.pem"
> >         certificateChainFile="conf/localhost-rsa-chain.pem"
> >         type="RSA"
> >         />
> >   </SSLHostConfig>
> > </Connector>
> >
> > Option 2) Without Tomcat Native
> >
> >
> > ...
> >
> >
> >
> > I don't know what is the formal process for improving the documentation
> > here?
> >
> >
> >
> >
> >
> > > > >
> >> > > >
> >> > > >
> >> > > > >
> >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> >> > > mladen.adamo...@gmail.com
> >> > > > >
> >> > > > > a
> >> > > > > écrit :
> >> > > > >
> >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> >> > > > > > ch...@christopherschultz.net> wrote:
> >> > > > > >
> >> > > > > > > Why not use cron? You can do this with a single "curl"
> command
> >> > and
> >> > > > the
> >> > > > > > > Manager+JMXProxyServlet.
> >> > > > > > >
> >> > > > > >
> >> > > > > > We are not using Tomcat manager app.
> >> > > > > >
> >> > > > > > Why someone should be forced to use Manager, to read/setup the
> >> > > > > > documentation regarding JMXProxyServlet, create an additional
> >> > > > > > servlet (where does it have dependency on?) only to reload
> >> > > > automatically
> >> > > > > > certificates?
> >> > > > > >
> >> > > > > > I'm proposing a solution with the simple SSLHostConfig
> >> parameter.
> >> > > It's
> >> > > > a
> >> > > > > > user friendly. Simple, intuitive.
> >> > > > > > No need for using manager, no need to create a specific
> servlet
> >> > > > somewhere
> >> > > > > > in your code. Just a single server.xml argument.
> >> > > > > >
> >> > > > > > Also, *another idea*, I'm contributing this code (see below)
> we
> >> are
> >> > > > using
> >> > > > > > for Letsencrypt ACME challenge.
> >> > > > > > Tomcat could also have an option, i.e. in web.xml to
> >> automatically
> >> > > > > support
> >> > > > > > Letsencrypt ACME challenge.
> >> > > > > > Idea for web.xml
> >> > > > > >   <servlet>
> >> > > > > >         <servlet-name>Letsencrypt-acme</servlet-name>
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> >> > > > > >         <init-param>
> >> > > > > > etc.
> >> > > > > > </servlet>
> >> > > > > >
> >> > > > > >
> >> > > > > > We are using
> >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> >> > > > > > {"/.well-known/acme-challenge/*"})
> >> > > > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> >> > > > > >
> >> > > > > >   /**
> >> > > > > >    * Processes requests for both HTTP <code>GET</code> and
> >> > > > > > <code>POST</code> methods.
> >> > > > > >    *
> >> > > > > >    * @param request servlet request
> >> > > > > >    * @param response servlet response
> >> > > > > >    * @throws ServletException if a servlet-specific error
> occurs
> >> > > > > >    * @throws IOException if an I/O error occurs
> >> > > > > >    */
> >> > > > > >   protected void processRequest(HttpServletRequest request,
> >> > > > > > HttpServletResponse response)
> >> > > > > >       throws ServletException, IOException {
> >> > > > > >     String requestUrl = request.getRequestURL().toString();
> >> > > > > >     if (requestUrl.contains(".well-known/acme-challenge/")) {
> >> > > > > >       int indexFilename = requestUrl.lastIndexOf("/") + 1;
> >> > > > > >       boolean wasError = true;
> >> > > > > >       if (indexFilename > 0 && indexFilename <
> >> > requestUrl.length()) {
> >> > > > > >         String filename = requestUrl.substring(indexFilename);
> >> > > > > >         File existingFile = new
> >> > > > > >
> File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> >> +
> >> > > > > >  filename);
> >> > > > > >         if (existingFile.exists()) {
> >> > > > > >           response.setContentType("text/plain");
> >> > > > > >           OutputStream out = response.getOutputStream();
> >> > > > > >           FileInputStream in = new
> >> FileInputStream(existingFile);
> >> > > > > >           FilesOperations.inputStreamToOutputStream(in, out);
> >> > > > > >           wasError = false;
> >> > > > > >         }
> >> > > > > >       }
> >> > > > > >       if (wasError) {
> >> > > > > >         throw new ServletException("invalid requestUrl " +
> >> > > requestUrl);
> >> > > > > >       }
> >> > > > > >   }
> >> > > > > >
> >> > > > > > from FilesOperations:
> >> > > > > >      public static void inputStreamToOutputStream(InputStream
> >> in,
> >> > > > > > OutputStream out) throws IOException {
> >> > > > > >         try {
> >> > > > > >             byte[  ] buf = new byte[32 * 1024];  // 32K buffer
> >> > > > > >             int bytesRead;
> >> > > > > >             while ((bytesRead = in.read(buf)) != -1) {
> >> > > > > >                 out.write(buf, 0, bytesRead);
> >> > > > > >             }
> >> > > > > >         } finally {
> >> > > > > >             if (in != null) {
> >> > > > > >               in.close();
> >> > > > > >               out.close();
> >> > > > > >             }
> >> > > > > >         }
> >> > > > > >     }
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > > > *Long*:
> >> > > > > > > > SSL certificates have a period of expiration and in the
> >> case of
> >> > > > > > > > Letsencrypt, it's set to 3 months as they think everyone
> >> should
> >> > > > have
> >> > > > > > the
> >> > > > > > > > renewal mechanism automatically.
> >> > > > > > > >
> >> > > > > > > > As the Letsencrypt is the most popular SSL issuing
> authority
> >> > > > (source:
> >> > > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think
> >> Tomcat
> >> > > > > should
> >> > > > > > > have
> >> > > > > > > > an integration with Letsencrypt working flawlessly.
> >> > > > > > > >
> >> > > > > > > > We are currently using the script to renew the certificate
> >> (I
> >> > can
> >> > > > > share
> >> > > > > > > our
> >> > > > > > > > integration details with whoever is interested, please
> >> email me
> >> > > if
> >> > > > > you
> >> > > > > > > are
> >> > > > > > > > interested), but it's restarting Tomcat.
> >> > > > > > > >
> >> > > > > > > > As Tomcat shall not be restarted ever (ideally), I think
> >> Tomcat
> >> > > > > should
> >> > > > > > > have
> >> > > > > > > > an option to reload certificate, without a dependency to
> >> Tomcat
> >> > > > > source
> >> > > > > > > code
> >> > > > > > > > and "hacks" like some available on StackOverflow:
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> >> > > > > > > ).
> >> > > > > > > > Those hacks are no good as:
> >> > > > > > > > 1) code to reload certificate should not run inside Java
> >> code,
> >> > as
> >> > > > > > > > letsencrypt is invoked through Linux
> >> > > > > > > > 2) each application uses that Stackoverflow hack have
> >> > additional
> >> > > > > > compile
> >> > > > > > > > and run dependency set to Tomcat (which is very bad).
> >> > > > > > > >
> >> > > > > > > > I have a proposal on how this should be fixed: Tomcat
> should
> >> > > have a
> >> > > > > > > > server.xml options something like
> >> certificateReloadAfterDays or
> >> > > > > > > > reloadAfterDays
> >> > > > > > > >
> >> > > > > > > > I see this is moved to SSLHostConfig, we are still using
> old
> >> > > > params.
> >> > > > > > > >
> >> > > > > > > > Do you agree on this feature?
> >> > > > > > > >
> >> > > > > > > > If so... I'm not lazy to try to do it myself, but as I
> >> haven't
> >> > > ever
> >> > > > > > > written
> >> > > > > > > > Tomcat code neither know procedures (I have been coding
> >> > > > > professionally
> >> > > > > > > > since 2006, but I never committed to Maven or Git project
> >> > before,
> >> > > > > lol),
> >> > > > > > > is
> >> > > > > > > > there someone else who is keen on doing this feature?
> >> > > > > > >
> >> > > > > > > Have a look at this:
> >> > > > > > >
> >> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> >> > > > > > >
> >> > > > > > > -chris
> >> > > > > > >
> >> > > > > > >
> >> > >
> ---------------------------------------------------------------------
> >> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> > > > > > > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

Reply via email to