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