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

Reply via email to