SSL doesn't work on new server. Is Apache listening on port 443?

[tomfra]

I've just moved some accounts from old server to a new one throught the WHM Transfer. On the new server there is Apache 2.2.x installed.

I installed a self-signed SSL certificate on one domain through WHM. All went OK, no errors at all. But when I access https://DOMAIN.COM or https://DEDICATED_DOMAIN_IP, it doesn't work. I get simply "Page cannot be displayed" or "Connection Error" error message.

I checked the apache logs, including the error log and domain log and there is even no record about the connection attempts. It seems almost as if Apache was not listening on port 443?

At the very end of httpd.conf is this:

<IfDefine SSL>
    SSLMutex  file:/usr/local/apache/logs/ssl_mutex
    SSLPassPhraseDialog  builtin
    SSLSessionCache         dbm:/usr/local/apache/logs/ssl_scache
    SSLSessionCacheTimeout  300
</IfDefine>

<IfDefine SSL>

<VirtualHost 123.123.123.123:443>
    ServerAdmin [email protected]
    DocumentRoot /home/USERNAME/public_html
    ServerName DOMAIN.COM
    UserDir public_html
    <IfModule mod_suphp.c>
        suPHP_UserGroup USERNAME USERNAME
    </IfModule>
    <IfModule !mod_disable_suexec.c>
        SuexecUserGroup USERNAME USERNAME
    </IfModule>
    CustomLog /usr/local/apache/domlogs/DOMAIN.COM-bytes_log "%{%s}t %I .\n%{%s}t %O ."
    ScriptAlias /cgi-bin/ /home/USERNAME/public_html/cgi-bin/
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/DOMAIN.COM.crt
    SSLCertificateKeyFile /etc/ssl/private/DOMAIN.COM.key
    ErrorLog /usr/local/apache/domlogs/DOMAIN.COM-ssl_data_log
    CustomLog /usr/local/apache/domlogs/DOMAIN.COM-ssl_log combined
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
</VirtualHost>

</IfDefine>

Perhaps there could be a problem with this section? It was added directly by WHM.

Any help is very appreciated!

Tomas

 

[Todd Mitchell]

This will be resolved in the next set of builds.

You need to edit the apache init scripts and modify the startssl strings.

Edit Line 84 of /usr/local/apache/bin/apachectl & line 102
of /etc/init.d/httpd

The startssl section should be:

startssl|sslstart|start-SSL)
$HTTPD -k start -DSSL
ERROR=$?
;;

Once finished editing, run '/etc/init.d/httpd stop' then '/etc/init.d/httpd startssl' and SSL will be enabled.

If you are unsure of making these modification, submit a ticket and I'll be happy to make the changes for you.

Please note, this only affects Apache 2.x.

 

[tomfra]

That worked! Only the "-DSSL" part was missing in fact.

Thanks!

Tomas

 

[Todd Mitchell]

Yes, a slight change was made earlier this week which caused this to happen. The developers have resolved it, however the build hasn't been pushed out yet, should be out early next week. Until then, gotta make the change manually.

 

[joeyiv]

was this introduced with build 11.12.0-CURRENT_17349? When will the fix be out?

 

[Todd Mitchell]

Yes, this was introduced with build 17349. The fix has been pushed to EDGE and should make it's way to CURRENT soon.

 

[joeyiv]

Just to make sure - the problem I'm having is that my ssl seems to be broken. No sites that require https:// will work. This is what should result based on the bug that was introduced, right?

Should I have any problems upgrading to EDGE to fix this bug? Also, should I then have problems when I downgrade back to CURRENT? Thanks for your help!

 

[Todd Mitchell]

I don't recommend upgrading to EDGE as it isn't recommended for production use.

However this can easily be fixed by editing the init files as I posted earlier.

If you are unsure of making this change, submit a ticket at https://tickets.cpanel.net/submit/index.cgi?reqtype=tickets and pm me the ticket number and I'll be happy to make the change for you.

 

[joeyiv]

Yeah - I couldn't seem to find the first directory that you said needed to be changed. I just submitted a support ticket - but the site told me that you couldn't accept pmessages. Where can I find the ticket number? the ip for my server is 208.73.37.43 Thank you very much for your help! I have a theater site that uses an SSL and their tickets are supposed to go on sale today... Thanks again.

 

[Todd Mitchell]

Not sure whats up with the private message system.

But you should of received a ticket number when you submitted the ticket. If you have this, post it here so I can take a look at the ticket.

 

[joeyiv]

Should I have received it in an email? I haven't received anything not did I see anything - Sorry. It just gave me a message that said that something had been authenticated and that I would receive a higher priority...

 

[cPanelDavidG]

Should I have received it in an email? I haven't received anything not did I see anything - Sorry. It just gave me a message that said that something had been authenticated and that I would receive a higher priority...

You should have received an email indicating what your ticket ID number is.

 

[joeyiv]

i never received an email - and there is nothing in my junk folder either. should I submit another ticket maybe? Thanks again.

 

[cPanel Scott]

Hi joeyiv,
I've sent you a PM asking you for additional information.

Thank you,

Scott O'Neil
Systems Administrator, cPanel

 

[joeyiv]

Todd,

Here is my ticket #: 215305

Thank you very much!

 

[S-Combs]

Thanks for the fix Todd, it helped me as well. I did notice however that restarting httpd via WHM afterwards will restart without SSL support again. I had to run the stop/startssl mentioned above again.

 

[S-Combs]

This now seems to be resolved after updating to 11.15.0-C17483 today




EDIT: I posted incorrect upgrade version earlier (forgot to reload frame :P)

 

[Todd Mitchell]

Yup. The fix for this has been pushed out in the latest EDGE and CURRENT updates.

 

[fenixer]

Yup. The fix for this has been pushed out in the latest EDGE and CURRENT updates.

Nowadays, I am running:

WHM 11.11.0 cPanel 11.16.0-R18546
FEDORA 6 i686 on standard - WHM X v3.1.0

The init.d script for httpd shows:

restart)
if [ $RUNNING -eq 0 ]; then
echo "$0 $ARG: httpd not running, trying to start"
if $HTTPD ; then
echo "$0 $ARG: httpd started"
else
echo "$0 $ARG: httpd could not be started"
ERROR=5
fi
else
if $HTTPD -t >/dev/null 2>&1; then
if kill -HUP $PID ; then
echo "$0 $ARG: httpd restarted"
else
echo "$0 $ARG: httpd could not be restarted"
ERROR=6
fi

Yesterday, Apache was running, but https sites were down.. if you tried to connect to https it shows message like if port were not being listened, you know...

After "service httpd restart" several times, it was just the same.... I needed to execute "killall -9 httpd;service httpd startssl", and then https went up.

Can you please give me a clue what were happening and why restarting httpd through script did not nothing about it??

Added info few hours after
--------------------------------------
Look at this:

[email protected] [~]# lsof -ni tcp:443
[email protected] [~]# netstat -ln | grep 443
unix 2 [ ACC ] STREAM LISTENING 73144391 /var/run/ftpd.sock
[email protected] [~]# service httpd restart
/etc/init.d/httpd restart: httpd restarted
[email protected] [~]# netstat -ln | grep 443
unix 2 [ ACC ] STREAM LISTENING 73144391 /var/run/ftpd.sock
[email protected] [~]# service httpd stop&&service httpd startssl
/etc/init.d/httpd stop: httpd stopped
/etc/init.d/httpd startssl: httpd (pid 2529) already running
[email protected] [~]# service httpd stop&&service httpd startssl
/etc/init.d/httpd stop: httpd (no pid file) not running
/etc/init.d/httpd startssl: httpd started
[email protected] [~]# netstat -ln | grep 443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
unix 2 [ ACC ] STREAM LISTENING 73144391 /var/run/ftpd.sock

mmmmm... this is getting me crazy. SSL falls and non chkservd nor automatically (via cronjob each 2 hours) httpd restart scripts could fix it..

Do I need to killall -TERM httpd proccesses each 2 hours to be sure SSL would be running OK??? All visitors each two hours would see their loadings being interrupted.. I do not think it is the best sollution.

Thanks.

 

[nvvetal]

Please note, this only affects Apache 2.x.

And what about Apache 1.34 ? I have exactly the same error!