#1b - Same as the previous #1, we don’t enable TLS for management by default for now, but we additionally include an extra cli script to enable TLS.
For 11 I think we should move to TLS by default, perhaps with a configurable URL policy on redirects, and address the incongruence with upgrade over app.
I think its likely reasonable to redirect by default for 11, but we can hash that out further. One nice thing I had forgotten about is that the JDK will prompt for you to add unknown certs, and this all works with the CLI. So it’s really only non-interactive clients we have to worry about, and that sounds like a reasonable burden for upgrade.
[disconnected /] connect
Unable to connect due to unrecognised server certificate
Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US
Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US
Valid From - Tue Jun 07 15:22:06 CDT 2016
Valid To - Thu Jun 07 15:22:06 CDT 2018
MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d
SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b
Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t
Long term I think we want management using TLS, but that can of course come in phases. Assuming 2) is one of those phases to come (either now or later), a following step is that the CLI, and really any remoting client, should prefer TLS with a defaulted trust store location that points to the keystore.
With 2) if we have the default of the attribute that forces redirect be true, and our default config be false, then someone that carries over their old config would not have a potential security weakness. If they have a CLI script that adds the https port, it will fail, hopefully sending a signal to look. Although, the user might just assume that oh it's there, I don't have to do anything.
Another interesting thing about 2 is that IIRC we have conflicting behavior between the app port which doesn't force upgrade and the management port which does.
So my preference is 2, because at some point we have to do it anyway, and if we have TLS out of the box might as well use it.
So while implementing this I have noticed a potential problem that it would be good to get some feedback on.
If the management interface has SSL by default then the HTTP interface will always redirect to the HTTPS interface. This effectively breaks the management API, as clients such as the CLI, Arquillian etc will be redirected to HTTPS, and then reject the self signed certificate (as they should).
I am not sure what to do about this, these are the options as I see them:
1) Don't enable SSL for the management interface (just for the Undertow subsystem). The management interface can still use this auto-generation capability, it just won't be enable by default (we could even leave the cert in the security domain, but just not enable the https interface).
2) Disable automatic redirects for HTTP upgrade requests (potentially controlled by an attribute). This will allow the CLI etc to work, but at the price of potentially reducing security, as some connections that would have previously been redirected to use HTTPS will no longer do this.
3) Enable it by default and leave it broken. We can setup some kind of automatic trust store thing so the local CLI works, and can get our test suite to work with Arquillian in a similar manner. Personally I think this is a terrible idea, but I am including it for completeness.
Personally I think we should go for 1). Given that this is supposed to be about developer usability I don't think having management also use SSL as being that important.
wildfly-dev mailing firstname.lastname@example.org
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat