My domain is:
I ran this command:
sudo certbot --apache -d c -d
It produced this output: see:
My web server is (include version): Apache 2.4.18
The operating system my web server runs on is (include version): Ubuntu 16.04.4
My hosting provider, if applicable, is: digitalocean
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no
Which aspect of it doesn’t work? Your site is sitting behind the Cloudflare SSL proxy, so on the face of it, everything seems fine.
You are right about that. I’ve disabled the cloudflare SSL about an hour ago to see whether or not let’s encrypt works and that almost broke my site. For some odd reason, logging into user accounts is still impossible and the shop software doesn’t allow me to enable ssl again because it can’t verify that it works. Those however aren’t the problem.
The problem is, that, if you ignore ssllabs.com’s analysis of the domain, https doesn’t work anymore as soon as I’ve disabled cloudflares ssl. Which lead me to assume that the let’s encrypt ssl certficicate doesn’t work. It’s easier to see on the linked image. (as in, the image is hosted on that domain. So if you open it in the browser, you can actually see that despite using https, the connection is insecure.
If you now check ssllabs.com again, you’ll see that it doesn’t quite work 
What did you do to achieve this?
If you want to see Let's Encrypt certificates in the browser rather than Cloudflare's certificates, then you need to totally disable Cloudflare by making sure none of your DNS records have the "orange cloud" enabled on them. After that, you'll need to wait for your DNS records to update from the Cloudflare proxy to your actual server's IP address:
If you disabled Cloudflare SSL in any other way, then yes, it would mess your site up.
OK, so I see you disabled it the right way.
Apache doesn’t seem to be listening on port 443 at all. Which is strange, because Certbot should have setup an HTTPS listener if you ran the command you said you did.
Can you please show the output of:
apachectl -SHere you go! That’s the pic
It should be listing a port 443 namevhost as well, but it isn’t 
.
Can you try your original command again:
sudo certbot --apache -d x -d www.x
It should state that a certificate already exists, and ask you whether to re-install it. You should say yes.
The output of the command should indicate that it’s installing the certificate to Apache.
If not, please show what it says.
That might be related to me using digitalocean’s own firewall.
I’ve reinstalled the cert but it gave me an odd ‘error’ message. Screenshot will follow.
Well, I can’t add another, so here’s a link.
Hence, the www. one seems to not have worked.
You’ve posted the same link/image twice.
In any case, I don’t think it’s a firewall issue, as your Apache config corroborates the symptoms.
Updated the link.
So, how do you’d suggest to go about this?
Can you show me these lines from your x.conf:
<VirtualHost ???????:80>
ServerName x
ServerAlias x
# ...
I've set it up in its own .conf but the content is
<VirtualHost *:80>
ServerAdmin admin@example.com
ServerName domain
ServerAlias domain
DocumentRoot /var/www/html/store/
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
I just compared that to this file on github and came to the comclusion that there probably is a lot of stuff missing to get the ssl to work properly.
You don’t need the other stuff - Certbot should add it automatically. Is that the full contents of the file?
It indeed is. I just ran down one of the tutorials on digitalocean. Let me try to find out which one it was … but if I recall it correctly it was related to getting multiple domains work on different sub folders and so on. So yes, this is the whole content of the file.
Not too sure what’s wrong.
You could try manually set up the HTPTS listener using e.g. https://mozilla.github.io/server-side-tls/ssl-config-generator/ , but it would be ideal to get Certbot’s Apache installer working instead.
If you can zip up and upload your /etc/apache2/ directory (assuming it has no sensitive information in it) I could try see where Certbot is tripping up, or someone else might stop by and have an idea about what’s wrong.
just give me a note once you’ve downloaded it. I’m not super comfortable with it being publicly available 
P.S. the DNS appears to have updated, given how loading the website in https results in a “connection attempt refused” error.
Sure, delete it.
bottom text
Well, your Apache directory worked for me - I was able to issue and install a certificate using your command, just substituting your domain for my own.
Last two things I would check (I ran 0.25.1):
certbot --version
and
certbot certificatesYou indeed wear smartypants. certbot certificates gave me the error I needed to see. I'm runnin 0.25.0 but that shouldn't be a big deal. Appareantly certbot doesn't have the permissions needed.
The following error was encountered:
[Errno 13] Permission denied: '/var/log/letsencrypt/.certbot.lock'
Either run as root, or set --config-dir, --work-dir, and --logs-dir to writeable paths.
Ah, yeah, sorry, stick sudo in front of those. It’s probably not the problem.