httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Lance Wilkinson <jl...@psu.edu>
Subject [users@httpd] mod_nss ??
Date Tue, 24 Feb 2015 14:32:22 GMT
This morning a webserver that I'm responsible for (but didn't have a 
particularly significant hand in setting up) was reporting as <defunct> in a
	$ ps -ef | grep httpd
display.  This is on RHEL6 and it's Apache HTTPD 2.2 patched up the way that
Red Hat does things.

When I explored the logs, and especially after I tried to restart it and got a
[FAILED] report on the start, I found several log entries suggesting SSL 
problems and an unexpired certificate.

But the webserver in question doesn't supply ANY SSL encrypted services.

Turns out what appeared to be a legacy use of mod_nss was present in the 
configuration.

I was able to restore the services by simply commenting out the nss.conf file 
from the /etc/httpd/conf.d directory.

But I'd really like to confirm things by trying to identify just what this 
expired certificate was trying to secure.   The only reference that I can find 
to a specific certificate complains about "Server-cert" and naturally there's 
no such file anywhere in the perview of the server.

Skimming docs on mod_nss, I see that I shouldn't be able to find individual 
certificates, because they're all in a database.

The docs I've found don't tell how to review the contents of the database
which appears to be in three files (cert8.db, key3.db and secmod.db) in a
directory cited in one of the NSS configuration directives, /etc/httpd/alias

The server is one of two that are load balanced.  While the one that failed 
appears to have its database files all timestamped 4 years ago (Feb 23 2011), 
the one that did not has the same files but timestamped a little more recent 
(Dec 6 2011).   So it's likely on or about December 6th I'll observe the same 
issue on that other server.

While my brute force method of recovering the server that expired with its 
certificates overnight seems to alleviated the issue, I'd love to be able to 
definitively say what this was applying to before using the same brute force 
method on the as yet unaffected server.


-- 
J.Lance Wilkinson ("Lance")		InterNet: Lance.Wilkinson@psu.edu
Systems Design Specialist - Lead	Phone: (814) 865-4870
Information Technology Services 	FAX:   (814) 863-3560
Penn State University
ITS Services and Solutions (SaS), 6 Willard, University Park, PA 16802
http://ucs.psu.edu/home/jlw12@psu.edu?fmt=freebusy


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message