WHM - Content served over https only, http throws 404

Question

I just set up a VPS using WHM. I setup the account, and installed an SSL certificate. Everything serves fine using an HTTPS connection, but any time I try to load anything via vanilla HTTP, I just get a 404 error.

I've looked at the generated VirtualHost settings, and both port 80 and 443 share the same document root. This is only happening on the subdomain (secure.example.com) that the SSL cert is configured for. Serving HTTP over the regular domain (example.com) works fine.

What am I missing? Thanks.

UPDATE:

Here's my vhost config.

example.com

<VirtualHost server.ip.address:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /home/username/public_html
    ServerAdmin webmaster@example.com
    UseCanonicalName Off
    CustomLog /usr/local/apache/domlogs/example.com combined
    CustomLog /usr/local/apache/domlogs/example.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."
    ## User username # Needed for Cpanel::ApacheConf
    UserDir disabled
    UserDir enabled username 
    <IfModule mod_suphp.c>
        suPHP_UserGroup username username
    </IfModule>
    <IfModule !mod_disable_suexec.c>
        SuexecUserGroup username username
    </IfModule>
    ScriptAlias /cgi-bin/ /home/username/public_html/cgi-bin/


    # To customize this VirtualHost use an include file at the following location
    # Include "/usr/local/apache/conf/userdata/std/2/username/example.com/*.conf"

</VirtualHost>

secure.example.com

<VirtualHost server.ip.address:80>
    ServerName secure.example.com
    ServerAlias www.secure.example.com
    DocumentRoot /home/username/public_html/secure
    ServerAdmin webmaster@secure.example.com
    UseCanonicalName Off
    CustomLog /usr/local/apache/domlogs/secure.example.com combined
    CustomLog /usr/local/apache/domlogs/secure.example.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."
    ## User username # Needed for Cpanel::ApacheConf
    UserDir disabled
    UserDir enabled username
    <IfModule mod_suphp.c>
        suPHP_UserGroup username username
    </IfModule>
    <IfModule !mod_disable_suexec.c>
        SuexecUserGroup username username
    </IfModule>
    ScriptAlias /cgi-bin/ /home/username/public_html/secure/cgi-bin/


    # To customize this VirtualHost use an include file at the following location
    # Include   "/usr/local/apache/conf/userdata/std/2/username/secure.example.com/*.conf"

</VirtualHost>

secure.example.com:443

<VirtualHost server.ip.address:443>
    ServerName secure.example.com
    ServerAlias www.secure.example.com
    DocumentRoot /home/username/public_html/secure
    ServerAdmin webmaster@secure.example.com
    UseCanonicalName Off
    CustomLog /usr/local/apache/domlogs/secure.example.com combined
    CustomLog /usr/local/apache/domlogs/secure.example.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."
    ## User username # Needed for Cpanel::ApacheConf
    UserDir disabled
    UserDir enabled username
    <IfModule mod_suphp.c>
        suPHP_UserGroup username username
    </IfModule>
    <IfModule !mod_disable_suexec.c>
         SuexecUserGroup username username
    </IfModule>
    ScriptAlias /cgi-bin/ /home/username/public_html/secure/cgi-bin/
    SSLEngine on

    SSLCertificateFile /etc/ssl/certs/secure.example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/secure.example.com.key
    CustomLog /usr/local/apache/domlogs/secure.example.com-ssl_log combined
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
    <Directory "/home/username/public_html/secure/cgi-bin">
        SSLOptions +StdEnvVars
    </Directory>

    # To customize this VirtualHost use an include file at the following location
    # Include "/usr/local/apache/conf/userdata/ssl/2/username/secure.example.com/*.conf"

 </VirtualHost>

Answer 1

Are you sure these vhost configurations are being loaded? (That is, are they being included by apache2.conf)? If the secure.example.com configuration isn't being loaded, requests on port 80 for secure.example.com might get served by example.com and therefore get 404s because the file URIs would be wrong. (To check this concept, try adding secure/ to the request URLs and see if they work.)