There are several ways to make two domains resolve to the same content in Plesk. The easiest option is to setup a Domain Alias. That way, domain1.com and domain2.com both serve the same content from the same subscription.
This worked great for non-SSL domains, but if you have a secured domain, the redirection will be detected by modern browsers and a certificate warning appears. Not what we want.
Another way to achieve the same thing is to create a separate subscription in Plesk, then change the Hosting Settings to Forwarding. This will result in a search engine friendly 301 redirect, but again we have that certificate issue to deal with. Since the redirected domain no longer has its own file structure, the Let’s Encrypt extension is unable to issue a separate certificate for the second domain. Not good either.
The solution, it appears, is a manual addition of a piece of code to the NGINX directives. This will only work if NGINX is enabled in your Plesk setup (it is by default as of Plesk Onyx). Let’s see how to do it.
Step by Step Instructions
Create a new subscription for the domain you’d like to redirect. In our example, let’s use new-domain.com as the current domain that has a subscription, but you’ve got another domain you want to redirect to the above. Let’s call that one old-domain.com. This domain needs its own subscription in Plesk. Don’t worry about adding any content there.
Once setup, head over to Websites and Domains is the subscription and select Apache and NGINX Settings.
Towards the bottom of this ever so slightly intimidating list we’ll find an empty field into which we can add our own code, under Additional NGINX Directives.
We’ll add the following to this box, replacing old-domain.com with the domain you’d like to redirect to. In essence, this is telling NGINX to use the location in brackets for the top level location of our current domain. Here’s a cut-and-paste friendly version:
And that’s it! Now your new domain will redirect to the old domain, while retaining all SSL properties. There’s no need for a new certificate either, and search engines will make a note when the bot comes crawling the next time. Furthermore, all deep links will be retained that way too.
In this episode I’ll explain how to add a free SSL Certificate for web traffic in Plesk Onyx.
First we’ll enable the Let’s Encrypt extension in Plesk, then we’ll create the certificate and prepare our subscription for SSL traffic. And finally, we’ll tweak two values in the WordPress database so that all requests will be directed to https rather than http.
Note that Let’s Encrypt SSL Certificates can only be used to encrypt web traffic between your server and a client’s browser. They cannot currently be used to secure email or Plesk itself (but who knows what the future holds).
I’ve just installed the Dovecot Mail Service on one of my Plesk 12 servers. It’s an alternative to the old favourite Courier IMAP/POP and a new addition in Plesk 12.
Dovecot does more or less the same as Courier (i.e. lets you receive mail), but it’s a bit more configurable and debug friendly. It also offers server-side mail filtering which is accessible via the Plesk Webmail services Roundcube and Horde.
In this article I’ll show you how to install Dovecot in Plesk 12, and how to add your own SSL certificates for mail. In my previous article I’ve explained how to do this with the standard Courier Mail service.
Installing Dovecot in Plesk 12
Head over to
Tools and Settings (or the Server Tab)
under the Plesk heading
Updates and Upgrades
Select Add or Remove Components and under Mail Hosting Features, find the option for Different IMAP/POP3 server:
You can only install either Courier or Dovecot. Switching will automatically uninstall the component you currently have and instead install the other one.
Note that switching Courier for Dovecot will preserve all mailboxes and will not affect your outgoing mail services. Give Plesk a moment until your see the “installation has finished” message.
You’re now running Dovecot!
Patching Dovecot SSL Certificates
As with Courier, Dovecot will use self-signed certificates for secure connections. This means that a nasty window is likely to pop up when clients connect. You can suppress this window by specifying your own SSL Certificates.
The default configuration file for Dovecot is in /etc/dovecot/dovecot.conf. However the file states that any changes you make here are wiped when an upgrade comes along. Instead, take a look at the /etc/dovecot/conf.d/ directory in which you’ll find three files by default:
You can add your own configuration snippets here, each beginning with a number and ending with .conf. The lower the number, the earlier your snippet is loaded. The higher the number, the later it is loaded. You get the picture.
Let’s create /etc/dovecot/conf.d/5-ssl.conf for our purposes. Because I had already configured my certificates for Courier they are still in /usr/share/imapd.pem – but feel free to place your .pem files anywhere you like. Here’s what my file looks like:
# SSL Certificates for Dovecot are defined here
# Path to your Certificate, preferred permissions: root:root 0444
# Path to your Private Key, preferred permissions: root:root 0400
Dovecot lets you have separate files for the certificate and the private key, something that’s not possible in Courier as far as I know. Dovecot is also happy to keep those in the same file though as in my example, and as in Courier. Easy going I say!
For the changes to take effect we need to restart the Plesk Mail Service like so:
You’ve installed an SSL Certificate to secure your Plesk Panel, you’ve tested it with an SSL checker and sure enough: the ugly warning window doesn’t bother you or your customers anymore.
But your email client still says that the server doesn’t have a valid certificate. What gives?
The secret is this: SMTP, IMAP and POP3 use their own certificates which are not related to the ones you setup in Plesk to secure https connections. By default the mail services use auto-generated self-signed certificates.
Sadly as of Plesk 12 there is still no way to manage those in the web interface – but it’s relatively easy to fix on the command line. Let’s go through this step by step.
These instructions are for Plesk 12 on CentOS 6 and CentOS 7, using the default Courier mail service. You can also install an alternative mail service called Dovecot in Plesk 12. I’m discussing how to install Dovecot over here.
We need to replace the following three files (default permissions in brackets):
Those are the culprits for SMTP, IMAP and POP3. We need to add our own private key and the certificate of a domain associated with this server and remove the default certificates.
Before we begin, make a safety copy of them like this:
And that’s it! Now that pesky warning isn’t going to come up anymore when you access Plesk mail with an email client.
Adding CA Certificates
The above is enough to suppress the usual warning windows in email clients, however if you’re an avid SSL enthusiast you’ll notice that we’ve not added any CA Certificates to the above .pem files. In essence those tell a client that our certificate is valid – otherwise the client would only have our word for it.
You can add the combined CA Certificate to the end of the three .pem files in addition to the private key and your own certificate. It’s not strictly necessary, but doing this means you will pass strict SSL tests.
Simply hack in your email address and you’ll see if your certificate is installed properly. Note that to pass the test, your email address must match the domain on the certificate. For example, if your address is email@example.com, but your certificate is for yourdomain.com then the test will fail the “Cert OK” field.
Wait – where do I find my private key and certificate?
If you’re using the same certificate for mail that you’re using to secure Plesk, simply head over to
Tools and Settings (or the Server Tab)
click on your certificate from the list
scroll down to find plain text sections for your private key and certificate
Wait – where do I find that CA Certificate you speak of?
Your certificate provider will give that to you. Some providers call it “intermediate CA certificate”. They usually have several versions of the same thing. Look for a combined version. In essence it’s two plain text blocks, very similar to the ones I’ve shown you above.