Michael, On 10/15/20 08:12, Michael Osipov wrote: >> Michael, >> >> On 10/14/20 12:46, Michael Osipov wrote: >>> Folks, >>> >>> I have recently upgrade a cert and left out the last char of the key >>> password by accident. >>> >>>> # /sbin/init.d/tomcat-smartld start >>>> Starting Apache Tomcat 8.5... >>>> Using CATALINA_BASE: /var/opt/tomcat-smartld >>>> Using CATALINA_HOME: /opt/ports/apache-tomcat-8.5.57 >>>> Using CATALINA_TMPDIR: /var/opt/tomcat-smartld/temp >>>> Using JRE_HOME: /opt/java8 >>>> Using CLASSPATH: >>>> /opt/ports/apache-tomcat-8.5.57/bin/bootstrap.jar:/opt/ports/apache-tomcat-8.5.57/bin/tomcat-juli.jar >>>> >>>> Tomcat started. >>>> Apache Tomcat 8.5 started. >>>> # Some of your private key files are encrypted for security reasons. >>>> In order to read them you have to provide the pass phrases. >>>> Enter password : >>>> >>> >>> I have seen similar with HTTPd in the past. Since the start is async I >>> have no option to react on that and it will block the entire config. I >>> looked briefly in the OpenSSL API, but wasn't really able to find a flag >>> to inhibit the interactive prompt. >>> >>> Does someone know whether we can make this better with libtcnative? >> >> What kind of behavior were you hoping for? I'm assuming that some kind >> of exception would be best for this case (incorrect password). > > Correct. As long as stdin is is not attached to a tty, this must be > non-interactive. > >> Suppressing the interactive prompt is likely to simply cause the >> connector to fail to initialize; basically the same thing as throwing an >> exception in the above case. > > Correct. > >> I searched the Tomcat code and I don't see that sting anywhere, so I >> suspect it's coming directly from OpenSSL (which is very weird IMHO). > > It comes from us (tomcat-native/native/include/ssl_private.h): >> #define SSL_DEFAULT_PASS_PROMPT "Some of your private key files are >> encrypted for security reasons.\n" \ >> "In order to read them you have to provide >> the pass phrases.\n" \ >> "Enter password :"
*facepalm* I was only looking at the Java code. > Used by us in SSL_password_prompt() called by SSL_password_callback(). > I haven't yet found out which object is called to obtain the password. It seems reasonable that when we *know* that we are supplying a password, we should install a null-callback for that and let OpenSSL's engine fail to initialize. >> mod_ssl has a configurable way to gather this passphrase, presumably to >> pass it into OpenSSL's read-key function. It would surprise me greatly >> if an incorrect passphrase would cause the same kind of prompt in httpd. > > It does when your don't provide a method how you will supply the password. > See SSLPassPhraseDialog builtin in >> ./modules/ssl/ssl_engine_config.c ./modules/ssl/ssl_engine_pphrase.c > > See also Javadoc of SSLContext#setCertificate(long, String, String, String, > int) > >> What version of OpenSSL are you using? Have you tried any other versions? > > I am on >> # openssl version >> OpenSSL 1.1.1d 10 Sep 2019 > > supplied by HPE on HP-UX. > > A change in OpenSSL version won't make a difference because this is how it is > configured from tcnative for now. +1 > I will file an issue to track this, especially because it is not documented > compared to SSLPassPhraseDialog. +1 I didn't even know that tcnative would prompt for a password, *ever*. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
