date:20201223

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ć 
wrote:

> On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau 
> 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:
>
> 
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
> port="8443"
> maxThreads="150"
> SSLEnabled="true" >
>   
>  certificateKeyFile="conf/localhost-rsa-key.pem"
> certificateFile="conf/localhost-rsa-cert.pem"
> certificateChainFile="conf/localhost-rsa-chain.pem"
> type="RSA"
> />
>   
> 
>
> 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
>> > > > > >   
>> > > > > > Letsencrypt-acme
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> org.apache.catalina.servlets.LetsencryptAcmeChallenge
>> > > > > > 
>> > > > > > etc.
>> > > > > > 
>> > > > > >
>> > > > > >
>> > > > > > We are using
>> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
>> > > > > > {"/.well-known/acme-challenge/*"})
>> > > > > > public class LetsencryptAcmeChallenge extends HttpServlet {
>> > > > > >
>> > > > > >   /**
>> > > > > >* Processes requests for both HTTP GET and
>> > > > > > POST 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 (in

Re: feature request: reload SSL certificate automatically after X days (configuration option)

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 23 déc. 2020 à 09:15, Mladen Adamović  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:
> >
> > 
> >  > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > port="8443"
> > maxThreads="150"
> > SSLEnabled="true" >
> >   
> >  > certificateKeyFile="conf/localhost-rsa-key.pem"
> > certificateFile="conf/localhost-rsa-cert.pem"
> > certificateChainFile="conf/localhost-rsa-chain.pem"
> > type="RSA"
> > />
> >   
> > 
> >
> > 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
> >> > > > > >   
> >> > > > > > Letsencrypt-acme
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> org.apache.catalina.servlets.LetsencryptAcmeChallenge
> >> > > > > > 
> >> > > > > > etc.
> >> > > > > > 
> >> > > > > >
> >> > > > > >
> >> > > > > > We are using
> >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> >> > > > > > {"/.well-known/acme-challenge/*"})
> >> > > > > > public

[tomcat] branch master updated: Avoid JMX stacktraces when ruinning the testsuite

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 296766e  Avoid JMX stacktraces when ruinning the testsuite
296766e is described below

commit 296766ed66047115e409d69895f739e3b2a2c30d
Author: remm 
AuthorDate: Wed Dec 23 11:18:47 2020 +0100

Avoid JMX stacktraces when ruinning the testsuite
---
 java/org/apache/coyote/http2/Http2Protocol.java | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/http2/Http2Protocol.java 
b/java/org/apache/coyote/http2/Http2Protocol.java
index 51ed086..bb13224 100644
--- a/java/org/apache/coyote/http2/Http2Protocol.java
+++ b/java/org/apache/coyote/http2/Http2Protocol.java
@@ -349,7 +349,10 @@ public class Http2Protocol implements UpgradeProtocol {
 
 try {
 ObjectName oname = 
this.http11Protocol.getONameForUpgrade(getUpgradeProtocolName());
-Registry.getRegistry(null, null).registerComponent(global, oname, 
null);
+// This can be null when running the testsuite
+if (oname != null) {
+Registry.getRegistry(null, null).registerComponent(global, 
oname, null);
+}
 } catch (Exception e) {
 log.warn(sm.getString("http2Protocol.jmxRegistration.fail"), e);
 }


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch 9.0.x updated: Avoid JMX stacktraces when ruinning the testsuite

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 91b9b78  Avoid JMX stacktraces when ruinning the testsuite
91b9b78 is described below

commit 91b9b78501407be0e2a758fa36118bb32e612faa
Author: remm 
AuthorDate: Wed Dec 23 11:18:47 2020 +0100

Avoid JMX stacktraces when ruinning the testsuite
---
 java/org/apache/coyote/http2/Http2Protocol.java | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/http2/Http2Protocol.java 
b/java/org/apache/coyote/http2/Http2Protocol.java
index 0167b05..4d34c80 100644
--- a/java/org/apache/coyote/http2/Http2Protocol.java
+++ b/java/org/apache/coyote/http2/Http2Protocol.java
@@ -455,7 +455,10 @@ public class Http2Protocol implements UpgradeProtocol {
 
 try {
 ObjectName oname = 
this.http11Protocol.getONameForUpgrade(getUpgradeProtocolName());
-Registry.getRegistry(null, null).registerComponent(global, oname, 
null);
+// This can be null when running the testsuite
+if (oname != null) {
+Registry.getRegistry(null, null).registerComponent(global, 
oname, null);
+}
 } catch (Exception e) {
 log.warn(sm.getString("http2Protocol.jmxRegistration.fail"), e);
 }


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch 8.5.x updated: Avoid JMX stacktraces when ruinning the testsuite

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 3f78050  Avoid JMX stacktraces when ruinning the testsuite
3f78050 is described below

commit 3f78050742684c508d2fbb8d1efed05a4f596f31
Author: remm 
AuthorDate: Wed Dec 23 11:18:47 2020 +0100

Avoid JMX stacktraces when ruinning the testsuite
---
 java/org/apache/coyote/http2/Http2Protocol.java | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/http2/Http2Protocol.java 
b/java/org/apache/coyote/http2/Http2Protocol.java
index b8d3b0a..1606614 100644
--- a/java/org/apache/coyote/http2/Http2Protocol.java
+++ b/java/org/apache/coyote/http2/Http2Protocol.java
@@ -443,7 +443,10 @@ public class Http2Protocol implements UpgradeProtocol {
 
 try {
 ObjectName oname = 
this.http11Protocol.getONameForUpgrade(getUpgradeProtocolName());
-Registry.getRegistry(null, null).registerComponent(global, oname, 
null);
+// This can be null when running the testsuite
+if (oname != null) {
+Registry.getRegistry(null, null).registerComponent(global, 
oname, null);
+}
 } catch (Exception e) {
 log.warn(sm.getString("http2Protocol.jmxRegistration.fail"), e);
 }


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: feature request: reload SSL certificate automatically after X days (configuration option)

Thank you Romain, do you then think the place to check for ACME Valve (if
that would the be appropriate naming) would be in
CoyoteAdapter.postParseRequest line 814
before doConnectorAuthenticationAuthorization(...) ?


On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau 
wrote:

> 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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 23 déc. 2020 à 09:15, Mladen Adamović 
> 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:
> > >
> > > 
> > >  > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > port="8443"
> > > maxThreads="150"
> > > SSLEnabled="true" >
> > >   
> > >  > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > certificateFile="conf/localhost-rsa-cert.pem"
> > > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > type="RSA"
> > > />
> > >   
> > > 
> > >
> > > 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.

[tomcat] branch master updated: Add support for Unix domain sockets for NIO

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 884b997  Add support for Unix domain sockets for NIO
884b997 is described below

commit 884b997f5a9a7da9f696d00574d3b727afbfae8c
Author: remm 
AuthorDate: Wed Dec 23 11:45:58 2020 +0100

Add support for Unix domain sockets for NIO

This requires Java 16 or later, and NIO (NIO2 did not get the feature).
This does not remove the socket on shutdown, not sure what the best
behavior is there. The socket is closed and Java doesn't do anything
about that. This uses a bit of reflection, maybe the
unixDomainSocketPath attribute can be added to avoid that, if the
feature is actually popular.
When using the feature, the JMX and thread names are slightly adjusted,
and using the port attribute is optional.
Based on a PR submitted by Graham Leggett
https://github.com/apache/tomcat/pull/382
---
 java/org/apache/catalina/connector/Connector.java  |  56 ++-
 java/org/apache/coyote/AbstractProtocol.java   |  31 +++---
 .../org/apache/tomcat/util/compat/Jre16Compat.java |  15 +++
 java/org/apache/tomcat/util/compat/JreCompat.java  |   9 ++
 .../apache/tomcat/util/net/AbstractEndpoint.java   |   2 +-
 java/org/apache/tomcat/util/net/NioEndpoint.java   | 107 +++--
 webapps/docs/changelog.xml |   7 ++
 webapps/docs/config/http.xml   |  21 
 8 files changed, 205 insertions(+), 43 deletions(-)

diff --git a/java/org/apache/catalina/connector/Connector.java 
b/java/org/apache/catalina/connector/Connector.java
index c2e7e25..4f4be1c 100644
--- a/java/org/apache/catalina/connector/Connector.java
+++ b/java/org/apache/catalina/connector/Connector.java
@@ -950,23 +950,30 @@ public class Connector extends LifecycleMBeanBase  {
 
 StringBuilder sb = new StringBuilder("type=");
 sb.append(type);
-sb.append(",port=");
-int port = getPortWithOffset();
-if (port > 0) {
-sb.append(port);
+Object path = getProperty("unixDomainSocketPath");
+if (path != null) {
+// Maintain MBean name compatibility, even if not accurate
+sb.append(",port=0,address=");
+sb.append(ObjectName.quote(path.toString()));
 } else {
-sb.append("auto-");
-sb.append(getProperty("nameIndex"));
-}
-String address = "";
-if (addressObj instanceof InetAddress) {
-address = ((InetAddress) addressObj).getHostAddress();
-} else if (addressObj != null) {
-address = addressObj.toString();
-}
-if (address.length() > 0) {
-sb.append(",address=");
-sb.append(ObjectName.quote(address));
+sb.append(",port=");
+int port = getPortWithOffset();
+if (port > 0) {
+sb.append(port);
+} else {
+sb.append("auto-");
+sb.append(getProperty("nameIndex"));
+}
+String address = "";
+if (addressObj instanceof InetAddress) {
+address = ((InetAddress) addressObj).getHostAddress();
+} else if (addressObj != null) {
+address = addressObj.toString();
+}
+if (address.length() > 0) {
+sb.append(",address=");
+sb.append(ObjectName.quote(address));
+}
 }
 return sb.toString();
 }
@@ -1059,7 +1066,7 @@ public class Connector extends LifecycleMBeanBase  {
 protected void startInternal() throws LifecycleException {
 
 // Validate settings before starting
-if (getPortWithOffset() < 0) {
+if (getProperty("unixDomainSocketPath") == null && getPortWithOffset() 
< 0) {
 throw new LifecycleException(sm.getString(
 "coyoteConnector.invalidPort", 
Integer.valueOf(getPortWithOffset(;
 }
@@ -1125,12 +1132,17 @@ public class Connector extends LifecycleMBeanBase  {
 StringBuilder sb = new StringBuilder("Connector[");
 sb.append(getProtocol());
 sb.append('-');
-int port = getPortWithOffset();
-if (port > 0) {
-sb.append(port);
+Object path = getProperty("unixDomainSocketPath");
+if (path != null) {
+sb.append(path.toString());
 } else {
-sb.append("auto-");
-sb.append(getProperty("nameIndex"));
+int port = getPortWithOffset();
+if (port > 0) {
+sb.append(port);
+} else {
+sb.append("auto-");
+sb.append(getProperty("nameIndex"));
+}
 }
 sb.append(']');
 return sb.toString()

[GitHub] [tomcat] rmaucher commented on pull request #382: Add support for unix domain sockets.



rmaucher commented on pull request #382:
URL: https://github.com/apache/tomcat/pull/382#issuecomment-750141172


   I added the feature for NIO, since it wasn't too difficult using 
https://openjdk.java.net/jeps/380 . Testing with curl works fine, I'll add a 
test in the testsuite next. It does have specific unlock accept, some 
compatibility code for port/address annoyances ("TCP local addresses" for 
access logs, JMX name, connector name), and the port attribute becomes 
optional. This cannot be added to NIO2 since the feature is not available.
   
   Some possible changes:
   - The permission attribute, is it really useful ?
   - Reflection is used for this attribute for now since this is NIO only
   - The socket is not deleted on shutdown (although the channel is closed)



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] michael-o commented on pull request #382: Add support for unix domain sockets.



michael-o commented on pull request #382:
URL: https://github.com/apache/tomcat/pull/382#issuecomment-750148235


   I see no reason why this cannot work which Java UDS and APR UDS.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: feature request: reload SSL certificate automatically after X days (configuration option)

I don't think so, this connector auth is only used in very particular cases
(= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is also a
kind of automatic authorization - no password or so - so will pass and not
fail.
My point was if you have some security contraint (JWT, basic, etc...) on
/*, then your servlet will not be called for letsencrypt call whereas if
you have a valve you can still handle it properly since you didn't enter
the secured chain - a valve is before filter chain and can be before
authenticators in valve chain since authenticators - AuthenticatorBase -
are valves.
In other words: no code change required in tomcat internals.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 23 déc. 2020 à 11:23, Mladen Adamović  a
écrit :

> Thank you Romain, do you then think the place to check for ACME Valve (if
> that would the be appropriate naming) would be in
> CoyoteAdapter.postParseRequest line 814
> before doConnectorAuthenticationAuthorization(...) ?
>
>
> On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau 
> wrote:
>
> > 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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović  >
> > 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:
> > > >
> > > > 
> > > >  > > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > port="8443"
> > > > maxThreads="150"
> > > > SSLEnabled="true" >
> > > >   
> > > >  > > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > > certificateFile="conf/localhost-rsa-cert.pem"
> > > > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > > type="RSA"
> > > > />
> > > >   
> > > > 
> > > >
> > > > 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

Re: feature request: reload SSL certificate automatically after X days (configuration option)

On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau 
wrote:

> I don't think so, this connector auth is only used in very particular cases
> (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is also a
> kind of automatic authorization - no password or so - so will pass and not
> fail.
>

That sounds very strange, as I have seen in the code:
if (req.getRemoteUserNeedsAuthorization()) {
...
} else if (!(authenticator instanceof AuthenticatorBase)) {
   ...
}

public class SSLAuthenticator extends AuthenticatorBase {


My point was if you have some security contraint (JWT, basic, etc...) on
> /*, then your servlet will not be called for letsencrypt call whereas if
> you have a valve you can still handle it properly since you didn't enter
> the secured chain - a valve is before filter chain and can be before
> authenticators in valve chain since authenticators - AuthenticatorBase -
> are valves.
>

Authenticator Valve's seems to me to have a different treatment than other
Valves which are accessed through Pipeline.



> In other words: no code change required in tomcat internals.
>

I don't understand this yet. If the implementation would use serverl.xml to
change StandardContextValve to something else?

I've tried to figure out what are you doing in meecrowave and my IDE
(Netbeans) shows me Usage of LetsEncryptValve [no occurrences]

How this LetsEncryptValve is actually "injected" into meecrowave Pipeline ?
Or how it is used internally?
I didn't see any Reflection code on Valves or Valve base by searching
source code.




>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 23 déc. 2020 à 11:23, Mladen Adamović 
> a
> écrit :
>
> > Thank you Romain, do you then think the place to check for ACME Valve (if
> > that would the be appropriate naming) would be in
> > CoyoteAdapter.postParseRequest line 814
> > before doConnectorAuthenticationAuthorization(...) ?
> >
> >
> > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > 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  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | 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

[GitHub] [tomcat] martin-g commented on pull request #382: Add support for unix domain sockets.



martin-g commented on pull request #382:
URL: https://github.com/apache/tomcat/pull/382#issuecomment-750260041


   @rmaucher 
https://github.com/apache/tomcat/commit/884b997f5a9a7da9f696d00574d3b727afbfae8c#diff-117ff4ae372c7a4f6643546174bcc2dbf5a25bd399fe1b89f55e72d2d4150285R212



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] rmaucher commented on pull request #382: Add support for unix domain sockets.



rmaucher commented on pull request #382:
URL: https://github.com/apache/tomcat/pull/382#issuecomment-750274850


   It can 100% work with APR, except I personally don't want to add features to 
that component at this point.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: feature request: reload SSL certificate automatically after X days (configuration option)

Le mer. 23 déc. 2020 à 12:50, Mladen Adamović  a
écrit :

> On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau  >
> wrote:
>
> > I don't think so, this connector auth is only used in very particular
> cases
> > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is
> also a
> > kind of automatic authorization - no password or so - so will pass and
> not
> > fail.
> >
>
> That sounds very strange, as I have seen in the code:
> if (req.getRemoteUserNeedsAuthorization()) {
> ...
> } else if (!(authenticator instanceof AuthenticatorBase)) {
>...
> }
>
> public class SSLAuthenticator extends AuthenticatorBase {
>
>
Sure but check what makes remoteUserNeedsAuthorization true (http2 and ajp)
and what does the block when true (authenticate(username), no password or
so).
So not an issue IMHO.


>
> My point was if you have some security contraint (JWT, basic, etc...) on
> > /*, then your servlet will not be called for letsencrypt call whereas if
> > you have a valve you can still handle it properly since you didn't enter
> > the secured chain - a valve is before filter chain and can be before
> > authenticators in valve chain since authenticators - AuthenticatorBase -
> > are valves.
> >
>
> Authenticator Valve's seems to me to have a different treatment than other
> Valves which are accessed through Pipeline.
>

This is true since it can be obtained from the context and its call can be
forced, but here again the question is when.
If you check callers then it shouldn't be the case until you add another
valve doing it and if so you can still set the LetsEncryptValve before and
bypass it - can even be set on the host and not the context.


>
>
>
> > In other words: no code change required in tomcat internals.
> >
>
> I don't understand this yet. If the implementation would use serverl.xml to
> change StandardContextValve to something else?
>

No, change nothing, just add a valve on the host for example through  tag.


>
> I've tried to figure out what are you doing in meecrowave and my IDE
> (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
>

Maybe use another IDE ;) (joking ;)):
https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
server.xml but it is equivalent to previous proposal ().


>
> How this LetsEncryptValve is actually "injected" into meecrowave Pipeline ?
> Or how it is used internally?
> I didn't see any Reflection code on Valves or Valve base by searching
> source code.
>
>
>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 23 déc. 2020 à 11:23, Mladen Adamović  >
> > a
> > écrit :
> >
> > > Thank you Romain, do you then think the place to check for ACME Valve
> (if
> > > that would the be appropriate naming) would be in
> > > CoyoteAdapter.postParseRequest line 814
> > > before doConnectorAuthenticationAuthorization(...) ?
> > >
> > >
> > > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > 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  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | 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
> > > > > challe

[tomcat] branch 9.0.x updated: Add support for Unix domain sockets for NIO

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 0d27655  Add support for Unix domain sockets for NIO
0d27655 is described below

commit 0d276556881446aa499fefd496d567606bc0ddec
Author: remm 
AuthorDate: Wed Dec 23 11:45:58 2020 +0100

Add support for Unix domain sockets for NIO

This requires Java 16 or later, and NIO (NIO2 did not get the feature).
This does not remove the socket on shutdown, not sure what the best
behavior is there. The socket is closed and Java doesn't do anything
about that. This uses a bit of reflection, maybe the
unixDomainSocketPath attribute can be added to avoid that, if the
feature is actually popular.
When using the feature, the JMX and thread names are slightly adjusted,
and using the port attribute is optional.
Based on a PR submitted by Graham Leggett
https://github.com/apache/tomcat/pull/382
---
 java/org/apache/catalina/connector/Connector.java  |  56 ++-
 java/org/apache/coyote/AbstractProtocol.java   |  31 +++---
 .../org/apache/tomcat/util/compat/Jre16Compat.java |  15 +++
 java/org/apache/tomcat/util/compat/JreCompat.java  |   9 ++
 .../apache/tomcat/util/net/AbstractEndpoint.java   |   2 +-
 java/org/apache/tomcat/util/net/NioEndpoint.java   | 107 +++--
 webapps/docs/changelog.xml |   7 ++
 webapps/docs/config/http.xml   |  21 
 8 files changed, 205 insertions(+), 43 deletions(-)

diff --git a/java/org/apache/catalina/connector/Connector.java 
b/java/org/apache/catalina/connector/Connector.java
index 1cc1580..28e0019 100644
--- a/java/org/apache/catalina/connector/Connector.java
+++ b/java/org/apache/catalina/connector/Connector.java
@@ -944,23 +944,30 @@ public class Connector extends LifecycleMBeanBase  {
 
 StringBuilder sb = new StringBuilder("type=");
 sb.append(type);
-sb.append(",port=");
-int port = getPortWithOffset();
-if (port > 0) {
-sb.append(port);
+Object path = getProperty("unixDomainSocketPath");
+if (path != null) {
+// Maintain MBean name compatibility, even if not accurate
+sb.append(",port=0,address=");
+sb.append(ObjectName.quote(path.toString()));
 } else {
-sb.append("auto-");
-sb.append(getProperty("nameIndex"));
-}
-String address = "";
-if (addressObj instanceof InetAddress) {
-address = ((InetAddress) addressObj).getHostAddress();
-} else if (addressObj != null) {
-address = addressObj.toString();
-}
-if (address.length() > 0) {
-sb.append(",address=");
-sb.append(ObjectName.quote(address));
+sb.append(",port=");
+int port = getPortWithOffset();
+if (port > 0) {
+sb.append(port);
+} else {
+sb.append("auto-");
+sb.append(getProperty("nameIndex"));
+}
+String address = "";
+if (addressObj instanceof InetAddress) {
+address = ((InetAddress) addressObj).getHostAddress();
+} else if (addressObj != null) {
+address = addressObj.toString();
+}
+if (address.length() > 0) {
+sb.append(",address=");
+sb.append(ObjectName.quote(address));
+}
 }
 return sb.toString();
 }
@@ -1053,7 +1060,7 @@ public class Connector extends LifecycleMBeanBase  {
 protected void startInternal() throws LifecycleException {
 
 // Validate settings before starting
-if (getPortWithOffset() < 0) {
+if (getProperty("unixDomainSocketPath") == null && getPortWithOffset() 
< 0) {
 throw new LifecycleException(sm.getString(
 "coyoteConnector.invalidPort", 
Integer.valueOf(getPortWithOffset(;
 }
@@ -1119,12 +1126,17 @@ public class Connector extends LifecycleMBeanBase  {
 StringBuilder sb = new StringBuilder("Connector[");
 sb.append(getProtocol());
 sb.append('-');
-int port = getPortWithOffset();
-if (port > 0) {
-sb.append(port);
+Object path = getProperty("unixDomainSocketPath");
+if (path != null) {
+sb.append(path.toString());
 } else {
-sb.append("auto-");
-sb.append(getProperty("nameIndex"));
+int port = getPortWithOffset();
+if (port > 0) {
+sb.append(port);
+} else {
+sb.append("auto-");
+sb.append(getProperty("nameIndex"));
+}
 }
 sb.append(']');
 return sb.toString();

Re: feature request: reload SSL certificate automatically after X days (configuration option)

hmmm.. at least for us, Certbot fetches acme-challenge on HTTP connector.
According to
https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
an app most likely should have a HTTP connector for Letsencrypt.

Then it really doesn't matter AFAIK, if Servet is used or a Valve for most
cases.  Whatever dev thinks fits more in the nature of the system.

I know this can be implemented outside of Tomcat (as we have that
implementation through Servlet), I'm discussing what could be done in
Tomcat to simplify Letsencrypt integration.


On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau 
wrote:

> Le mer. 23 déc. 2020 à 12:50, Mladen Adamović 
> a
> écrit :
>
> > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > I don't think so, this connector auth is only used in very particular
> > cases
> > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is
> > also a
> > > kind of automatic authorization - no password or so - so will pass and
> > not
> > > fail.
> > >
> >
> > That sounds very strange, as I have seen in the code:
> > if (req.getRemoteUserNeedsAuthorization()) {
> > ...
> > } else if (!(authenticator instanceof
> AuthenticatorBase)) {
> >...
> > }
> >
> > public class SSLAuthenticator extends AuthenticatorBase {
> >
> >
> Sure but check what makes remoteUserNeedsAuthorization true (http2 and ajp)
> and what does the block when true (authenticate(username), no password or
> so).
> So not an issue IMHO.
>
>
> >
> > My point was if you have some security contraint (JWT, basic, etc...) on
> > > /*, then your servlet will not be called for letsencrypt call whereas
> if
> > > you have a valve you can still handle it properly since you didn't
> enter
> > > the secured chain - a valve is before filter chain and can be before
> > > authenticators in valve chain since authenticators - AuthenticatorBase
> -
> > > are valves.
> > >
> >
> > Authenticator Valve's seems to me to have a different treatment than
> other
> > Valves which are accessed through Pipeline.
> >
>
> This is true since it can be obtained from the context and its call can be
> forced, but here again the question is when.
> If you check callers then it shouldn't be the case until you add another
> valve doing it and if so you can still set the LetsEncryptValve before and
> bypass it - can even be set on the host and not the context.
>
>
> >
> >
> >
> > > In other words: no code change required in tomcat internals.
> > >
> >
> > I don't understand this yet. If the implementation would use serverl.xml
> to
> > change StandardContextValve to something else?
> >
>
> No, change nothing, just add a valve on the host for example through  className /> tag.
>
>
> >
> > I've tried to figure out what are you doing in meecrowave and my IDE
> > (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
> >
>
> Maybe use another IDE ;) (joking ;)):
>
> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
> The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
> server.xml but it is equivalent to previous proposal ().
>
>
> >
> > How this LetsEncryptValve is actually "injected" into meecrowave
> Pipeline ?
> > Or how it is used internally?
> > I didn't see any Reflection code on Valves or Valve base by searching
> > source code.
> >
> >
> >
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <
> mladen.adamo...@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > Thank you Romain, do you then think the place to check for ACME Valve
> > (if
> > > > that would the be appropriate naming) would be in
> > > > CoyoteAdapter.postParseRequest line 814
> > > > before doConnectorAuthenticationAuthorization(...) ?
> > > >
> > > >
> > > > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > 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  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn

Re: feature request: reload SSL certificate automatically after X days (configuration option)

Le mer. 23 déc. 2020 à 15:08, Mladen Adamović  a
écrit :

> hmmm.. at least for us, Certbot fetches acme-challenge on HTTP connector.
> According to
>
> https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
> an app most likely should have a HTTP connector for Letsencrypt.
>

Why? I don't see the gain there except requiring 2 ports if you dedicate
one connector for letsencrypt.


>
> Then it really doesn't matter AFAIK, if Servet is used or a Valve for most
> cases.  Whatever dev thinks fits more in the nature of the system.
>

Hmm, this is where I disagree, if you use letsencrypt in  secured app then
a servlet will just not be called whereas the valve will as explained so -
IMHO indeed - it does not depend, only exception to that is when you have
no routing filter and no security in your app - not sure it is mainstream
or not but I know the opposite is common.


>
> I know this can be implemented outside of Tomcat (as we have that
> implementation through Servlet), I'm discussing what could be done in
> Tomcat to simplify Letsencrypt integration.
>

I'm tempted to say either provide a default tomcat-letsencrypt module
"ready to activate" - and I would support you in that work - or nothing
since tomcat is letsencryts friendly thanks its pluggable design IMHO
Do you see anything else which would need to change? The reloadSSL method
was added for letsencrypt already so guess this adjustment work is already
done.


>
>
> On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau 
> wrote:
>
> > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović  >
> > a
> > écrit :
> >
> > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > I don't think so, this connector auth is only used in very particular
> > > cases
> > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is
> > > also a
> > > > kind of automatic authorization - no password or so - so will pass
> and
> > > not
> > > > fail.
> > > >
> > >
> > > That sounds very strange, as I have seen in the code:
> > > if (req.getRemoteUserNeedsAuthorization()) {
> > > ...
> > > } else if (!(authenticator instanceof
> > AuthenticatorBase)) {
> > >...
> > > }
> > >
> > > public class SSLAuthenticator extends AuthenticatorBase {
> > >
> > >
> > Sure but check what makes remoteUserNeedsAuthorization true (http2 and
> ajp)
> > and what does the block when true (authenticate(username), no password or
> > so).
> > So not an issue IMHO.
> >
> >
> > >
> > > My point was if you have some security contraint (JWT, basic, etc...)
> on
> > > > /*, then your servlet will not be called for letsencrypt call whereas
> > if
> > > > you have a valve you can still handle it properly since you didn't
> > enter
> > > > the secured chain - a valve is before filter chain and can be before
> > > > authenticators in valve chain since authenticators -
> AuthenticatorBase
> > -
> > > > are valves.
> > > >
> > >
> > > Authenticator Valve's seems to me to have a different treatment than
> > other
> > > Valves which are accessed through Pipeline.
> > >
> >
> > This is true since it can be obtained from the context and its call can
> be
> > forced, but here again the question is when.
> > If you check callers then it shouldn't be the case until you add another
> > valve doing it and if so you can still set the LetsEncryptValve before
> and
> > bypass it - can even be set on the host and not the context.
> >
> >
> > >
> > >
> > >
> > > > In other words: no code change required in tomcat internals.
> > > >
> > >
> > > I don't understand this yet. If the implementation would use
> serverl.xml
> > to
> > > change StandardContextValve to something else?
> > >
> >
> > No, change nothing, just add a valve on the host for example through
>  > className /> tag.
> >
> >
> > >
> > > I've tried to figure out what are you doing in meecrowave and my IDE
> > > (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
> > >
> >
> > Maybe use another IDE ;) (joking ;)):
> >
> >
> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
> > The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
> > server.xml but it is equivalent to previous proposal ().
> >
> >
> > >
> > > How this LetsEncryptValve is actually "injected" into meecrowave
> > Pipeline ?
> > > Or how it is used internally?
> > > I didn't see any Reflection code on Valves or Valve base by searching
> > > source code.
> > >
> > >
> > >
> > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn

Re: feature request: reload SSL certificate automatically after X days (configuration option)

On Wed, Dec 23, 2020 at 3:17 PM Romain Manni-Bucau 
wrote:

> I'm tempted to say either provide a default tomcat-letsencrypt module
> "ready to activate" - and I would support you in that work - or nothing
> since tomcat is letsencryts friendly thanks its pluggable design IMHO
>

I'm not sure what you mean by tomcat-letsencrypt module, as tomcat doesn't
have "Module" neither Letsencrypt according to Google search.

Tomcat is  not user friendly for Letsencrypt enough according to people who
are posting problems on Letsencrypt forums:
https://community.letsencrypt.org/search?q=tomcat%20order%3Alatest
you can see many people experiencing problems.

Situation in Payara is better with this script:
https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
(hopefully, I didn't try).




> Do you see anything else which would need to change? The reloadSSL method
> was added for letsencrypt already so guess this adjustment work is already
> done.


There are currently two options, through manager or through service
restart. It seems that there is no consensus here to add the 3th option.







>
> >
> >
> > On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <
> mladen.adamo...@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > I don't think so, this connector auth is only used in very
> particular
> > > > cases
> > > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It
> is
> > > > also a
> > > > > kind of automatic authorization - no password or so - so will pass
> > and
> > > > not
> > > > > fail.
> > > > >
> > > >
> > > > That sounds very strange, as I have seen in the code:
> > > > if (req.getRemoteUserNeedsAuthorization()) {
> > > > ...
> > > > } else if (!(authenticator instanceof
> > > AuthenticatorBase)) {
> > > >...
> > > > }
> > > >
> > > > public class SSLAuthenticator extends AuthenticatorBase {
> > > >
> > > >
> > > Sure but check what makes remoteUserNeedsAuthorization true (http2 and
> > ajp)
> > > and what does the block when true (authenticate(username), no password
> or
> > > so).
> > > So not an issue IMHO.
> > >
> > >
> > > >
> > > > My point was if you have some security contraint (JWT, basic, etc...)
> > on
> > > > > /*, then your servlet will not be called for letsencrypt call
> whereas
> > > if
> > > > > you have a valve you can still handle it properly since you didn't
> > > enter
> > > > > the secured chain - a valve is before filter chain and can be
> before
> > > > > authenticators in valve chain since authenticators -
> > AuthenticatorBase
> > > -
> > > > > are valves.
> > > > >
> > > >
> > > > Authenticator Valve's seems to me to have a different treatment than
> > > other
> > > > Valves which are accessed through Pipeline.
> > > >
> > >
> > > This is true since it can be obtained from the context and its call can
> > be
> > > forced, but here again the question is when.
> > > If you check callers then it shouldn't be the case until you add
> another
> > > valve doing it and if so you can still set the LetsEncryptValve before
> > and
> > > bypass it - can even be set on the host and not the context.
> > >
> > >
> > > >
> > > >
> > > >
> > > > > In other words: no code change required in tomcat internals.
> > > > >
> > > >
> > > > I don't understand this yet. If the implementation would use
> > serverl.xml
> > > to
> > > > change StandardContextValve to something else?
> > > >
> > >
> > > No, change nothing, just add a valve on the host for example through
> >  > > className /> tag.
> > >
> > >
> > > >
> > > > I've tried to figure out what are you doing in meecrowave and my IDE
> > > > (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
> > > >
> > >
> > > Maybe use another IDE ;) (joking ;)):
> > >
> > >
> >
> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
> > > The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
> > > server.xml but it is equivalent to previous proposal ().
> > >
> > >
> > > >
> > > > How this LetsEncryptValve is actually "injected" into meecrowave
> > > Pipeline ?
> > > > Or how it is used internally?
> > > > I didn't see any Reflection code on Valves or Valve base by searching
> > > > source code.
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> >

Re: feature request: reload SSL certificate automatically after X days (configuration option)

Le mer. 23 déc. 2020 à 15:36, Mladen Adamović  a
écrit :

> On Wed, Dec 23, 2020 at 3:17 PM Romain Manni-Bucau 
> wrote:
>
> > I'm tempted to say either provide a default tomcat-letsencrypt module
> > "ready to activate" - and I would support you in that work - or nothing
> > since tomcat is letsencryts friendly thanks its pluggable design IMHO
> >
>
> I'm not sure what you mean by tomcat-letsencrypt module, as tomcat doesn't
> have "Module" neither Letsencrypt according to Google search.
>

I meant that for me a letsencrypt work in tomcat can lead to create such a
module in the project and release it with other modules (next to jdbc
module maybe even if it is not embed by default).


>
> Tomcat is  not user friendly for Letsencrypt enough according to people who
> are posting problems on Letsencrypt forums:
> https://community.letsencrypt.org/search?q=tomcat%20order%3Alatest
> you can see many people experiencing problems.
>
> Situation in Payara is better with this script:
>
> https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
> (hopefully, I didn't try).
>

Well there are a few points to take into account here:

1. Usage, typically if you run in kubernetes or any managed instance env
then you don't care and will restart the instance (with graceful shutdown)
when needed
2. There are several tomcat instances out there using certbot (my blog is a
tomee with certbot on for example) so can also be a lack of doc/knowledge
3. I agree a built in module enables an easier deployment (just a valve to
configure with a few attributes) and everything else works OOTB but you
don't need any modification in tomcat distribution to do that - was my main
point, all can be done in a new module without modifying tomcat internals
for a particular deployment
4. In several cases tomcat will not have the SSL config but a frontend
(httpd, nginx, ...) will do it so tomcat integration will not help there

This is why, for me, a tomcat-letsencrypt module is the most relevant
solution.
If owned by Tomcat project perfect (this is the best IMHO), if not it will
still cover the same features so still good.

Hope it makes sense.


>
>
>
>
> > Do you see anything else which would need to change? The reloadSSL method
> > was added for letsencrypt already so guess this adjustment work is
> already
> > done.
>
>
> There are currently two options, through manager or through service
> restart. It seems that there is no consensus here to add the 3th option.
>
>
>
>
>
>
>
> >
> > >
> > >
> > > On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <
> > mladen.adamo...@gmail.com
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I don't think so, this connector auth is only used in very
> > particular
> > > > > cases
> > > > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It
> > is
> > > > > also a
> > > > > > kind of automatic authorization - no password or so - so will
> pass
> > > and
> > > > > not
> > > > > > fail.
> > > > > >
> > > > >
> > > > > That sounds very strange, as I have seen in the code:
> > > > > if (req.getRemoteUserNeedsAuthorization()) {
> > > > > ...
> > > > > } else if (!(authenticator instanceof
> > > > AuthenticatorBase)) {
> > > > >...
> > > > > }
> > > > >
> > > > > public class SSLAuthenticator extends AuthenticatorBase {
> > > > >
> > > > >
> > > > Sure but check what makes remoteUserNeedsAuthorization true (http2
> and
> > > ajp)
> > > > and what does the block when true (authenticate(username), no
> password
> > or
> > > > so).
> > > > So not an issue IMHO.
> > > >
> > > >
> > > > >
> > > > > My point was if you have some security contraint (JWT, basic,
> etc...)
> > > on
> > > > > > /*, then your servlet will not be called for letsencrypt call
> > whereas
> > > > if
> > > > > > you have a valve you can still handle it properly since you
> didn't
> > > > enter
> > > > > > the secured chain - a valve is before filter chain and can be
> > before
> > > > > > authenticators in valve chain since authenticators -
> > > AuthenticatorBase
> > > > -
> > > > > > are valves.
> > > > > >
> > > > >
> > > > > Authenticator Valve's seems to me to have a different treatment
> than
> > > > other
> > > > > Valves which are accessed through Pipeline.
> > > > >
> > > >
> > > > This is true since it can be obtained from the context and its call
> can
> > > be
> > > > forced, but here again the question is when.
> > > > If you check callers then it shouldn't be the case until you add
> > another
> > > > valve doing it and if so you can still set the LetsEncryptValve
> before
> > > and
> > > > bypass it - can even be set on the host and not the context.
> > > >
> > > >
> > > > >

Re: feature request: reload SSL certificate automatically after X days (configuration option)

On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau 
wrote:

> 1. Usage, typically if you run in kubernetes or any managed instance env
> then you don't care and will restart the instance (with graceful shutdown)
> when needed
>

This is outside of my scope.


> 2. There are several tomcat instances out there using certbot (my blog is a
> tomee with certbot on for example) so can also be a lack of doc/knowledge
>

That's well known before in the conversation, i.e. I'm running Tomcat with
SSL on numbeo.com as documented here:
https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/


> 3. I agree a built in module enables an easier deployment (just a valve to
> configure with a few attributes) and everything else works OOTB but you
> don't need any modification in tomcat distribution to do that - was my main
> point, all can be done in a new module without modifying tomcat internals
> for a particular deployment
>

But adding a Valve or a Servlet would mean modifying Tomcat internals?



> 4. In several cases tomcat will not have the SSL config but a frontend
> (httpd, nginx, ...) will do it so tomcat integration will not help there
>

Those suckers ;-)




>
> This is why, for me, a tomcat-letsencrypt module is the most relevant
> solution.
> If owned by Tomcat project perfect (this is the best IMHO), if not it will
> still cover the same features so still good.
>
> Hope it makes sense.
>
>
> >
> >
> >
> >
> > > Do you see anything else which would need to change? The reloadSSL
> method
> > > was added for letsencrypt already so guess this adjustment work is
> > already
> > > done.
> >
> >
> > There are currently two options, through manager or through service
> > restart. It seems that there is no consensus here to add the 3th option.
> >
> >
> >
> >
> >
> >
> >
> > >
> > > >
> > > >
> > > > On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <
> > > mladen.adamo...@gmail.com
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I don't think so, this connector auth is only used in very
> > > particular
> > > > > > cases
> > > > > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much.
> It
> > > is
> > > > > > also a
> > > > > > > kind of automatic authorization - no password or so - so will
> > pass
> > > > and
> > > > > > not
> > > > > > > fail.
> > > > > > >
> > > > > >
> > > > > > That sounds very strange, as I have seen in the code:
> > > > > > if (req.getRemoteUserNeedsAuthorization()) {
> > > > > > ...
> > > > > > } else if (!(authenticator instanceof
> > > > > AuthenticatorBase)) {
> > > > > >...
> > > > > > }
> > > > > >
> > > > > > public class SSLAuthenticator extends AuthenticatorBase {
> > > > > >
> > > > > >
> > > > > Sure but check what makes remoteUserNeedsAuthorization true (http2
> > and
> > > > ajp)
> > > > > and what does the block when true (authenticate(username), no
> > password
> > > or
> > > > > so).
> > > > > So not an issue IMHO.
> > > > >
> > > > >
> > > > > >
> > > > > > My point was if you have some security contraint (JWT, basic,
> > etc...)
> > > > on
> > > > > > > /*, then your servlet will not be called for letsencrypt call
> > > whereas
> > > > > if
> > > > > > > you have a valve you can still handle it properly since you
> > didn't
> > > > > enter
> > > > > > > the secured chain - a valve is before filter chain and can be
> > > before
> > > > > > > authenticators in valve chain since authenticators -
> > > > AuthenticatorBase
> > > > > -
> > > > > > > are valves.
> > > > > > >
> > > > > >
> > > > > > Authenticator Valve's seems to me to have a different treatment
> > than
> > > > > other
> > > > > > Valves which are accessed through Pipeline.
> > > > > >
> > > > >
> > > > > This is true since it can be obtained from the context and its call
> > can
> > > > be
> > > > > forced, but here again the question is when.
> > > > > If you check callers then it shouldn't be the case until you add
> > > another
> > > > > valve doing it and if so you can still set the LetsEncryptValve
> > before
> > > > and
> > > > > bypass it - can even be set on the host and not the context.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > In other words: no code change required in tomcat internals.
> > > > > > >
> > > > > >
> > > > > > I don't understand this yet. If the implementation would use
> > > > serverl.xml
> > > > > to
> > > > > > change StandardContextValve to something else?
> > > > > >
> > > > >
> > > > > No, change nothing, just add a valve on the host for example
> through
> > > >  > > > > className /> tag.
> > > > >
> > > > >
> > > > > >
> > > > > > I've tried to figure out what are you doing in meecrowave

Re: feature request: reload SSL certificate automatically after X days (configuration option)

Le mer. 23 déc. 2020 à 17:24, Mladen Adamović  a
écrit :

> On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau 
> wrote:
>
> > 1. Usage, typically if you run in kubernetes or any managed instance env
> > then you don't care and will restart the instance (with graceful
> shutdown)
> > when needed
> >
>
> This is outside of my scope.
>
>
> > 2. There are several tomcat instances out there using certbot (my blog
> is a
> > tomee with certbot on for example) so can also be a lack of doc/knowledge
> >
>
> That's well known before in the conversation, i.e. I'm running Tomcat with
> SSL on numbeo.com as documented here:
>
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
>
>
Was just answering your point that user complains. It works, that's a fact.
If (once hopefully) we get a tomcat-letsencrypt module we'll get issues
that it does not work for some people. This is always the case each time
you create something new so real point is can we make it better.
Being embed we can refresh when needed instead of randomly so I think we
can make it better, but it already works and it will not solve the entry
cost users have I think.


>
> > 3. I agree a built in module enables an easier deployment (just a valve
> to
> > configure with a few attributes) and everything else works OOTB but you
> > don't need any modification in tomcat distribution to do that - was my
> main
> > point, all can be done in a new module without modifying tomcat internals
> > for a particular deployment
> >
>
> But adding a Valve or a Servlet would mean modifying Tomcat internals?
>

No, it means implementing a Valve.
We don't modify tomcat internals each time we implement a servlet and it is
~the same there ;).


>
>
>
> > 4. In several cases tomcat will not have the SSL config but a frontend
> > (httpd, nginx, ...) will do it so tomcat integration will not help there
> >
>
> Those suckers ;-)
>

Joke apart, they have their usage and in such a setup one big gain is to
reduce the number of requests to let's encrypt (compared to a backend with
hundreds of instances, the front will likely just get ~10 instances) and
have a different lifecycle than the app.


>
>
>
>
> >
> > This is why, for me, a tomcat-letsencrypt module is the most relevant
> > solution.
> > If owned by Tomcat project perfect (this is the best IMHO), if not it
> will
> > still cover the same features so still good.
> >
> > Hope it makes sense.
> >
> >
> > >
> > >
> > >
> > >
> > > > Do you see anything else which would need to change? The reloadSSL
> > method
> > > > was added for letsencrypt already so guess this adjustment work is
> > > already
> > > > done.
> > >
> > >
> > > There are currently two options, through manager or through service
> > > restart. It seems that there is no consensus here to add the 3th
> option.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > >
> > > > >
> > > > > On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <
> > > > mladen.adamo...@gmail.com
> > > > > >
> > > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > > > > > rmannibu...@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I don't think so, this connector auth is only used in very
> > > > particular
> > > > > > > cases
> > > > > > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care
> much.
> > It
> > > > is
> > > > > > > also a
> > > > > > > > kind of automatic authorization - no password or so - so will
> > > pass
> > > > > and
> > > > > > > not
> > > > > > > > fail.
> > > > > > > >
> > > > > > >
> > > > > > > That sounds very strange, as I have seen in the code:
> > > > > > > if (req.getRemoteUserNeedsAuthorization()) {
> > > > > > > ...
> > > > > > > } else if (!(authenticator instanceof
> > > > > > AuthenticatorBase)) {
> > > > > > >...
> > > > > > > }
> > > > > > >
> > > > > > > public class SSLAuthenticator extends AuthenticatorBase {
> > > > > > >
> > > > > > >
> > > > > > Sure but check what makes remoteUserNeedsAuthorization true
> (http2
> > > and
> > > > > ajp)
> > > > > > and what does the block when true (authenticate(username), no
> > > password
> > > > or
> > > > > > so).
> > > > > > So not an issue IMHO.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > My point was if you have some security contraint (JWT, basic,
> > > etc...)
> > > > > on
> > > > > > > > /*, then your servlet will not be called for letsencrypt call
> > > > whereas
> > > > > > if
> > > > > > > > you have a valve you can still handle it properly since you
> > > didn't
> > > > > > enter
> > > > > > > > the secured chain - a valve is before filter chain and can be
> > > > before
> > > > > > > > authenticators in valve chain since authenticators -
> > > > > AuthenticatorBase
> > > > > > -
> > > >

Re: feature request: reload SSL certificate automatically after X days (configuration option)

2020-12-23 Thread Christopher Schultz

Mladen,

On 12/23/20 09:07, Mladen Adamović wrote:

hmmm.. at least for us, Certbot fetches acme-challenge on HTTP connector.
According to
https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
an app most likely should have a HTTP connector for Letsencrypt.

Then it really doesn't matter AFAIK, if Servet is used or a Valve for most
cases. Whatever dev thinks fits more in the nature of the system.

Romain is right: if you have configured blanket authentication
requirements for your web application, they will be applied *before* a
Servlet is invoked and Let's Encrypt doesn't generally provide
authentication to the application handling its ACME reply.

Stated more simply: if your application requests username+password, then
your application cannot be used to respond to ACME requests.

If you use a Valve, you can have the ACME-handling code execute before
the authenticator. That's how you get around the authentication "problem".

I know this can be implemented outside of Tomcat (as we have that
implementation through Servlet), I'm discussing what could be done in
Tomcat to simplify Letsencrypt integration.

Use a Valve. ;)

-chris

On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau
wrote:

Le mer. 23 déc. 2020 à 12:50, Mladen Adamović
a
écrit :

On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <

rmannibu...@gmail.com

wrote:

I don't think so, this connector auth is only used in very particular

cases

(= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is

also a

kind of automatic authorization - no password or so - so will pass and

not

fail.

That sounds very strange, as I have seen in the code:
if (req.getRemoteUserNeedsAuthorization()) {
...
} else if (!(authenticator instanceof

AuthenticatorBase)) {

...
}

public class SSLAuthenticator extends AuthenticatorBase {

Sure but check what makes remoteUserNeedsAuthorization true (http2 and ajp)
and what does the block when true (authenticate(username), no password or
so).
So not an issue IMHO.

My point was if you have some security contraint (JWT, basic, etc...) on

/*, then your servlet will not be called for letsencrypt call whereas

you have a valve you can still handle it properly since you didn't

enter

the secured chain - a valve is before filter chain and can be before
authenticators in valve chain since authenticators - AuthenticatorBase

are valves.

Authenticator Valve's seems to me to have a different treatment than

other

Valves which are accessed through Pipeline.

This is true since it can be obtained from the context and its call can be
forced, but here again the question is when.
If you check callers then it shouldn't be the case until you add another
valve doing it and if so you can still set the LetsEncryptValve before and
bypass it - can even be set on the host and not the context.

In other words: no code change required in tomcat internals.

I don't understand this yet. If the implementation would use serverl.xml

change StandardContextValve to something else?

No, change nothing, just add a valve on the host for example through tag.

I've tried to figure out what are you doing in meecrowave and my IDE
(Netbeans) shows me Usage of LetsEncryptValve [no occurrences]

Maybe use another IDE ;) (joking ;)):

https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
server.xml but it is equivalent to previous proposal ().

How this LetsEncryptValve is actually "injected" into meecrowave

Pipeline ?

Or how it is used internally?
I didn't see any Reflection code on Valves or Valve base by searching
source code.

https://www.packtpub.com/application-development/java-ee-8-high-performance

Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <

mladen.adamo...@gmail.com

a
écrit :

Thank you Romain, do you then think the place to check for ACME Valve

(if

that would the be appropriate naming) would be in
CoyoteAdapter.postParseRequest line 814
before doConnectorAuthenticationAuthorization(...) ?

On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:

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

Re: feature request: reload SSL certificate automatically after X days (configuration option)

2020-12-23 Thread Christopher Schultz

Romain,

On 12/23/20 10:43, Romain Manni-Bucau wrote:

Well there are a few points to take into account here:

> [snip]
>

2. There are several tomcat instances out there using certbot (my blog is a
tomee with certbot on for example) so can also be a lack of doc/knowledge

+1

I know this works for sure, because I worked to make sure it did. I use 
it on a reporting server that's been running under this configuration 
for months. certbot + scripts = working :) I partially built that as a 
proof-of-concept for the "Let's Encrypt Apache Tomcat" presentation I 
have done in the past. The initial version didn't have automatic reload, 
so we (markt, really) built the reloadSsl capability as a "first step" 
to something that would actually work.

Mladen, I know you are anxious to get this done but to say that nobody 
here is interested is disingenuous. We are volunteers and we have 
day-jobs, families, and holidays here and there that might interfere 
with your schedule. I'm sorry about that, but it's the truth. If you 
want Tomcat to support ACME "out of the box", we can move towards that 
but you can't have it by 09:00 on Monday.

3. I agree a built in module enables an easier deployment (just a valve to
configure with a few attributes) and everything else works OOTB but you
don't need any modification in tomcat distribution to do that - was my main
point, all can be done in a new module without modifying tomcat internals
for a particular deployment

+1 (x1000)

This can be done in a Valve. Romain has already built this as a 
ServletContextListener so it's very self-contained. I had to read it 
through several times to understand how the ACME verification step was 
being completed (the magic is that it drops a file onto the filesystem, 
which I didn't expect, honestly). If you use a Valve, you can respond 
directly without using a filesystem-based approach.

4. In several cases tomcat will not have the SSL config but a frontend
(httpd, nginx, ...) will do it so tomcat integration will not help there

This is why, for me, a tomcat-letsencrypt module is the most relevant
solution.
If owned by Tomcat project perfect (this is the best IMHO), if not it will
still cover the same features so still good.

This can be a very straightforward project if you want it to be.

If you build it as a Valve, it will require the use of some internal 
Tomcat APIs (e.g. Valve!) but it will not require that any part of 
Tomcat be modified. This is good, especially if you want your 
contribution to be accepted.

Valves also already have a timed-execution scheme that you can hook-into 
(it's the backgroundProcess() call which will be called at intervals).

Valves get a crack at every request that comes through the system. If 
you see a request to /.well-known/acme-challenge/[token] you can respond 
immediately. Otherwise, just allow the request to process normally.

It will be a lot of straightforward than Romain's code IMHO.

The big problem is a dependency on an ACME client. Tomcat is not going 
to want to have an ACME client as a built-dependency, and may not want 
to have it as a deployment dependency. Take a look at the existing 
libraries Tomcat uses. The list is *very* short, and we'd like to keep 
it that way.

If you want Tomcat to be able to handle ACME out of the box, you are 
going to have to make it somehow possible to use a plugable ACME API so 
Tomcat doesn't have to supply one (it's not exactly OOTB, then, is it?) 
or you are gong to have to package it separately, like tomcat-pool.

If you able to build this as a "simple" Valve and also without any 
third-party dependencies (which may be silly, since ACME clients should 
be trivially re-usable and re-building one in Tomcat seems like a waste 
of time), then adding a acmeSupport="true" setting in Tomcat's  
should be pretty trivial: we just have to arrange for acmeSupport="true" 
to trigger the automated installation of a Valve in the valve pipeline 
during startup. This is how the authenticators work: implemented as a 
Valve, triggered by XML configuration in WEB-INF/web.xml.

But the point is that it is modular, can be developed independently, and 
can use existing Tomcat infrastructure, code, APIs, etc. without lots of 
changes to suit your view of how things should work.

-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: feature request: reload SSL certificate automatically after X days (configuration option)

2020-12-23 Thread Christopher Schultz

Mladen,

On 12/23/20 11:24, Mladen Adamović wrote:

On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau
wrote:

1. Usage, typically if you run in kubernetes or any managed instance env
then you don't care and will restart the instance (with graceful shutdown)
when needed

This is outside of my scope.

2. There are several tomcat instances out there using certbot (my blog is a
tomee with certbot on for example) so can also be a lack of doc/knowledge

That's well known before in the conversation, i.e. I'm running Tomcat with
SSL on numbeo.com as documented here:
https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/

That guide does way more than necessary. Try reading this:
http://tomcat.apache.org/presentations.html#latest-lets-encrypt

(Again, if necessary.)

certbot + script = working

3. I agree a built in module enables an easier deployment (just a valve to
configure with a few attributes) and everything else works OOTB but you
don't need any modification in tomcat distribution to do that - was my main
point, all can be done in a new module without modifying tomcat internals
for a particular deployment

But adding a Valve or a Servlet would mean modifying Tomcat internals?

No. Writing a Valve does not change any code that ships with Tomcat.

Steps:

1. Write Valve, compile + package to JAR
2. Drop JAR in lib/ directory
3. Add to conf/server.xml

No where in there is editing of any Tomcat Java source required.

4. In several cases tomcat will not have the SSL config but a frontend
(httpd, nginx, ...) will do it so tomcat integration will not help there

Those suckers ;-)

I know you are kidding, but if you want load-balancing and fail-over,
you have to front Tomcat with *something*. And if you are fronting
Tomcat, you really should be terminating TLS there as well. At which
point, ACME-in-Tomcat is really unnecessary.

That's one of the reasons we are all a little skeptical about this: most
Tomcat installations are not one-node wonders and already have all this
other infrastructure available. So doing ACME elsewhere is simply
"easier" than doing it at the Tomcat level.

-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: feature request: reload SSL certificate automatically after X days (configuration option)

Christopher, thank you, now I think I understand better the situation. You
were right that I was anxious about this.

Let me try to summarize:
- there is a consensus that this could be implemented through a Valve
- there are two options for this to work: either with the full ACME client
or with the certbot (to note that Letsencrypt recommends users to use
certbot).
- Tomcat devs don't want additional dependencies towards a ACME client
(this one: https://github.com/shred/acme4j/blob/master/README.md has
additional dependencies), I understand this point
- Writing Tomcat's own ACME client probably shall not happen for various
reasons (i.e. not so many users as many users have legitimate reasons to
run Tomcat behind a proxy, except those 'suckers' who run it for the sole
purpose to have Letsencrypt/SSL with it).

Two options for a Valve:
- simple responding to ACME challenge (this could go into Tomcat source
code eventually)
- dependency on Java ACME client (probably would stay separate)

Regarding writing Valve, this would probably mean in any case most likely
providing a different ServletContext, right?











On Wed, Dec 23, 2020 at 7:02 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Mladen,
>
> On 12/23/20 11:24, Mladen Adamović wrote:
> > On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> 1. Usage, typically if you run in kubernetes or any managed instance env
> >> then you don't care and will restart the instance (with graceful
> shutdown)
> >> when needed
> >>
> >
> > This is outside of my scope.
> >
> >
> >> 2. There are several tomcat instances out there using certbot (my blog
> is a
> >> tomee with certbot on for example) so can also be a lack of
> doc/knowledge
> >>
> >
> > That's well known before in the conversation, i.e. I'm running Tomcat
> with
> > SSL on numbeo.com as documented here:
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
>
> That guide does way more than necessary. Try reading this:
> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
>
> (Again, if necessary.)
>
> certbot + script = working
>
> >> 3. I agree a built in module enables an easier deployment (just a valve
> to
> >> configure with a few attributes) and everything else works OOTB but you
> >> don't need any modification in tomcat distribution to do that - was my
> main
> >> point, all can be done in a new module without modifying tomcat
> internals
> >> for a particular deployment
> >
> > But adding a Valve or a Servlet would mean modifying Tomcat internals?
>
> No. Writing a Valve does not change any code that ships with Tomcat.
>
> Steps:
>
> 1. Write Valve, compile + package to JAR
> 2. Drop JAR in lib/ directory
> 3. Add  to conf/server.xml
>
> No where in there is editing of any Tomcat Java source required.
>
> >> 4. In several cases tomcat will not have the SSL config but a frontend
> >> (httpd, nginx, ...) will do it so tomcat integration will not help there
> >>
> >
> > Those suckers ;-)
>
> I know you are kidding, but if you want load-balancing and fail-over,
> you have to front Tomcat with *something*. And if you are fronting
> Tomcat, you really should be terminating TLS there as well. At which
> point, ACME-in-Tomcat is really unnecessary.
>
> That's one of the reasons we are all a little skeptical about this: most
> Tomcat installations are not one-node wonders and already have all this
> other infrastructure available. So doing ACME elsewhere is simply
> "easier" than doing it at the Tomcat level.
>
> -chris
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: feature request: reload SSL certificate automatically after X days (configuration option)

Le mer. 23 déc. 2020 à 20:39, Mladen Adamović  a
écrit :

> Christopher, thank you, now I think I understand better the situation. You
> were right that I was anxious about this.
>
> Let me try to summarize:
> - there is a consensus that this could be implemented through a Valve
> - there are two options for this to work: either with the full ACME client
> or with the certbot (to note that Letsencrypt recommends users to use
> certbot).
> - Tomcat devs don't want additional dependencies towards a ACME client
> (this one: https://github.com/shred/acme4j/blob/master/README.md has
> additional dependencies), I understand this point
> - Writing Tomcat's own ACME client probably shall not happen for various
> reasons (i.e. not so many users as many users have legitimate reasons to
> run Tomcat behind a proxy, except those 'suckers' who run it for the sole
> purpose to have Letsencrypt/SSL with it).
>

I am for it, dependency free is key as soon as you modify tomcat/lib - and
since it is  a transversal extension it will often be there.


> Two options for a Valve:
> - simple responding to ACME challenge (this could go into Tomcat source
> code eventually)
> - dependency on Java ACME client (probably would stay separate)
>
> Regarding writing Valve, this would probably mean in any case most likely
> providing a different ServletContext, right?
>

The valve does not need another context which enables to match the
letsencript challenge whatever is deployed as app.


>
>
>
>
>
>
>
>
>
>
> On Wed, Dec 23, 2020 at 7:02 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Mladen,
> >
> > On 12/23/20 11:24, Mladen Adamović wrote:
> > > On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > >> 1. Usage, typically if you run in kubernetes or any managed instance
> env
> > >> then you don't care and will restart the instance (with graceful
> > shutdown)
> > >> when needed
> > >>
> > >
> > > This is outside of my scope.
> > >
> > >
> > >> 2. There are several tomcat instances out there using certbot (my blog
> > is a
> > >> tomee with certbot on for example) so can also be a lack of
> > doc/knowledge
> > >>
> > >
> > > That's well known before in the conversation, i.e. I'm running Tomcat
> > with
> > > SSL on numbeo.com as documented here:
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> >
> > That guide does way more than necessary. Try reading this:
> > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> >
> > (Again, if necessary.)
> >
> > certbot + script = working
> >
> > >> 3. I agree a built in module enables an easier deployment (just a
> valve
> > to
> > >> configure with a few attributes) and everything else works OOTB but
> you
> > >> don't need any modification in tomcat distribution to do that - was my
> > main
> > >> point, all can be done in a new module without modifying tomcat
> > internals
> > >> for a particular deployment
> > >
> > > But adding a Valve or a Servlet would mean modifying Tomcat internals?
> >
> > No. Writing a Valve does not change any code that ships with Tomcat.
> >
> > Steps:
> >
> > 1. Write Valve, compile + package to JAR
> > 2. Drop JAR in lib/ directory
> > 3. Add  to conf/server.xml
> >
> > No where in there is editing of any Tomcat Java source required.
> >
> > >> 4. In several cases tomcat will not have the SSL config but a frontend
> > >> (httpd, nginx, ...) will do it so tomcat integration will not help
> there
> > >>
> > >
> > > Those suckers ;-)
> >
> > I know you are kidding, but if you want load-balancing and fail-over,
> > you have to front Tomcat with *something*. And if you are fronting
> > Tomcat, you really should be terminating TLS there as well. At which
> > point, ACME-in-Tomcat is really unnecessary.
> >
> > That's one of the reasons we are all a little skeptical about this: most
> > Tomcat installations are not one-node wonders and already have all this
> > other infrastructure available. So doing ACME elsewhere is simply
> > "easier" than doing it at the Tomcat level.
> >
> > -chris
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>

Re: feature request: reload SSL certificate automatically after X days (configuration option)

On Wed, Dec 23, 2020 at 9:13 PM Romain Manni-Bucau 
wrote:

> I am for it, dependency free is key as soon as you modify tomcat/lib - and
> since it is  a transversal extension it will often be there.
>

Aha, you are for writing Tomcat specific ACME library without dependencies.
First, I have never used Tomcat without Tomcat Native in production. I
don't know if Tomcat without Native is currently feasible in production for
SSL connector (what is the performance overhead?)
I will try tomorrow to see on removing jose4j and bouncycastle dependencies
from acme4j.

> Regarding writing Valve, this would probably mean in any case most likely
> > providing a different ServletContext, right?
>
> The valve does not need another context which enables to match the
> letsencript challenge whatever is deployed as app.
>

I don't understand this from the code. Pipeline has its order so it's
important that this Valve is put in the right position?
On Host level, Netbeans didn't show me how setConfigClass is used.
I think I should take a rest and tomorrow install IntelliJ and Eclipse as
it seems Netbeans not working for Tomcat source for me properly.



>
> > On Wed, Dec 23, 2020 at 7:02 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > > Mladen,
> > >
> > > On 12/23/20 11:24, Mladen Adamović wrote:
> > > > On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > >> 1. Usage, typically if you run in kubernetes or any managed instance
> > env
> > > >> then you don't care and will restart the instance (with graceful
> > > shutdown)
> > > >> when needed
> > > >>
> > > >
> > > > This is outside of my scope.
> > > >
> > > >
> > > >> 2. There are several tomcat instances out there using certbot (my
> blog
> > > is a
> > > >> tomee with certbot on for example) so can also be a lack of
> > > doc/knowledge
> > > >>
> > > >
> > > > That's well known before in the conversation, i.e. I'm running Tomcat
> > > with
> > > > SSL on numbeo.com as documented here:
> > > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > >
> > > That guide does way more than necessary. Try reading this:
> > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > >
> > > (Again, if necessary.)
> > >
> > > certbot + script = working
> > >
> > > >> 3. I agree a built in module enables an easier deployment (just a
> > valve
> > > to
> > > >> configure with a few attributes) and everything else works OOTB but
> > you
> > > >> don't need any modification in tomcat distribution to do that - was
> my
> > > main
> > > >> point, all can be done in a new module without modifying tomcat
> > > internals
> > > >> for a particular deployment
> > > >
> > > > But adding a Valve or a Servlet would mean modifying Tomcat
> internals?
> > >
> > > No. Writing a Valve does not change any code that ships with Tomcat.
> > >
> > > Steps:
> > >
> > > 1. Write Valve, compile + package to JAR
> > > 2. Drop JAR in lib/ directory
> > > 3. Add  to conf/server.xml
> > >
> > > No where in there is editing of any Tomcat Java source required.
> > >
> > > >> 4. In several cases tomcat will not have the SSL config but a
> frontend
> > > >> (httpd, nginx, ...) will do it so tomcat integration will not help
> > there
> > > >>
> > > >
> > > > Those suckers ;-)
> > >
> > > I know you are kidding, but if you want load-balancing and fail-over,
> > > you have to front Tomcat with *something*. And if you are fronting
> > > Tomcat, you really should be terminating TLS there as well. At which
> > > point, ACME-in-Tomcat is really unnecessary.
> > >
> > > That's one of the reasons we are all a little skeptical about this:
> most
> > > Tomcat installations are not one-node wonders and already have all this
> > > other infrastructure available. So doing ACME elsewhere is simply
> > > "easier" than doing it at the Tomcat level.
> > >
> > > -chris
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > >
> > >
> >
>

[GitHub] [tomcat] michael-o commented on pull request #382: Add support for unix domain sockets.



michael-o commented on pull request #382:
URL: https://github.com/apache/tomcat/pull/382#issuecomment-750490202


   > 
   > 
   > It can 100% work with APR, except I personally don't want to add features 
to that component at this point.
   
   If you personally don't want to, @minfrin happily will.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: feature request: reload SSL certificate automatically after X days (configuration option)