Godaddy SSL certificate and ISPConfig 3 Debian

Thanks for the reply btw

Ok i'm confused I read that site and this is a excerpt from it:

SSLCertificateFile /path/to/your/certificate/file
SSLCertificateKeyFile /path/to/your/key/file
SSLCertificateChainFile /path/to/intermediate/bundle/file

So I assumed that the SSLCertificateChainFile was asking for the gd_bundle.crt because it says /path/to/intermediate/bundle/file - see the bundle bit??

What do I do with the gd_bundle.crt if on that apache installation site it doesn't reference it??

 

Don't be shy about hitting the "Thanks" button on useful posts.

You're right; the GoDaddy article is scant on details. Go figure... It's quite possibly the worst hosting company on the planet (and without question the worst website).

Don't get hung-up on the term "bundle". All that means is multiple certificates concatenated together into a single file.

Did you have a look at the link to GoDaddy's public certificate repository that is referenced in the article?

https://certs.godaddy.com/anonymous/repository.seam

It seems as though you may be missing one of the so-called "intermediate" certificates. I have no way to know which one, as I cannot test your configuration (obviously), but I suspect it may be the file listed as "gd_intermediate.crt" at the above-referenced repository URL.

Let's take a closer look at the relevant Apache documentation ( http://httpd.apache.org/docs/2.0/mod/mod_ssl.html ).

SSLCACertificateFile Directive

SSLCertificateChainFile Directive

All GoDaddy has to say about intermediate certificates is http://help.godaddy.com/article/869 (which contains nothing useful and directs the user back to the article that I cited a couple of posts back).

What's it all mean? Try something like this in the Apache configuration:

Code:

SSLCertificateChainFile /path/to/gd_intermediate.crt

Don't forget to restart Apache and check the log for any errors.

 

LoL I like that...

Anyway I had already tried this see post dated: 7th January 2012 15:19

But I believe we are right. I updated to ISPConfig 3.0.4.2 tonight and it removes that line in the file /etc/apache2/sites-available/ispconfig.vhost under SSL

SSLCertificateChainFile /usr/local/ispconfig/interfaces/ssl/gd_bundle.crt

So I tried it out on a completely clean machine I have never tried accessing my webmail or anything through it as yet. True to form it comes up with a SSL error. But when I put that line back in and restart apache it doesn't come up with a SSL error. When I look at the certificate it has some issue saying that its run by (unknown) but I think thats just because I bought the cheapest option - dutch I know

Anyway I think that GoDaddy's SSL installer (dumb name because it doesn't install it just tests) gets hung up on the fact that I also run a Spiceworks machine (Window XP) on port 443 which is generally the https port. Even though there is a option to change the port from 443 to 50443.

To be honest I would love to do away with all this 50443 and just have some form of reverse proxy so that if I type in the URL www.example.com/help it redirects to my Spiceworks server. If I type in www.example.com/webmail it redirects to Roundcube on the ISPConfig server which is the apache server. But I guess I would have to start a new thread for that huh??

Cheers though Ben for your help its greatly appreciated. Also all that work of researching apache documents I really do appreciate that.

thanks mate

 

This is simply because ISPConfig overwrites the file in question when one responds "Yes" to "Reconfigure Service?" during an upgrade. It's not as though ISPConfig detected that this line is "incorrect"; it simply paves-over the entire file.

So, be aware of this behavior when upgrading ISPConfig in the future. (As an aside, I have requested that this behavior be changed for this very reason; feel free to "vote" for the issue at http://bugtracker.ispconfig.org/index.php?do=details&task_id=1970 .)

This is not an "error", per se. And you're right, this message is the result of being a cheap bastard. Just kidding... unless you are running an e-commerce site and require sophisticated certificate validation, I wouldn't spend the extra money.

Functionally, all SSL certificates are basically the same. The difference in price has to do with the "trustworthiness" of a certificate. The least extensive validation method, "Domain Control Validation", will cause this "notice" to be displayed if the user inspects the certificate in most browsers. All this message means is that the issuing CA (Certificate Authority) did not take extensive measures to verify that the entity to whom the certificate was issued runs/owns the domain. Domain Control Validation requires only that the certificate requester be able to receive a "confirmation email" at a predefined address (e.g., [email protected]). The theory is that this method ensures that the requester actually controls the domain for which the certificate is being issued. Needless to say, this method is not very rigorous, but it doesn't require cumbersome paperwork to be filed, as with the more "trustworthy" validation methods.

Well, which certificate is presented when you use the GoDaddy tool? The certificate that is configured via Apache, or the certificate for Spiceworks? Or are both services using the same certificate, so you aren't sure whether GoDaddy is hitting Apache or Spiceworks?

It seems far more logical to run Apache on ports 80 and 443 (the standard ports) and configure Spiceworks to use some alternate port (e.g., 50443).

Does the GoDaddy tool not offer a means to specify the port number of the target Web server?

Also, there's no need to setup a reverse proxy to redirect to your Spiceworks server. You could just use mod_rewrite for that.

 

Done although I did read what was added there by someone else; to me it makes sense to have it documented better in my opinion.

Fair enough I will save my money although at some point having a wild card certificate would really be helpful.

Spiceworks is found even if I try changing the port to 50443... seems like it finds 443 first and sticks to it.

I'm using the self generated for Spiceworks and the verified certificate for Apache only.

I would agree with this. Personally seeing the port number in the URL looks tacky IMHO. Can I make this disappear even though it IS using port 50443 make it not show up like https uses 443 but doesn't show that in the URL???

Yes it does, however it appears to not work for me.

Now this could be the best bit of information ever. Would you be able to direct me to a good tutorial or tell me here. That would solve my certificate issues just nicely.

Also one other thing I've noticed is that when I add a clients domain they can access the webmail setting by typing www.theirdomain.com/webmail however because there is no trusted certificate it comes up with certificate issues.
My request would be how can I redirect www.everyclientsdomain/webmail to www.mytrusteddomain.com/webmail???

Thanks again Ben

 

No. Browsers are configured to hide the port number when it is 80 or 443, because they are standard conventions. Any other port number will always be displayed. You have no choice but to use an alternate port for Spiceworks (provided you want Apache bound to 80 and 443) if Apache and Spiceworks are listening on the same network interface (IP address). If you are in a position to purchase a second IP address for the server in question, or run Spiceworks on a different server altogether (provided it has a different IP address and is not on a home/office LAN or similar), it would be possible to run it on port 443 as well. Apache and Spiceworks would then be accessible via different domains (ideally, two subdomains of the same top-level domain) and the port number would not be displayed.

Regarding the GoDaddy certificate validation tool, and port number specification not working as expected, what happens when you visit the domain and port for Apache vs. the domain and port for Spiceworks? Does the browser present the correct certificate for each? If so, then yes, GoDaddy's tool must be broken (which would not be surprising).

As for the mod_rewrite approach to your issue, your case is so simple that mod_alias should work just as well (and is less complicated). Try adding something like this to your Apache configuration:

Code:

Redirect permanent /help http://example.com:50443

This will redirect all requests for the /help URL on the Apache Web server to the Spiceworks server. You can add a file path after the port, if required. Don't forget to reload Apache for the changes to take effect.

Right; this is the expected behavior.

Do something like this in your Apache configuration:

Code:

<Location /webmail>
SSLOptions +StrictRequire
SSLRequireSSL
SSLRequire %{HTTP_HOST} eq "example.com"
ErrorDocument 403 https://example.com/webmail
</Location>

Also, have a look at my Roundcube thread for other ideas that may be of interest (unless, of course, you are using SquirrelMail):

http://www.howtoforge.com/forums/showthread.php?p=271942

 

Ok its working to a extent however it puts it in a endless loop.

from the log /var/log/ispconfig/httpd/error.log it shows countless tries without SSL ... this is my code:

Code:

<IfModule mod_rewrite.c>
  <IfModule mod_ssl.c>
    <Location /webmail>
      SSLOptions +StrictRequire
      SSLRequireSSL
      SSLRequire %{HTTP_HOST} eq "www.example.com"
      ErrorDocument 403 https://www.example.com:50443/webmail

      RewriteEngine on
      RewriteCond %{HTTPS} !^on$ [NC]
      RewriteRule . https://%{HTTP_HOST}:50443%{REQUEST_URI}  [L]
    </Location>
  </IfModule>
</IfModule>

The rewrite I need so that a simple www.example.com/webmail gets redirected to https://www.example.com:50443/webmail

I have tried putting it before, after, seperate but no luck...

Oh and by the way you rock with the /help thing that works a treat and is so dang simple... thank you so much

 

You do have the following line somewhere in the Apache configuration, right?

Code:

Alias /webmail /var/lib/roundcube

Obviously, if you are using SquirrelMail, the second argument above would need to be adjusted accordingly.

Let me explain the following block a bit more:

Code:

SSLOptions +StrictRequire
SSLRequireSSL
SSLRequire %{HTTP_HOST} eq "www.example.com"
ErrorDocument 403 https://www.example.com:50443/webmail

This tells Apache, in essence, "If the connection is not over SSL, and if the requested hostname is not exactly www.example.com, then respond with the 403 error code and send the user-agent to the specified "error document" (in this case, the desired "index" URL).

So, you shouldn't actually need the second rule, as the above directives cover both conditions:

1.) Ensure that the connection is encrypted;
2.) Ensure that the requested hostname is www.example.com

The one thing this won't do is redirect individual page requests to their encrypted equivalents; this snippet will always direct users to /webmail, even if they request /webmail/mailbox.php, or any "deeper" URL. A second rule would be required for that (and it would look similar to, but not exactly like, what you have there).

This is a more robust way of enforcing SSL connections. The mod_rewrite approach that you included after the above bit will work, but it requires mod_rewrite to be enabled and there are certain cases in which SSL will not be forced (this is why I use SSLOptions +StrictRequire).

To reiterate, just delete (or comment-out) the mod_rewrite directives and see if everything works as expected.

 

Yes I do and I have only roundcube running

I have tried that but to no avail. I get a error message in the web browser that says:

This webpage has a redirect loop
The webpage at https://www.example.com:50443/webmail has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.

This is my complete file from /etc/apache2/conf.d/roundcube

Code:

# Those aliases do not work properly with several hosts on your apache server
# Uncomment them to use it or adapt them to your configuration
#    Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
Alias /webmail /var/lib/roundcube

# Access to tinymce files
<Directory "/usr/share/tinymce/www/">
      Options Indexes MultiViews FollowSymLinks
      AllowOverride None
      Order allow,deny
      allow from all
</Directory>

<Directory /var/lib/roundcube/>
  Options +FollowSymLinks
  # This is needed to parse /var/lib/roundcube/.htaccess. See its
  # content before setting AllowOverride to None.
  AllowOverride All
  order allow,deny
  allow from all
</Directory>

# Protecting basic directories:
<Directory /var/lib/roundcube/config>
        Options -FollowSymLinks
        AllowOverride None
</Directory>

<Directory /var/lib/roundcube/temp>
        Options -FollowSymLinks
        AllowOverride None
        Order allow,deny
        Deny from all
</Directory>

<Directory /var/lib/roundcube/logs>
        Options -FollowSymLinks
        AllowOverride None
        Order allow,deny
        Deny from all
</Directory>

#<IfModule mod_rewrite.c>
#  <IfModule mod_ssl.c>
    <Location /webmail>
        SSLOptions +StrictRequire
        SSLRequireSSL
        SSLRequire %{HTTP_HOST} eq "www.example.com"
        ErrorDocument 403 https://www.example.com:50443/webmail

#      RewriteEngine on
#      RewriteCond %{HTTPS} !^on$ [NC]
#      RewriteRule . https://%{HTTP_HOST}:50443%{REQUEST_URI}  [L]
    </Location>
#  </IfModule>
#</IfModule>

 

It seems as though you have a rewrite rule elsewhere that is affecting the behavior.

What happens if you remove all of these configuration directives? Do you simply hit www.everyclientsdomain/webmail over a plaintext connection?

Also, you should be adding these directives to the <Directory /var/lib/roundcube/></Directory> block, not creating a new <Location></Location> block for /webmail.

Try adding the following (and none of the directives that you are using unsuccessfully) to the <Directory /var/lib/roundcube/> block:

Code:

RewriteCond %{HTTPS} !=on
RewriteRule ^.*$ https://%{SERVER_NAME}:%{SERVER_PORT}%{REQUEST_URI} [R,L]

Does that do the job?

Don't worry, I'm not just shooting in the dark here I have this type of thing working on several of my servers, so I know that the code itself is viable.

 

No it errors out with - I now get a error 500 when I put in www.example.com/webmail - internal server error (ispconfig error 500 i believe)

I got the code from this tutorial when I setup everything
http://www.howtoforge.com/extending-perfect-server-debian-squeeze-ispconfig-3-p2

This is my new /etc/apache/conf.d/roundcube file that I tried:

Code:

# Those aliases do not work properly with several hosts on your apache server
# Uncomment them to use it or adapt them to your configuration
#    Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
Alias /webmail /var/lib/roundcube

# Access to tinymce files
<Directory "/usr/share/tinymce/www/">
      Options Indexes MultiViews FollowSymLinks
      AllowOverride None
      Order allow,deny
      allow from all
</Directory>

<Directory /var/lib/roundcube/>
  RewriteCond %{HTTPS} !=on
  RewriteRule ^.*$ https://%{SERVER_NAME}:%{SERVER_PORT}%{REQUEST_URI} [R,L]
  Options +FollowSymLinks
  # This is needed to parse /var/lib/roundcube/.htaccess. See its
  # content before setting AllowOverride to None.
  AllowOverride All
  order allow,deny
  allow from all
</Directory>

# Protecting basic directories:
<Directory /var/lib/roundcube/config>
        Options -FollowSymLinks
        AllowOverride None
</Directory>

<Directory /var/lib/roundcube/temp>
        Options -FollowSymLinks
        AllowOverride None
        Order allow,deny
        Deny from all
</Directory>

<Directory /var/lib/roundcube/logs>
        Options -FollowSymLinks
        AllowOverride None
        Order allow,deny
        Deny from all
</Directory>

Haha I am sure that you know what your talking about... honestly I am very happy that you bother to respond to me. I really do appreciate it mate, its not very common that someone helps repeatedly.

 

It looks like there may be several issues at play, actually:

1.)

You have the mod_rewrite directive before the access control directives.

In other words, move the mod_rewrite code down to the bottom of that block. Please revisit my thread at http://www.howtoforge.com/forums/showthread.php?p=271942 (and in particular, the last bit of step 4) for details.

2.)

suPHP (which is active when the FastCGI PHP mode is in effect) is not disabled for the Roundcube directory. See above link (relevant bit pasted below for your convenience).

Code:

  <IfModule suphp_module>
    suPHP_Engine Off
    AddHandler php5-script	.php
  </IfModule>

3.)

PHP open_basedir errors are likely to occur unless you add the necessary directives here. Again, see above link (relevant bit pasted below for your convenience).

Code:

  php_admin_value open_basedir "/usr/share/php:/etc/roundcube/:/usr/share/roundcube:/var/log/roundcube:/var/lib/roundcube"

 

G'day Ben,

I have tried countless configurations now, but they all don't work.

Code:

# Those aliases do not work properly with several hosts on your apache server
# Uncomment them to use it or adapt them to your configuration
#    Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
Alias /webmail /var/lib/roundcube

# Access to tinymce files
<Directory "/usr/share/tinymce/www/">
      Options Indexes MultiViews FollowSymLinks
      AllowOverride None
      Order allow,deny
      allow from all
</Directory>

<Directory /var/lib/roundcube/>
  Options +FollowSymLinks
  # This is needed to parse /var/lib/roundcube/.htaccess. See its
  # content before setting AllowOverride to None.
  AllowOverride All
  order allow,deny
  allow from all

# Add these lines just after the "allow from all" within
# the <Directory /var/lib/roundcube/> block.
# Lines below this (within this Directory block) are custom.
  <IfModule mod_rewrite.c>
    <IfModule mod_ssl.c>
      RewriteEngine on
      RewriteCond %{HTTPS} !=on
      RewriteRule ^.*$ https://%{SERVER_NAME}:%{SERVER_PORT}%{REQUEST_URI} [R,L]
    </IfModule>
  </IfModule>
  <IfModule suphp_module>
    suPHP_Engine Off
    AddHandler php5-script      .php
  </IfModule>
  php_admin_value open_basedir "/usr/share/php:/etc/roundcube/:/usr/share/roundcube:/var/log/roundcube:/var/lib/ro$

</Directory>

# Protecting basic directories:
<Directory /var/lib/roundcube/config>
        Options -FollowSymLinks
        AllowOverride None
</Directory>

<Directory /var/lib/roundcube/temp>
        Options -FollowSymLinks
        AllowOverride None
        Order allow,deny
        Deny from all
</Directory>

<Directory /var/lib/roundcube/logs>
        Options -FollowSymLinks
        AllowOverride None
        Order allow,deny
        Deny from all
</Directory>

It redirects to my Spiceworks server (running on port 443) asking for the /webmail directory/link

I have the following:

Spiceworks port 443
Webserver port 80
Roundcube port 50443
ISPConfig port 50443

Ok so I have found out the following:

1. If I change my portforwarding for 443 to the webserver (X.X.X.5) it works. I can type in www.example.com/webmail and it finds roundcube. However I was hoping that the redirect would force the URL to change to www.example.com instead of www.clientsdomain.com/webmail and therefore having no certificate errors.

2. If I leave that my spiceworks server isn't accessible via the www.example.com/help anymore. It doesn't get access rather redirects to my website in https.

I would like to have roundcube and spiceworks all available of port 443 however I need to portforward 443 to the webserver and then how do I access spiceworks?

Seems so close yet so far... argh...

 

Ahh, oops, my bad . I forgot what we were trying to do for a moment.

For the sake of clarity, does the following list include all of your requirements?

How can I:

1.) Redirect www.everyclientsdomain/webmail to www.mytrusteddomain.com/webmail, so that the client's domain is used?

2.) Require SSL for webmail, while avoiding "Domain Mismatch" certificate errors (e.g., by using a unique and valid certificate for each domain)?

3.) Redirect requests for www.example.com/help to the Spiceworks server, i.e., www.example.com:443?

If so, then I will point you in the right direction.

Also, before I forget, what happened with the open_basedir line? It ends with "/var/lib/ro$". Is it like that in the actual file? Or did this forum butcher it somehow?

 

LoL I probably should have realized myself... its all good

1 and 2 are correct but 3 is a little more difficult.

3.) Redirect requests for www.example.com/help to Spiceworks server on same internal network X.X.X.7 with SSL enabled. So yes https://www.example.com/help actually points somehow to https://X.X.X.7

Basically I would love to have www.anyhosteddomain.com/webmail (on server X.X.X.5 - the ISPConfig Server (only 1)) redirect to force SSL https://www.mycertifiedserver.com/webmail (running on port 443). Then I also would like www.mycertifiedserver.com/help to redirect to https://www.mycertifiedserver.com (spiceworks server X.X.X.7, running on port 443)

So I have 2 servers but I want to use the same certificate.

Currently if I put into the URL - www.mycertifiedserver.com/webmail it redirects to https://www.mycertifiedserver.com:50443/webmail which I can change to 443 once I portforward to server X.X.X.5

I portforward to server X.X.X.7 (spiceworks) which responds after the rewrite www.mycertifiedserver.com/help changes it to https://www.mycertifiedserver.com/portal (portal is automatic once the request goes through to the spiceworks server)

It doesn't sound clear but I don't know how else to say it. I might if I have time make up a drawing.

Sorry Ben I have NO idea what this is or where to find it. It was in the code that you told me to put in but I have that hashed out ATM due to it not working. Is it meant to be found in the roundcube.conf file or someplace else?

Cheers mate,
Steve

 

Actually, I noticed a mistake in #1 . I meant to say:

Redirect www.everyclientsdomain/webmail to www.mytrusteddomain.com/webmail, so that only your domain is used?

This is quite different from what I had stated previously.

Let's go for the low-hanging fruit first (#1 and #2). Let's also tackle one issue at a time, so that we know when new rules are affecting existing rules.

The code I posted at http://www.howtoforge.com/forums/showpost.php?p=271943&postcount=26 really should work for #1. I did notice, however, that we forgot the port number... I keep forgetting that Spiceworks is running on 443 and Apache on 50443.

Code:

<IfModule mod_ssl.c>
  SSLOptions +StrictRequire
  SSLRequireSSL
  SSLRequire %{HTTP_HOST} eq "www.mytrusteddomain.com"
  ErrorDocument 403 https://www.mytrusteddomain.com:50443/webmail
</IfModule>

Try adding this rule to the <Directory /var/lib/roundcube/></Directory> block, and ensure that all of the mod_rewrite rules are commented-out. Also, be sure that any <IfModule></IfModule> blocks are correct and relevant.

If your client hits the Webmail URL at his own domain, e.g., www.everyclientsdomain/webmail, and the request is made over SSL, he will receive a warning unless a "proper" certificate for the client's domain is installed. This point is at the heart of what makes my revised #1 different from my original #1.

It's crucial to understand that SSL handshakes happen before anything else, which means that an SSL certificate error will arise before any redirection can happen.

There is nothing you can do to "prevent" people from accessing www.everyclientsdomain/webmail over SSL -- short of disabling SSL for the domain, in which case attempts to connect over SSL will simply fail.

Two important points of note:

a.) The www matters in the Apache directives above. So, if you are doing any kind of automatic www redirection, via ISPConfig's Sites -> Domain -> Redirect [tab], or Sites -> Domain -> Domain [tab] -> Auto-Subdomain, those settings could affect the rules that we're creating.

b.) You shouldn't mix LAN IP addresses and FQDNs (fully-qualified domain names) within your configuration. Given that your SSL certificate is issued to the FQDN (e.g., www.mycertifiedserver.com), you must use that FQDN wherever SSL in concerned (including to access the Spiceworks server).

Try this for #1, and I'll post re: #2 once that's working.

 

Ahh, #2 was predicated on the assumption that you intended to have proper SSL certificates at each client domain. If that is not your intention, then #2 is irrelevant.

So, onto #3 instead.

Use the sample code I provided in an earlier post. (I have corrected the port number to match your current [not to be confused with your ideal] setup.)

Code:

# Redirect requests for the /help URL (on the Apache Webserver) to Spiceworks server.
# (MUST USE FQDN, not LAN IP).

Redirect permanent /help https://spiceworkserver.com:443

Code:

So I have 2 servers but I want to use the same certificate.

That's fine. It's done all the time. You will simply have to configure Spiceworks to use that certificate, if you haven't done so already. I know nothing about Spiceworks, so I can't help you there.

Code:

Sorry Ben I have NO idea what this is or where to find it. It was in the code that you told me to put in but I have that hashed out ATM due to it not working. Is it meant to be found in the roundcube.conf file or someplace else?

I'm referring to the line that I told you to add at the end of the <Directory /var/lib/roundcube/></Directory> block (in /etc/apache2/conf.d/roundcube, which is just a symbolic link for /etc/roundcube/apache.conf) at the bottom of this post: http://www.howtoforge.com/forums/showpost.php?p=272138&postcount=32

I just checked the original post and the text is correct there, so I'm not sure how the butchered text made it into your file. Please double-check that, even though the line is commented-out for the moment.

 

Added that, followed your instructions and the browser complains about endless redirects. My log file contains this:

Code:

[Mon Jan 30 09:40:20 2012] [error] [client 203.173.29.25] access to /var/lib/roundcube failed, reason: SSL requirement expression not fulfilled (see SSL logfile for more details)

This is fine I don't think many people will try to put in the SSL url everyone loves simple - i do at least.

As for a) I do have automatic www turned on in ISPConfig but does that matter if people add the www.theirdomain.com/webmail ?? i could see it being a problem for theirdomain.com/webmail... but I might be mistaken.

As for b) The only reason why I put in IP's is because if I put in the FQDN the certificate mismatches. I have a certificate for www.mytrusteddomain.com only not for spiceworks.mytrusteddomain.com or any other ... oh except mail.mytrusteddomain.com so that SSL connection doesn't pop up with that annoying "this server isn't trusted" message.

Here is the most recent test of roundcube.conf file that doesn't work:

Code:

# Those aliases do not work properly with several hosts on your apache server
# Uncomment them to use it or adapt them to your configuration
#    Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
Alias /webmail /var/lib/roundcube

# Access to tinymce files
<Directory "/usr/share/tinymce/www/">
      Options Indexes MultiViews FollowSymLinks
      AllowOverride None
      Order allow,deny
      allow from all
</Directory>

<Directory /var/lib/roundcube/>
  Options +FollowSymLinks
  # This is needed to parse /var/lib/roundcube/.htaccess. See its
  # content before setting AllowOverride to None.
  AllowOverride All
  order allow,deny
  allow from all

<IfModule mod_ssl.c>
  SSLOptions +StrictRequire
  SSLRequireSSL
  SSLRequire %{HTTP_HOST} eq "www.mytrusteddomain.com"
  ErrorDocument 403 https://www.mytrusteddomain.com:50443/webmail
</IfModule>

</Directory>

# Protecting basic directories:
<Directory /var/lib/roundcube/config>
        Options -FollowSymLinks
        AllowOverride None
</Directory>

<Directory /var/lib/roundcube/temp>
        Options -FollowSymLinks
        AllowOverride None
        Order allow,deny
        Deny from all
</Directory>

<Directory /var/lib/roundcube/logs>
        Options -FollowSymLinks
        AllowOverride None
        Order allow,deny
        Deny from all
</Directory>

#<IfModule mod_rewrite.c>
#  <IfModule mod_ssl.c>
#    <Location /webmail>
#      RewriteEngine on
#      RewriteCond %{HTTPS} !^on$ [NC]
#      RewriteRule . https://%{HTTP_HOST}:50443%{REQUEST_URI}  [L]
#    </Location>
#  </IfModule>
#</IfModule>

So far I have successfully implemented part of what I was hoping to do.

1) www.mytrusteddomain.com/help redirects to my Spiceworks server with SSL set. So I believe that works just dandy.

So now all I need is the redirect of www.clients.com/webmail to www.mytrusteddomain.com/webmail and I am out of your hair

Sorry about the delay I have been very busy of late.

Regards,
Steve

 

This behavior seems to indicate that SSL is not available for, in our example, www.mytrusteddomain.com:50443.

The endless redirection can happen only if the SSL requirement is never met. The only way the requirement would never be met is if the document to which the user-agent (browser) should be forwarded upon non-SSL connection is not SSL-enabled.

This rule

Code:

SSLRequire %{HTTP_HOST} eq "www.mytrusteddomain.com"
ErrorDocument 403 https://www.mytrusteddomain.com:50443/webmail

says, "If SSL is not enabled, or if the requested domain is not exactly www.mytrusteddomain.com, respond with the 403 HTTP status code (forbidden) and send the user to the specified error document, https://www.mytrusteddomain.com:50443/webmail."

To reiterate, the only way that a loop could result is if https://www.mytrusteddomain.com:50443/webmail is not secured with SSL.

If you just punch the URL into your browser, https://www.mytrusteddomain.com:50443/webmail , does the Webmail interface load over SSL?

I'll address your other questions once we've ironed-out this issue.

 

When I have what you have listed enabled I cannot access even via inputting into the URL https://www.mytrusteddomain.com:50443/webmail

I think you might be on to something here. I recall that it does redirect if I go to www.otherdomain.com/webmail to the https://www.mytrusteddomain.com:50443/webmail

So maybe SSL isn't enabled. Except I have ticked the SSL box on my default website which is the certified website and also the one I use to access ISPConfig.

Very interesting I must say