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.wilkin...@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-unsubscr...@httpd.apache.org
  "   from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Reply via email to