Sander Temme wrote:
On Nov 30, 2010, at 8:37 PM, J.Lance Wilkinson wrote:But my httpd log files present an unexpected error each and every time a browser visits an SSL encrypted page (2 examples cited):So there is no discernible negative impact on the client?
Correct. At the moment, the only negative impact is the considerably larger error log files being generated. Furthermore, watching the error log with tail -f, I can say that the errors are NOT being thrown EVERY time a browser visits an SSL encrypted page.
User interface error unable to load Private Key 22439:error:0906A068:PEMroutines:PEM_do_header:bad password read:/on10/build-nd/G10U10B0B/usr/src/common/openssl/crypto/pem/pem_lib.c:401:
The errors seem to be thrown, however, when visiting a [previously authenticated] directory/resource protected by the single signon module mod_cosign (http://weblogin.org).
Any idea what these might be?It's hard to guess what's going on here without a backtrace. A cursory glance at the OpenSSL source suggests that things FAIL when this error is triggered, so successful SSL connections seem unlikely under those circumstances. I would not be surprised if this should cause your server to fail to start.
I'm seeking local assistance in getting that backtrace Sander suggested.
So the fact that it doesn't happen when the server starts (which is when we read the SSL private keys and certificates from disk), and does not cause the connections to the browser to fail, suggests that this does not have anything to do with mod_ssl.
I agree, especially now that the latest observations show it not being thrown when the only module dealing w/ Public/Private keys involved is mod_ssl.
What other modules do you have that might be reading a private key from a PEM blob on every request?
That would be mod_cosign's CosignCrypto directive.
I have already verified that the private key file is NOT password protected. I've also seen notations on both sites for Apache and mod_ssl:"Why does my 2048-bit private key not work?" http://www.modssl.org/docs/2.8/ssl_faq.html http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#keysizeboth seem to say say that 2048-bit private keys are NOT ALLOWED because of incompatibility w/ certain web browsers. Meanwhile it's not clear that I could even generate a 2048-bit public key without having a 2048-bit private key. So how could these COMODO certs EVER work if this was the issue?Surely that is very old and no longer relevant. If you visit https://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#keysize , you will find it protected by a 4096 bit key.
Not sure how I would see that, closest I can see is the "Subject's Public Key" is "Size: 526 Bytes / 4208 Bits". But I believe you. Ironic, isn't it, that the documentation is so clearly refuted by reality on the same page ;-P
Count this with a layer of extreme urgency, as this new vendor is my only source for certificates now, and I have two production webservers withcurrent certs expiring in about 30 hours that I need to replace w/ these new certs.Besides the weird error messages, what is the impact on functionality at this point?
Honestly, I'm not sure. The particular site I chose to verify the
new certificates installation procedure is a low-volume site. The
site that I have to apply these certs to TODAY is a very HIGH volume
site, so at the very least that server's log files are going to
explode.
The site in question is the University Libraries' bread-and-butter
site, the Online Public Access Catalog, https://cat.libraries.psu.edu.
Whenever any of our literally millions of users authenticates and
goes to access their personal information (reserves, personalized
searches, requests & recalls, renewals, etc.) we're going to see
similar messages logged. And if indeed there's something more
sinister taking place, it's going to happen a LOT more.
--
J.Lance Wilkinson ("Lance") InterNet: Lance.Wilkinson@xxxxxxx
Systems Design Specialist - Lead Phone: (814) 865-4870
Digital Library Technologies FAX: (814) 863-3560
E3 Paterno Library
Penn State University
University Park, PA 16802
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|