Jump to content

Recommended Posts

Hi Guys,

So I've recently bought and installed a wildcard SSL on my server which governs domain.com and any subdomain that I add to it.

 

In essence, the cert works fine. For example, if I set up a static 'hello world' PHP page and set the domain to sub1.domain.com, the page is displayed in both HTTP and HTTPS (with some mod_rewrite which I'll come to shortly).

 

The issue is that the domain is serving applications, which all kind of need their own document root to function properly.

 

If I print_r the $_SERVER array outside HTTPS, I see the correct document root - something like:

/home/domain.com/public_html/_apps/sub1/

That would be the doc root for sub1.domain.com

 

If I then switch over to HTTPS and again, print_r the $_SERVER array, I get:

/home/domain.com/public_html

 

It seems to be completely ignoring the docroot for that subdomain. The current mod_rewrite I'm using in the docroot of the base domain is:

 

RewriteEngine On
RewriteCond %{SERVER_PORT} ^443$
RewriteCond %{HTTP_HOST} ^sub1\.domain\.com$ [NC]
RewriteCond %{REQUEST_URI} !^/_apps/sub1/
RewriteRule ^(.*) /_apps/sub1/$1

 

This is required to get the wildcard SSL working across multiple subdomains. Without this, switching to SSL just reverts to the base domain.

 

Does anybody know if/how I can maintain the document root from normal HTTP inside HTTPS and stop it changing the document root to that of the base domain when running through HTTPS?

 

Cheers

Pete

Link to comment
https://forums.phpfreaks.com/topic/245120-wildcard-ssl-woes/
Share on other sites

Do you have a wildcard because you have an unknown and wide variety of subdomains? Or another way, is there a reason you can't set up virtual hosts for each subdomain? I think:

ServerName sub1.domain.com
DocumentRoot /home/domain.com/public_html/_apps/sub1

Link to comment
https://forums.phpfreaks.com/topic/245120-wildcard-ssl-woes/#findComment-1259093
Share on other sites

Hi requinix,

Exactly so - we have a lot of sub domains and we are adding more all the time so a wildcard SSL was the only practical option.

 

The subdomains are done using virtual hosts. As I mentioned, without SSL, the document root directory for each subdomain is correct (i.e. /home/public_html/_apps/sub1 being the docroot for sub1.domain.com), but it's when you visit one of the subdomains behind SSL that the issue occurs. For some reason, behind SSL, each subdomain's document root reverts back to the document root for domain.com as oppose to sub1.domain.com.

 

The mod_rewrite code is in there purely to allow the wildcard SSL to be distributed across the multiple subdomains. There's one entry for each subdomain as the SSL doesn't work for the domains without the mod_rewrite. I was just wondering if there was something I could put in the mod_rewrite to make it maintain the correct document root for each subdomain (as it is when it's not behind SSL) rather than reverting the document root for each domain back to the doc root for the base domain.

 

Thanks

Pete

Link to comment
https://forums.phpfreaks.com/topic/245120-wildcard-ssl-woes/#findComment-1259104
Share on other sites

Unless something's different, Apache serves HTTP and HTTPS out of two different locations. They're configured separately. So apparently the HTTPS is being served out of the normal public_html.

 

You say you're doing the subdomains with virtual hosts, but there must be something special going on if you have a lot of them and keep adding more. How are the new ones created and what do their s look like?

Link to comment
https://forums.phpfreaks.com/topic/245120-wildcard-ssl-woes/#findComment-1259171
Share on other sites

I've included a VirtualHost entry below. The SSL governs the entire domain so it's not included in the VHost config for each vhost.

 

<VirtualHost XXX.XXX.XXX.XXX:80>
    ServerName sub1.domain.com
    ServerAlias www.sub1.domain.com
    DocumentRoot /home/domain/public_html/_apps/sub1/public_html
    ServerAdmin webmaster@sub1.domain.com
    UseCanonicalName On
    CustomLog /usr/local/apache/domlogs/sub1.domain.com combined
    CustomLog /usr/local/apache/domlogs/sub1.domain.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."
    ## User wunderap # Needed for Cpanel::ApacheConf
    <IfModule !mod_disable_suexec.c>
        SuexecUserGroup wunderap wunderap
    </IfModule>
    ScriptAlias /cgi-bin/ /home/domain/public_html/_apps/sub1/public_html/cgi-bin/
</VirtualHost>

Link to comment
https://forums.phpfreaks.com/topic/245120-wildcard-ssl-woes/#findComment-1259320
Share on other sites

I've just given that a shot, all I seem to get is the error:

An error occurred during a connection to test.wunderapps.com.

 

SSL received a record that exceeded the maximum permissible length.

 

(Error code: ssl_error_rx_record_too_long)

 

Thanks

Pete

Link to comment
https://forums.phpfreaks.com/topic/245120-wildcard-ssl-woes/#findComment-1260423
Share on other sites

I think that's a separate issue. I'm Googling it myself and getting things like

- Don't use name-based virtualhosting for SSL sites (eg, "NameVirtualHost a.b.c.d:443")

- Make sure you don't have any non-SSL sites listening on :443

- Comment out any s and just assume that SSL is loaded

- Check for typos (though that applies to pretty much everything)

 

Any of that help?

Link to comment
https://forums.phpfreaks.com/topic/245120-wildcard-ssl-woes/#findComment-1260628
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.