Am 2020-10-15 um 17:34 schrieb Christopher Schultz:
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 asyncI
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 throwingan
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.
Exactly!
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*.
Worse than that, I does not even tell for what certificate key it
expects one..
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
