[
https://issues.apache.org/jira/browse/ARTEMIS-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599724#comment-17599724
]
Aaron Steigerwald commented on ARTEMIS-3968:
--------------------------------------------
Yes, that solves the problem from a certificate perspective. However, the goal
of this Jira issue was to provide a means to disable SNI host checking without
having to modify the certificate or introduce DNS values that will not be there
in production.
> Optionally disable Management UI HTTPS SNI host checking
> --------------------------------------------------------
>
> Key: ARTEMIS-3968
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3968
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
> Affects Versions: 2.24.0
> Reporter: Aaron Steigerwald
> Priority: Major
>
> The Management UI, when configured to run in HTTPS mode, returns "HTTP ERROR
> 400 Invalid SNI" to the client browser if the web server's certificate
> (defined in the {{bootstrap.xml}} file's web element's {{keyStorePath}}
> attribute) does not contain the server's DNS name. It also prevents the
> browser from using "https://localhost...";. This makes running the broker in a
> dev and test environment difficult. A work around is to run it in HTTP mode
> but this prevents exercising the HTTPS parameters and certificates.
> I think the upgrade from Jetty 9.x to 10.x caused SNI host checking to be
> enabled by default or at least more strictly enforced.
> I disabled SNI host checking by modifying
> {{org.apache.activemq.artemis.component.WebServerComponent}} in the following
> way:
> Current 2.24.0 version:
> {code:java}
> httpConfiguration.addCustomizer(new SecureRequestCustomizer());{code}
> Modified 2.24.0 version to disable SNI host checking:
> {code:java}
> SecureRequestCustomizer secureRequestCustomizer = new
> SecureRequestCustomizer();
> secureRequestCustomizer.setSniHostCheck(false);
> httpConfiguration.addCustomizer(secureRequestCustomizer);{code}
> Adding another binding attribute to the {{bootstrap.xml}} file's web element,
> like "disableSniHostCheck", and using it to set
> "secureRequestCustomizer.setSniHostCheck(false)" would allow a configurable
> way to disable SNI host checking.
> -----
> The following is provided for reference:
> Server Name Indication (SNI)
> https://stackoverflow.com/questions/69945173/http-error-400-invalid-sni-jetty-https-servlet
> Search for "jetty.ssl.sniHostCheck" in
> https://www.eclipse.org/jetty/documentation/jetty-10/operations-guide/index.html
> {{artemis.log}} entries:
> {noformat}
> 2022-08-31 21:35:39,512 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /console org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI
> 2022-08-31 21:35:39,560 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /favicon.ico org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI{noformat}
> Browser message when trying to access https://localhost:8163/console with SNI
> host checking enabled and a certificate with a DNS entry that does not match
> the server:
> {noformat}
> HTTP ERROR 400 Invalid SNI
> URI: /console
> STATUS: 400
> MESSAGE: Invalid SNI
> SERVLET: -
> CAUSED BY: org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> Caused by:
> org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> at
> org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:266)
> at
> org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:207)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$0(HttpChannel.java:501)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:762)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:497)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:282)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:319)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
> at
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:558)
> at
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:379)
> at
> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:146)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
> at
> org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:412)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:381)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:268)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.lambda$new$0(AdaptiveExecutionStrategy.java:138)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:407)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:894)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1038)
> at java.base/java.lang.Thread.run(Thread.java:829){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
