My web host does not support Let's Encrypt, but says I can install manually via cPanel... help!


My website ( is hosted on a Midphase shared server, and I want to add some basic free SSL certification - just to make it safer for users registering for the small forum that runs on there, no commercial or other sensitive data.

I spoke with Midphase Support, and they said they don’t directly support Let’s Encypt (only their own paid SSL services) but that I can install the certificates manually via cPanel if I want. I do not have root/admin access to cPanel, only to my own website files on the server, so I’ve no way to set up the automated bot.

I’m looking for a nice simple set of step-by-step instructions as to how to do this on my Windows PC. I have been able to generate a Private Key and a Certificate Signing Request via the online cPanel > SSL/TLS menu, but I’ve no idea how to then get the actual certificate part that I need to copy back to the server.

I have tried searching this site and the community here, but not found anything that makes very much sense to me so far. Any pointers would be appreciated! Thanks.



Hi @andrewilley,

You may find Let’s Encrypt inconvenient to use if you can’t automate the certificate renewal process. Remember that our certificates only last for 90 days. Most people in your situation have used a web-based client like (which replicates something like the experience of using a conventional paid CA, but without requiring payment). However, they’ll then have to repeat the process frequently.

The client application has some API support for cPanel so if your hosting provider deliberately won’t allow you to use the existing automated certificate support in cPanel, you might be able to use this method and still get automated renewal:

In that thread @Patches pointed to

which explains how to do this.


As far as I know, I don’t have any SSH access to cPanel on the shared server.

When you say “repeat the process every 90 days”, do you mean just request and install an updated copy of the certificate (as in with a few clicks) or go through the whole generate Private Key, CSR, etc. stage again?



If you don’t have SSH access, I guess that method won’t work. :frowning:

You can potentially reuse the private key and CSR, but you would have to request a new certificate using those files. There’s no way to extend the lifetime of a previously-issued certificate.


Well I gave a try, and that seemed pretty painless.

I first tried to use the ‘Public Key’ that my webserver’s cPanel had initially generated for me, but that failed (so I assume I only needed that to create the CSR initially, but nowhere else?). So I then let zerossl generate a new ‘Let’s Encrypt Private Key’ for me, and that seems to have worked fine with the ‘Certificate Signing Request’ that I had already created in cPanel.

I then created the unique authentication textfile in .well-known\acme-challenge\ as requested, and zerossl seemed happy with that and created a ‘Domain Certificate’ for me.

Finally I copied that Domain Certificate (just the first section) back into the SSL Tool in my website’s cPanel, and let it autofill the rest, and it seemed happy with the result. Initially I thought it hadn’t worked, but after half an hour I tested it again and now seems to be working with the Let’s Encrypt certificate.

Thanks for the pointer to zerossl, as that seems to have made the process pretty straightforward with no messing around with Unix command lines.

Just to check though, when I need to renew, all I need to do is use the same Let’s Encrypt Private Key (which I saved) and the same Certificate Signing Request that I’ve already used, yes? Will I then need to create a new updated authentication file in .well-known\acme-challenge\ , or will the exiting one still work and all I would need to do is install any newly generates Domain Certificate onto my webserver via cPanel?



Hi @andrewilley,

Several things :wink:

Your domain is using Cloudflare (I see your dns servers don’t point to cloudflare but you have defined a CNAME pointing to to and that means you are using a Cloudflare paid plan (Business or Enterprise level). Maybe you are not aware of this and is something included in your hosting plan :?

I’m saying that because your domain has already a certificate issued by Comodo because you are using Cloudflare as a CDN for this domain and maybe you don’t need a Let’s Encrypt certificate.

I’ve no idea if you configured that cloudflare stuff or not so I don’t know whether the connection from cloudflare to your real server is using https, but if it is using https, you could configure cloudflare to use flexible ssl (maybe it is already configured this way) and just create a self-signed certificate with a validity of 1 year and you don’t need to worry about renewing the cert every 90 days.

If you know nothing about what I’m talking about, then you should ask your hosting provider how is your site configured.

Right now, doesn’t matter whether you are installing a LE certificate in your Control Panel or not, your users connecting to your forum will have a TLS connection provided by cloudflare and the certificate issued by them.

Note: Keep in mind that the cloudflare configuration is covering only but not so trying to access it will give you a certificate validation error.



@sahsanu Thanks for the reply. Accessing already redirects to, and has done for some time, just to make site usage more consistent.

Yes, my hosting company provides Cloudflare as part of the standard hosting package, but only the free version. That seems to give basic SSL just as far as Cloudflare, but not actually onward to my own site (which still sees http traffic). I did try using their free SSL access a bit ago, and while it seemed to work fine to start with, as soon as I tried to force all traffic over to HTTPS (via 300 redirects in .htaccess) I started getting “too many redirect” errors after a day or two.

After the changes I made today, when I visit my site (even with Cloudflare running) I see the certificate details in the browser showing as LE and the sitename, rather than Cloudflare which I saw before.



To avoid loops, those redirects should be configured in cloudflare instead of directly in your web server vía .htaccess file.

I’m sorry but the certificate that I can see is the one issued by Cloudflare (Comodo):

$ openssl s_client -connect -servername 2>/dev/null </dev/null | openssl x509 -noout -text | grep -Ei '(issuer:|dns:)'

Issuer: C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Domain Validation Secure Server CA 2, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*, DNS:*,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,



It’s weird, on my mobile I see the Comodo (Cloudflare) certificate still. However on my PC (I’ve tried several browsers) I see Let’s Encrypt.

CN = Let’s Encrypt Authority X3
O = Let’s Encrypt
C = US
‎11 ‎May ‎2018 08:46:18 - ‎09 ‎August ‎2018 08:46:18
CN =

[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (
Alternative Name:
[2]Authority Info Access
Access Method=Certification Authority Issuer (
Alternative Name:


s/n 04:44:BB:3F:8F:14:EC:3D:F0:2E:E7:0A:2E:D1:86:6C:DF:F8

To be honest, if I plan to be using SSL on my webserver then I’m not sure if there’s any point in using Cloudflare anyway - I thought its main job is to optimise and cache the content served, and if that content is secured end-to-end then surely it shouldn’t be able to intercept and do that anyway?


#10 and point to totally different IP addresses. This is probably the reason for the discrepancy.


This is all correct and you would need to create a new updated authentication file every time.


CloudFlare can intercept HTTPS content because it can issue certificates of its own for domain names that are pointed at it. In most configurations, that’s exactly what it does—automatically!

You could view this as great (because you still have HTTPS and CloudFlare) or unfortunate (because CloudFlare can see what you and your users are communicating) depending on your particular priorities. :slight_smile:


The www version is the one I use. Any shorter references that someone may type are redirected via .htaccess to

So how do I now force https page serving? The Cloudflare control panel that is supplied by Midphase does not include any forced secure options, so is it now safe to use a redirect in .htaccess (now that the server is presumably using SSL to communicate with Cloudflare)?



I’m not sure, but I guess CloudFlare would forward that redirect along to end users.


My current rewrite rule in .htaccess was just to force “www.” in case someone tried plain This is done with:

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

I’ve read seemingly a million slight variations on how to force https too, and the following is what I’ve just implemented:

RewriteEngine on
# ensure www.
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# ensure https
RewriteCond %{HTTP:X-Forwarded-Proto} !https 
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Seems to be working so far anyway - I hope I don’t get another “too many redirects” loop.



Spoke too soon. With the Cloudflare option (included in my Midphase hosting plan) turned on, content that directly refers to old http: links (such as embedded images in users’ forum posts, which have to be inserted as absolute links rather than relative links like the main site code) was starting to throw up Too Many Redirects errors again.

I’m sure this is Cloudflare’s fault, so I’ve disabled it for now and most browsers are now coping normally (after a bit of a stressful delay where I was getting nothing but 1016 errors from Cloudflare even though it was meant to be turned off!). Now I’m seeing my own Let’s Encrypt certificate in all browsers, and the redirect from http: to https: is working.

So… how do I re-enable Cloudflare now I wonder? I do find it improves several performance things, including image loading times.



I think maybe the X-Forwarded-Proto doesn’t have the effect that you want. Maybe you should disable this redirection for now and look for guides about how to do this behind CloudFlare.

You could help users with some modern browsers by setting the update-insecure-requests policy.

This policy should help upgrade the HTTP requests from those browsers without causing a redirect loop.


Thanks for the tip, I’ve added
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
to my global headers file, and that seems to be happily redirecting all of the older (fully-qualified URL) “http:” images from the phpBB forum posts (which also generates the news pages) to the secure versions. That will save me a lot of messing about, even though as you say not all browsers support it. Otherwise, all of the internal links and images within the site use relative URLs anyway, so as long as the overall pages start out as https: in the first place, then all the other underlying content will be too (apart from the phpBB sourced stuff).

All of the guides to doing redirection with Cloudflare talk about an option which is not provided in Midphase’s Cloudflare control panel, and I don’t have a regular login for Cloudflare’s own site to do it from there.


closed #19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.