Yes, but then you may get confused when you go to edit the file…
Which one would you edit?
With a link, both go to the same place.
That is the preferred method.
To create the link:
ln -s /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-enabled/default-ssl.conf
then restart apache
You did it!
Now all you need is to proxypass it and you’re finished.
I’m going to bed, cya guys, it was no fun at all.
Lucky you - now I go to work - LOL
You were incredible guys! Thank you very much. WISH ME LUCK
Just to be clear, I need to make a proxy from 443 to 80, right?
And then set the renewal?
AGAIN YOU WERE GREAT , I LOVE YOU BOTH
These are the missing lines from /etc/apache2/sites-available/default-ssl.conf :
Renewal is automatic from when you issued the certificate with the --post-hook, you don’t need to do anything. Since you installed Certbot from repositories, a cronjob already exists on your system.
I didn’t issued the certificate with the --post-hook … I thought I should give the renewal command after the cert creation.
Yeah, check it to be sure it is how you want it:
crontab -l
or
sudo crontab -l
the post hook can go in the cron job
Why is my site working in https without the proxypass?
Couldn’t I use sudo certbot renew --dry-run or sudo certbot renew --post-hook for that matter?
Because it is pointing to the same root folder.
It just isn't using varnish though now.
The proxy pass is to force it back to varnish which will then bring it back to port 8080.
And provide all the varnishy things it provides.
Those commands only handle cert related functions.
They don't direct/redirect any ports.
Show:
crontab -l
and
sudo crontab -l
No, I mean for the renewal of the certification (instead of using a cron job).
no crontab for user
no crontabl for root
that just "test" if the cert can be renewed.
That would try to renew and when it does renew would execute whatever came after post-hook.
which is what we want in the cron job
Attempt to renew and when it does renew then restart apache.
Ok then we make you one...
first test these two and then we use whichever works from command line:
/usr/bin/certbot renew -q --deploy-hook 'service apache restart'
/usr/bin/certbot renew -q --post-hook 'service apache restart'
Assuming
which certbot
shows it at
/usr/bin/
Feel free to change the "service apache restart" to however you restart your apache...
The difference between deploy and post are:
deploy only kicks off when the cert is actually "deployed" (meaning renewed)
post will kick off immediately after every attempt (even if NOT renewed)
God damn you are good and helpful 
So, I assume the above commands work, because no errors were returned.
I used the following :
sudo certbot renew -q --deploy-hook 'service apache restart'
sudo /usr/bin/certbot renew -q --deploy-hook 'service apache2 restart'
sudo /usr/bin/certbot renew -q --post-hook 'service apache2 restart'
I should probably delete the first.
However, still:
no crontab for user
no crontabl for root
EDIT:
Also, I made the changes in default-ssl and it gave me an error. I am looking into it.
EDIT 2:
crontab -e returns a bad minute error
Shoud I be running it as user or as root?
God damn that is some nasty and difficult stuff.
EDIT 2:
Now it works for both user and root.
I mean crontab -e or sudo crontab -e. Shoud I just keep the user crontab?
OK so if all three worked, then I would use:
sudo /usr/bin/certbot renew -q --deploy-hook 'service apache2 restart’
Now to make a cron job entry for this…
You will need to edit the root user cron file, you can do that with
sudo crontab -e
Go to the bottom and insert:
11 04 * * * /usr/bin/certbot renew -q --deploy-hook 'service apache2 restart’
then save the file and recheck the contents with
sudo crontab -l
use:
sudo crontab -e
Do you mean the editor?
nano, vi ?
use:
sudo crontab -e