httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Lance Wilkinson" <jl...@psulias.psu.edu>
Subject Re: [users@httpd] Apache HTTPD 2.2.6 + mod_ssl 2.2.6 -- odd error...
Date Wed, 01 Dec 2010 13:18:04 GMT
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:PEM
>> routines: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#keysize
>> 
>> both 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 with
>> current 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@psu.edu
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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message