Bug 697113

With the SSL configuration in place:

1) Does running "/usr/sbin/httpd" directly work, or have any output?

2) Is there any output from running "httpd -t"?

3) Does httpd start if you use permissive SELinux mode ("setenforce Permissive" as root; remember to reset to Enforcing after testing)

Stop apache and mv ssl.conf.bk to ssl.conf and then do below 

1)

[root@myserver]# /usr/sbin/httpd                      
[root@myserver]# ps -ef | grep httpd    
root      8818  8816  0 05:11 ?        00:00:00 sudo tail -c 0 /var/log/httpd/www.myserver.com.access_log                                                                                     
root     10889 10818  0 16:25 pts/0    00:00:00 grep --color=auto httpd

2) 
                               
[root@myserver]# httpd -t                           
Syntax OK           

3) Selinux is already disabled.

     SELINUX=disabled

Well i have now successfully resolved the mystery :) 

I have enabled debug log and nothing special found in it, but i see that as ssl.conf have localhost.crt line so they generating temporarly private keys. For sixsense i view the localhost.crt, its CN value is != localhost , i have now copied localhost.crt file from other fc14 machine, and now apache is started f9 with SSL (ssl.conf).

Suggestion: I think it atleast tell in debug if CN value is mismatch and its failed to start apache via ssl.conf, as its difficult to trace the problem with out showing any reason also in debug log.

A(In reply to comment #3)
> Well i have now successfully resolved the mystery :) 
> 
> I have enabled debug log and nothing special found in it, but i see that as
> ssl.conf have localhost.crt line so they generating temporarly private keys.
> For sixsense i view the localhost.crt, its CN value is != localhost , i have
> now copied localhost.crt file from other fc14 machine, and now apache is
> started f9 with SSL (ssl.conf).

Also localhost.crt is expired, as machine is old and localhost.crt is also old.

> 
> Suggestion: I think it atleast tell in debug if CN value is mismatch and its
> failed to start apache via ssl.conf, as its difficult to trace the problem with
> out showing any reason also in debug log.

Or if cert is expired, so atleast shows in debug log, which helpful to fix the problem with out wasiting time.

Thanks
Muzi

Thanks for the update.  Was there not an error logged to /var/log/httpd/ssl_error_log at least?  It can be confusing where these errors end up.

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping