On 05/23/2013 08:27 AM, Dieter Bloms wrote:
> Hi,
>
> I use squid 3.3.5 with the ssl-bump feature.
> My private key is crypted and I want to enter the password at start time.
>
> Since 3.3.5 squid wants to execute a program even I haven't configured
> sslpassword_program and start squid with the -N option.
>
> --snip--
> idvhttpsproxy01:~ # squid -f /etc/squid/squid.conf -NY
> sh: (null): command not found
> FATAL: No valid signing SSL certificate configured for http_port MYIP:8080
> Squid Cache (Version 3.3.5): Terminated abnormally.
> CPU Usage: 0.004 seconds = 0.000 user + 0.004 sys
> Maximum Resident Size: 21248 KB
> Page faults with physical i/o: 0
> --snip--
>
> when I set sslpassword_program to a program which print the password on
> stdout squid starts, but I want to enter the password during start of
> squid.
>
> Is this a bug ?
Yes, I think it is. Please check whether the attached patch works when
you start Squid with -N and _without_ sslpassword_program.
The patch may or may not work when you start Squid without -N and with
sslpassword_program. The outcome depends on whether snprintf() crashes
when given a NULL pointer and on whether your sslpassword_program needs
to know the name of the key file Squid is trying to load (that name will
not be passed to your sslpassword_program). If you can test this
scenario, please do.
Please let us know what your tests show.
The patch is against trunk and is untested beyond compilation. It should
apply to v3.3 as well.
HTH,
Alex.
Ask for SSL key password when started with -N but without sslpassword_program.
Do not give SSL password-asking callback if sslpassword_program is not
configured. OpenSSL should ask for the password itself then (which should
work if Squid runs in foreground because of -N).
The fix applies to Ssl::readCertChainAndPrivateKeyFromFiles() context only.
This is not the only place where we read private keys. Some other places are
working correctly, but others may need more work. Also,
Ssl::readCertChainAndPrivateKeyFromFiles() may not really work if
sslpassword_program _is_ configured because it will lack "user data" to record
the password in. This change is for the better, but a complete fix needs
investigation/testing and possibly more work.
=== modified file 'src/ssl/support.cc'
--- src/ssl/support.cc 2013-05-14 17:15:02 +0000
+++ src/ssl/support.cc 2013-05-23 20:22:42 +0000
@@ -1545,41 +1545,44 @@
}
}
return certificate;
}
void Ssl::readCertChainAndPrivateKeyFromFiles(X509_Pointer & cert, EVP_PKEY_Pointer & pkey, X509_STACK_Pointer & chain, char const * certFilename, char const * keyFilename)
{
if (keyFilename == NULL)
keyFilename = certFilename;
if (certFilename == NULL)
certFilename = keyFilename;
debugs(83, DBG_IMPORTANT, "Using certificate in " << certFilename);
if (!chain)
chain.reset(sk_X509_new_null());
if (!chain)
debugs(83, DBG_IMPORTANT, "WARNING: unable to allocate memory for cert chain");
- pkey.reset(readSslPrivateKey(keyFilename, ssl_ask_password_cb));
+ // XXX: ssl_ask_password_cb needs SSL_CTX_set_default_passwd_cb_userdata()
+ // so this may not fully work iff Config.Program.ssl_password is set.
+ pem_password_cb *cb = ::Config.Program.ssl_password ? &ssl_ask_password_cb : NULL;
+ pkey.reset(readSslPrivateKey(keyFilename, cb));
cert.reset(readSslX509CertificatesChain(certFilename, chain.get()));
if (!pkey || !cert || !X509_check_private_key(cert.get(), pkey.get())) {
pkey.reset(NULL);
cert.reset(NULL);
}
}
bool Ssl::generateUntrustedCert(X509_Pointer &untrustedCert, EVP_PKEY_Pointer &untrustedPkey, X509_Pointer const &cert, EVP_PKEY_Pointer const & pkey)
{
// Generate the self-signed certificate, using a hard-coded subject prefix
Ssl::CertificateProperties certProperties;
if (const char *cn = CommonHostName(cert.get())) {
certProperties.commonName = "Not trusted by \"";
certProperties.commonName += cn;
certProperties.commonName += "\"";
} else if (const char *org = getOrganization(cert.get())) {
certProperties.commonName = "Not trusted by \"";
certProperties.commonName += org;
certProperties.commonName += "\"";
} else
