On Mon, Oct 19, 2026 at 2:37 PM von Wittich, Christoph < [email protected]> wrote:
> >PR: https://github.com/apache/tomcat/pull/1089 > I would also prefer to ignore all incompatible (EKU) and outdated > certificates. > > > ><Certificate certificateKeystoreType="Windows-MY-LOCALMACHINE" > > certificateKeyAlias="{CN}" > > Is there some kind of hostname variable? Or does certificateKeyAlias > defaults tot he hostname when it is empty for Windows keystores? > There is no built in hostname variable. certificateKeyAlias does not default to the hostname; citing the docs <https://tomcat.apache.org/tomcat-11.0-doc/config/http.html>: If not specified, the first key read from the keystore will be used. The order in which keys are read from the keystore is implementation dependent. It may not be the case that keys are read from the keystore in the same order as they were added. > Would be nice to have a default config I could just deploy to all hosts in > a cluster without any host specific customizations. > > > Christoph > > > -----Ursprüngliche Nachricht----- > Von: David Wooffindin <[email protected]> > Gesendet: Sonntag, 18. Oktober 2026 00:15 > An: Tomcat Users List <[email protected]> > Cc: Tomcat Developers List <[email protected]>; von Wittich, > Christoph <[email protected]> > Betreff: Re: certificates from windows cert store with autoenrollment from > AD CS > > ⚠ Externe E-Mail: Diese Nachricht stammt von außerhalb der Organisation. > Klicken Sie nicht auf Links und öffnen Sie keine Anhänge, es sei denn, Sie > kennen den Absender und wissen, dass der Inhalt sicher ist. Wenn Sie > unsicher sind, kontaktieren Sie uns bitte unter [email protected]<mailto: > [email protected]?subject=Pr%C3%BCfung%20einer%20externen%20E-Mail> > > Sent from Proton Mail for iOS. > > -------- Original Message -------- > On Friday, 10/16/26 at 21:11 Dimitris Soumis <[email protected]> wrote: > On Fri, Oct 16, 2026 at 1:22 PM Christopher Schultz < > [email protected]> wrote: > > > Christoph, > > > > On 10/15/26 4:06 PM, von Wittich, Christoph wrote: > > > I would like to use certificates from windows cert store with > > autoenrollment from AD CS to automate certifcate deployment. > > > > > > > > > > > > > > > > > > Tomcat 11 > > > > > > JRE 25 > > > > > > Windows Server 2025 > > > > > > > > > > > > Snippet from server.xml {CN} is the server hostname which matches > the > > CN of the certificate > > > > > > > > > > > > <SSLHostConfig> > > > > > > <Certificate certificateKeystoreFile="" > > > > > > certificateKeystorePassword="" > > > > > > > > certificateKeystoreType="Windows-MY-LOCALMACHINE" > > > > > > > > certificateKeyAlias="{CN}" > > > > > > > > protocols="TLSv1.2,TLSv1.3" > > > > > > > > /> > > > > > > </SSLHostConfig> > > > > > > > > > > > > > > > > > > I gave "Local Service" read access to the certifcate in the windows > > > cert > > store. > > > > > > I do not want to set the displayname of the certifcate as I cannot > > > set > > it with autoenrollment from the template. > > > > > > > > > > > > In most cases this configuation works fine - at least as long as > > > there > > is just one certificate with the CN. But as I have another cert for > > "Remote Desktop Authentication" on the machines, sometimes I tried to > > load the wrong one which fails because the user does not have > > permission to read the key and the key usage does not match. > > > > > > > > > > > > Why does it try to load the wrong cert? It should check for the > > > correct > > key usage (Server Auth) instead of just trying to get the first cert > > with the correct alias (here CN). > > > > > > I am not sure if this has to be fixed in tomcat or in jdk... > > This sounds like a bit of an unusual use case (multiple certs with the > > same DN but completely different applications), but my sense is that > > it > > *should* be supported. > > > > (I have a long-standing annoyance from stunnel where you cannot have > > two trusted certificates with the same DN: stunnel will only choose > > one of them, ever, which makes certificate re-issuance impossible with > > any overlap between the two trusted certificates.) > > > > Would you mind enabling debug (or trace if necessary) logging and > > capturing a failed authentication exercise, here? It's possible that > > Tomcat should simply ignore an initial failure and continue with > > additional possibilities for cert+key, only failing if *none* are > > successful. > > > > -chris > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > Tomcat selects the certificate solely by alias and doesn't check key usage. > Since the certificates share the same CN, they collide on the same alias. > Tomcat picks the first match, so it occasionally selects the wrong > certificate. > > I have added a new JSSE attribute, `certificateSelectByKeyUsage`. When > enabled, Tomcat picks a certificate valid for TLS server authentication > among those sharing the alias' Subject. > > <Certificate certificateKeystoreType="Windows-MY-LOCALMACHINE" > certificateKeyAlias="{CN}" > certificateSelectByKeyUsage="true" /> > > PR: https://github.com/apache/tomcat/pull/1089 > > Regards, > Dimitris > > > part of it can be automated with the right settings, but part of it is > also dependent on your internal certificate, authority, policy management, > and general health. > You can have group policy to renew and supply a new certificate every two > years or one year or six months or three months but you also need to have > some sort of policy that will clean up the old certificate from the Windows > certificate store that each endpoint has. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
