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]
