I've gotten my _default_ SNI SSLHostConfig working. Thank you for the help.
> Perhaps that method could have a better name, like reinitializeSSLHostConfigs. "reload" implies that it re-reads the server.xml which is not the case. At least the documentation should probabyl be better. If the server.xml isn't actually read during the reloadSslHostConfigs operation, is there a way to add an SSLHostConfig at runtime? I see addSslHostConfig on ProtocolHandler, but I'm not certain that it will do what I think it will do. On Fri, Sep 11, 2020 at 9:52 AM Daniel Skiles <dski...@docfinity.com> wrote: > > In your case, where did you rediscover reloadSslHostConfigs? > > To be honest, I wandered around in the JMX console until I found something > that looked promising. > > > You'll want to "set" the value of the attribute "certificateKeyAlias". > > Thank you for your help. I'll give that a try. > > On Fri, Sep 11, 2020 at 9:44 AM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Daniel, >> >> On 9/10/20 16:39, Daniel Skiles wrote: >> >> Also note that calling reloadSslHostConfigs does NOT re-read >> >> server.xml. It re-initializes the existing in-memory >> >> configuration. If you want to e.g. change the key alias, you'll >> >> have to make a JMX call to update the alias and THEN call >> >> reloadSslHostConfigs.> >> > *THAT *is probably my problem. >> >> Perhaps that method could have a better name, like >> reinitializeSSLHostConfigs. "reload" implies that it re-reads the >> server.xml which is not the case. At least the documentation should >> probabyl be better. >> >> In your case, where did you rediscover reloadSslHostConfigs? >> >> > Do you know which MBean and operation that is? >> >> It's this (you'll have to interpolate a bit of this to fir your >> environment): >> >> Catalina:type=SSLHostConfigCertificate,ThreadPool="https-[cryptoimpl]-[i >> oimpl]-[addr]-[port]",Host="[host]",name=[cert-type] >> >> My test one was: >> Catalina:type=SSLHostConfigCertificate,ThreadPool="https-jsse-nio-127.0. >> 0.1-12345",Host="_default_",name=EC >> >> Attach to Tomcat using VisualVM or your JMX browser of choice and have >> a look at what's there. You'll want to "set" the value of the >> attribute "certificateKeyAlias", then call reloadSslHostConfigs. >> >> - -chris >> >> > On Thu, Sep 10, 2020 at 4:00 PM Christopher Schultz < >> > ch...@christopherschultz.net> wrote: >> > >> > Daniel, >> > >> > On 9/10/20 13:33, Daniel Skiles wrote: >> >>>> In this case, I didn't remove every certificate, but I did >> >>>> remove the certificate that was originally being referenced >> >>>> after adding a new certificate under a new alias. >> >>>> >> >>>> Original Keystore: Alias A Server.xml _default_ >> >>>> SSLHostConfig points to Alias A >> >>>> >> >>>> After Modification: Alias B Server.xml _default_ >> >>>> SSLHostConfig points to Alias B >> >>>> >> >>>> <Call reloadSslHostConfigs here> <Receive error> >> >>>> >> >>>> If that's not supported, I'll see if I can keep the aliases >> >>>> stable somehow. If there is a way to do it, I'd be >> >>>> interested in hearing >> > what it >> >>>> is. >> > >> > What are the real alias names? If you don't specify the key alias, >> > Tomcat will use the first private key it finds in the file (which >> > is essentially random, as Java keystores do not guarantee any kind >> > of read-ordering). >> > >> > What does your <Certificate> look like in server.xml? >> > >> > Can you also post the actual error and complete stack trace you >> > get? >> > >> > If you change the key's alias, you'll need to change the alias >> > listed in the <Certificate> unless you are using the default >> > first-key behavior . >> > >> > Also note that calling reloadSslHostConfigs does NOT re-read >> > server.xml. It re-initializes the existing in-memory configuration. >> > If you want to e.g. change the key alias, you'll have to make a JMX >> > call to update the alias and THEN call reloadSslHostConfigs. >> > >> > -chris >> > >> >>>> On Thu, Sep 10, 2020 at 11:34 AM Christopher Schultz < >> >>>> ch...@christopherschultz.net> wrote: >> >>>> >> >>>> Daniel, >> >>>> >> >>>> On 9/10/20 09:09, Daniel Skiles wrote: >> >>>>>>> Is it possible to change the keystore alias of the >> >>>>>>> _default_ SSLHostConfig's certificate while tomcat is >> >>>>>>> running? >> >>>>>>> >> >>>>>>> At present, I'm trying to move the _default_ >> >>>>>>> certificate from one certificate in my keystore, to >> >>>>>>> another. I modify the server.xml, then I call the >> >>>>>>> reloadSslHostConfigs MBean operation. The operation >> >>>>>>> throws an error that boils down to a >> >>>>>>> jsse.alias_no_key_entry error that comes back from the >> >>>>>>> JVM. >> >>>>>>> >> >>>>>>> Is this a technical limitation on SNI/SSLHostConfig, or >> >>>>>>> am I missing something here? >> >>>> >> >>>> Did you remove all server certificates from your keystore and >> >>>> then try to bounce the connector? That's not going to work >> >>>> because the connector requires a server key and certificate. >> >>>> >> >>>> Instead of "moving" the cert, consider copying the >> >>>> certificate instead. >> >>>> >> >>>> -chris >> >>>>> >> >>>>> ------------------------------------------------------------------ >> - --- >> >>>>> >> >>>>> >> > >> >>>>> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> >>>>> For additional commands, e-mail: >> >>>>> users-h...@tomcat.apache.org >> >>>>> >> >>>>> >> >>>> >> >> >> > >> -----BEGIN PGP SIGNATURE----- >> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ >> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9bfz0ACgkQHPApP6U8 >> pFje3BAAkkX+/VQU+RA2s5OxiOYDSvOe1ewDsRj3VeXoRHr1aDbEp7PxNVVnmF1s >> /d/pHFOScrVksGy/hR3nbTZ7kk8NcXNsD2Vi0+YDejv9UuEB6GQw8ppjVMkPx6ei >> QjQYg+CQxybBbIeo5JlCIQy6I3+bRra3VJYrFzglRvKvl5/IxRIx4w1K35vyUcaq >> iyH7VynAP8O4VgV42ntJ+2gIq8Q+AE/2lEMKczK2ZblwbklJc+EYUZRRiuUIXHtH >> 0YoQWKa7914OJK/dR7ZdQWtj4JQX4djvnSXd055eeASNe6BPlXDkM4jNTcas64BA >> zqSZAv+SZIC/ttHL3t0dedmcbQ5T1ALV4cr9L2cWvInnCz76MB9qUd94PRehEOzm >> VCI9A/e2jN+6wCUy00jixBBgOEbj1s3NQSxgO+uP21QYhLPf0AoAgbNXLMKMvLmg >> 1TwOU3mXdxPq7KPR4aFIIvzpgWWo2SeY2uzjjwVVkjYq0psVAMFFM/cgfkmkF8Mk >> q7Q8p3um7q1K086/+MnhKI4254Z9O8zKuYAVdVmODrtlPAdikUQ58DqHd3Ug2sQZ >> aQcpgxTXUWqvSgr/mqAfQCDKhW5aJH/wmnaKse6p2uRjOOujMSg7S1x+KrPK4IMN >> Uj4+TRUDGGYM4o/izTTwEGCj2AnpoigyZTtr3fszDKN7f3Gs9oc= >> =U1rB >> -----END PGP SIGNATURE----- >> >