Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a centos6 VPS with cpanel/whm, I re-sell the webspace to clients that i do IT work for. Im wondering if such a ssl certificate exists that i would be able to stop the warning my clients see when visiting there individual webmail url's like '' and ''

I'm getting an ssl certificate for the VPS's domain ( so that my clients can use a proper ssl connection with email and i'm wondering if i can do anything to fix this in one motion.

share|improve this question

SSL certs are issued on a domain basis. If all of the domains you wish to secure are under the same domain (,, etc.), then you can get a wildcard cert that can serve * If they are in different domains, though, then you will need to obtain separate certs for each domain.

share|improve this answer
Or, you can get a certificate with a ton of SANs, if you need to run them all on the same host. – Falcon Momot Nov 11 '13 at 20:51


The wildcard cert is now installed and working properly for all clients accessing Webmail, cPanel, and directing their mail clients incoming/outgoing servers to the host domain for dovecot access. We have decided there is no reason to try to re-direct other protocols outside of HTTP, so all customers will be redirected to for IMAP/POP3.

For anyone wanting to do the redirect(s) manually, here is the info from .htaccess: ------------BELOW------------

RewriteEngine on

Options -Indexes

RewriteCond %{HTTP_HOST} ^$ [OR]

RewriteCond %{HTTP_HOST} ^$

RewriteRule ^/?$ "http\://" [R=301,L]

RewriteCond %{HTTP_HOST} ^$ [OR]

RewriteCond %{HTTP_HOST} ^$

RewriteRule ^/?$ "http\://" [R=301,L]



So I figured this out by testing with a temporary Comodo trial cert for our domain. I am now able to type in a client's address (no need for http or https) and it resolves to our SSL without a warning in any of the major browsers. Since we have multiple forced SSL login areas, we will purchase a * wildcard cert to cover our server management as well as any clients utilizing Webmail, cPanel, etc. (FYI, it looks like name cheap has the best pricing for wildcards at $100 (Comodo EssentialSSL) to $127 (GeoTrust RapidSSL) per year). A UCC would be considerably more costly due to the multiple subdomains for each client on top of our own.

I still want to test options for IMAP, POP, & SMTP Relay connectivity, but in the end we may just have new clients begin using our on localized email software & mobile devices since users could probably care less about a hidden setting (set & forget). Existing clients could just be migrated as needed.

Steps taken on CENTOS 5.10 with WHM 11.40.0 (build 26)

If anyone sees a problem with this setup in regards to flow, overhead, security, etc, please let me know.

  1. Create your CSR in WHM and then install a WHM/cPanel cert for the host domain (I recommend testing with a single domain free trial cert. Don't forget to use your FQDN for the desired service ( instead of www. Then just go out and get your wildcard after everything is working. - Comodo offers a 90 day trial which was nice, even though it ended up taking <90 minutes to complete the test)

  2. The cert was installed in the host domain's cPanel under "TLS/SSL Manager", and then applied to all the services under WHM's "Manage Service SSL Certificates". My understanding is that the new cert needs to be applied to all the listed services since they all share the same IP. Otherwise your browser may pull the original/self-signed cert instead and cause the reliability of tests to falter. In the end, they will all end up having the wildcard anyhow.

  3. We originally had "Always redirect to SSL" enabled under WHM's Tweak Settings, but for this project to work I had to disable the setting. Next I chose "Hostname" for "Non-SSL redirect destination", and "SSL Certificate Name" for "SSL redirect destination". I cannot remember if another redirect setting for HTTP to HTTPS was already enabled somewhere else in the WHM system, but will dig if someone needs me to.

  4. In the client's cPanel, go to Subdomains and create your webmail subdomain and then create a redirection to your host's webmail address in the same area: w/ Document root being "/public_html/". Because HTTPS is already redirecting for these services, mine simply ended up having for the redirect.

  5. Go verify your DNS. There will be a couple new subdomain related entries, and the original webmail A record should still be pointed back to the primary IP.

  6. Test. I had to restart a browser and empty the cache in another before it pulled in the new cert. Also, in order to avoid any false positives, make sure you go into the browser and remove any previously accepted untrusted certificates pertaining to the client domain(s) you are testing! Firefox still allows you to view an untrusted cert before continuing on to the destination which is nice for this process if you want to quickly see which cert is being pulled in. Untrusted certs in IE & Chrome are only viewable after you go past the warning.

Final thoughts:

With our server we want all client management access to be through SSL only, so this will be a standard setup for each account's cpanel subdomain as well. Many of our clients have already moved to Office 365 or have on-site Exchange, so I do not foresee a huge hassle for the rest when making quick cPanel entries (or editing .htaccess) & then quickly testing. We keep a setup checklist for new customers so adding these webmail & cpanel redirects to the list will only add a few seconds during initial setup.


I was completely wrong about using the CNAME method below. CNAME will not "redirect" one domain to another properly for SSL. I am currently looking into .htaccess & other programmed redirects for subdomains, and will post back if they work for this purpose. Otherwise, I think my team will have to go with a UCC on the root VPS domain that covers the necessary clients, or get each client a static IP with their own wildcard certs. Not a desirable cost for many, but quite a few are complaining about SSL warnings. As vortaq7 pointed out, our clients also do not want to type in our primary webmail domain instead of their own.

Original Post

I cannot leave a direct threaded reply/comment yet, so in reply to vortaq7... John was a little vague, but I took his meaning to be:

Create a "webmail" CNAME record in the client's DNS which points back to your VPS's primary webmail login url: > CNAME >

The SSL login would then be be covered under the VPS's primary wildcard or UCC cert. Further, the client only needs to type in their own domain ( and may never even notice the redirect to the VPS's primary ( Even if they do notice, it shouldn't matter for anyone who isn't willing to shell out for their own domain cert.

share|improve this answer

Get the cert, and steer them to your domain, not theirs, for their webmail.

share|improve this answer
This is a less-than-ideal solution for a bunch of reasons, the two big ones being that users vastly prefer to as a domain name, and dislike having to type their email domain name in order to log in (though they're becoming more accepting of the latter). – voretaq7 Nov 11 '13 at 17:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.