Maartin, On 10/14/20 09:07, Maarten van den Broek wrote: > Op 14-10-2020 om 14:10 schreef Rémy Maucherat: >> On Wed, Oct 14, 2020 at 11:38 AM Maarten van den Broek < >> mbr...@messagedesign.nl> wrote: >> >>> I use tomcat 9.0.33 with windows10 home and amazon corretto >>> jdk1.8.0_212. >>> >>> Below a snapshot of two different Connector definitions in server.xml >>> >>> <Connector port="443" connectionTimeout="20000" acceptCount="100" >>> maxThreads="150" SSLEnabled="true" scheme="https" >>> secure="true" >>> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol" >>> >>> clientAuth="false" sslEnabledProtocols="TLSv1.2" >>> minSpareThreads="5" >>> enableLookups="true" disableUploadTimeout="true" >>> keystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks" >>> keystorePass="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3" >>> /> >>> >>> <Connector acceptCount="100" connectionTimeout="20000" >>> disableUploadTimeout="true" enableLookups="true" maxThreads="150" >>> minSpareThreads="5" port="443" >>> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol" >>> >>> SSLEnabled="true" scheme="https" secure="true"> >>> <SSLHostConfig protocols="TLSv1.2"> >>> <Certificate >>> certificateKeystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks" >>> >>> >>> certificateKeystorePassword="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3" >>> certificateKeystoreType="JKS"/> >>> </SSLHostConfig> >>> </Connector> >>> >>> Using the first Connector everything is working fine. Debugging the >>> setKeystorePass method of the class >>> nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol in the >>> protocol attribute shows that the encrypted password gets decrypted. >>> >>> Using the second connector with the SSLHostConfig element instead of the >>> deprecated attributes debugging shows that the setKeystorePass method is >>> not called and I get errors for the incorrect password of the keystore. >>> >>> What am I doing wrong in migrating to the configuration with the >>> SSLHostConfig element? >>> >>> Sincerely yours, Maarten van den Broek >>> >> If you simply want to obfuscate server.xml attributes, you should look >> into >> the digester property sources instead of engaging in this sort of stuff. >> One such property source out there: >> https://github.com/web-servers/tomcat-vault >> >> Note: This capability is not included directly into Tomcat itself because >> it provides no actual extra security. >> >> Rémy > > Dear Rémy, > > Thank you for your swift response. > > Customers are happy with this solution because they only need to provide > these passwords during the first installation and it can be done by the > owner of the certificate. The key for the en/decryption is in a keystore > with a password, that can only be obtained by debugging the code.
So you have the password for the keystore hard-coded into your Java code? Doesn't that mean it's in revision-control? > In a production environment this is in most cases impossible. This > mechanism is also used to encrypt columns in the database and it is > easy to reuse for the encryption of the keystore passwords. I prefer > this over the use of a tomcat vault, because there is increased > complexity installing tomcat. Alas, it may break with major releases > and then you have to fix it again, but with your swift help it is no > problem. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
