-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Daniel,
On 9/11/20 17:06, Daniel Skiles wrote: > I've gotten my _default_ SNI SSLHostConfig working. Thank you for > the help. Excellent. >> 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 probably 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. Did you try it? - -chris > 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: >> > 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/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9fayEACgkQHPApP6U8 pFhHmw/+PcFaM5gnubHhY923ZRUNZQ4XUdBBn4SvPbEa4R2vKUrKEAXmcuLweZFb v2WMNi/IpOp/BldPOlaX9MBNAoImcm3Ku3yuTdN+LsXk0PhGTFb3jYToQ6LtlXnw emkyp210tQ1kjt4z5pRMgeLwmdlvET1qO79L4QNiyGSe0zUetfNuwjZmsyMeDsOg VwIaYvhrIi+ofuz2da+YOTyKpQBl2/+WNaJEQx/NdWZlf93Np0konOg3ScoYPVah Y6tg/GfXksGOWi0m4eGAjcaKVh6nQGlU9qltGY6B9uj+wMFlsZ05zZ070WRUO78b c8L0Tq59JqtDD/6DI2a5NBhbW8SAx26i4MFUrwJUKCnGBx75uXQzxO8I4E9ALhxO vUdlbLUndJCFfyXTOdLYLC9TLaQCFapmAdIZYQP0s9U2uruOdtwZboCqxHTR/Xx8 lq2TOgDyXNtU+Jo1h3a18oABXm7gKEi4OQPpzdao4cQNn3kUjkNyQR4PLIdJmgOj H9d8L4YIx277qEyUUwmiJ+ZAJF4vUyJzqOEWRJ4yP94GeLrdEcTzXHshkDyjmfJn 4tiYB030lklo0GIM490kiMnpaOORVBOSehSGr/dKCOs4vZErxQ23oPjHMUG/owcm QV3Lmyw8R3dnZ81NTjfIuE93XHBmIV4auWDNhNQI4BHV1kDZDoo= =6lLd -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
