Installing an SSL certificate in Plesk and moving the site to HTTPS
By Datafex Engineering TeamPublished 5 min read
Installing the certificate is the easy half of the job; actually running the site over HTTPS is the other half. On most sites that still show a "not secure" warning despite having a certificate, the problem is not the certificate but the redirect and the mixed content left behind. The order below is the one to follow on the Plesk-based web hosting plans.
Check this first: does the domain point at the server?
The validation mechanism behind free certificates proves that the domain is yours by reading a file over that domain. The practical consequence is this: a certificate cannot be issued before the domain points at the hosting server. On freshly migrated sites this is the most common mistake — the certificate is requested while DNS still points at the old provider, the request comes back with a validation error, and the certificate gets blamed.
The correct order is: DNS record first, then the certificate, then the HTTPS redirect. We covered the DNS side step by step in pointing a domain at your hosting.
Installing the certificate
You enter the panel with the Open Plesk panel button on the service detail page in your customer panel; there is no separate Plesk password to type, and the button drops you straight onto the screen that lists your domains.
- Open the SSL/TLS certificates section on your domain's card.
- Start the free certificate option; SSL is included with the plans, so there is nothing extra to buy.
- Choose which names the certificate should cover: the domain itself, the www form, and the webmail address if you use it.
- Subdomains are listed on their own cards, and a certificate has to be requested separately for each of them.
- When the job finishes, confirm on the same screen that the certificate is assigned to the domain; being installed on the server and being used by that domain are not the same thing.
Issuance takes a few seconds. If it does not complete, read the error text to the end: it almost always names the step where validation stopped, and retrying without that information is wasted time.
Do not leave www out of the certificate
Do not assume your visitor omits www in the address bar. If the www form is not on the certificate, anyone arriving at that address sees a security warning — and you will not notice, because you open the site at the address you are used to. Put both names on the certificate, then redirect one to the other so that visitors and search engines all see a single address.
Forcing HTTPS
Once the certificate is in place the site still answers on both HTTP and HTTPS; the old address does not close by itself. Turning on the permanent 301 redirect option in the domain's hosting settings moves HTTP requests to HTTPS for good. The redirect being a 301 matters: a temporary redirect does not tell search engines the address has changed permanently, and the two addresses keep getting crawled separately for a long time.
Mixed content: the page is HTTPS, the images are not
If the padlock still does not appear after the redirect is on, this is usually why. The page itself loads over HTTPS while an image, a font or a script inside it is still requested over an unencrypted address, and the browser treats the whole page as insecure. Your browser's developer console names each offending address. On WordPress those addresses usually sit in the site address setting in the database and inside older posts; we explained why that change should not be made with a manual search and replace in the WordPress hosting guide.
Renewal is automatic, but not silent
Free certificates are short-lived and the panel renews them before they expire. There is one common way for renewal to fail quietly: the domain no longer points at this server. If you repointed DNS elsewhere and left the hosting plan running, the next renewal attempt stops at validation, and you only find out when the certificate expires. Checking the certificate date in the panel once after a large DNS change catches this before anyone else sees it.
The certificate is installed but the browser still shows the old one
Seeing the old warning right after installation is normal; browsers hold certificate and redirect information in their own caches for a while. The right check is to open the site in a private window and, if you can, from another device. If the problem persists on one device only, it is that device's cache and not the certificate.
There is one exception: on a domain that has previously enforced HTTPS, the browser will not fall back to plain HTTP even when the certificate is broken, and shows the user a warning they cannot click past. That is why verifying that the certificate really works before turning the forced redirect on is easier than fixing it afterwards.
Three frequent mistakes
- Requesting the certificate before DNS. Validation happens over the domain; the order does not bend.
- Leaving www out of the scope. You are not the one who sees the warning — your visitor is.
- Turning the redirect on without fixing mixed content. The address becomes HTTPS, the padlock does not arrive, and the browser refuses to load some resources at all.