So, I have OpenLightSpeed server with CyberPanel installed. My issue is that once I issue the SSL with a standard CyberPanel tool, it works for 90 days only, regular Lets Encrypt cert.
There is a CRON job add possibility in the CP, but I`m not sure it will work properly to auto-renew. Esspecialy the restart part. Here it is:
/root/.acme.sh/acme.sh --issue -d yourdomainname.com -d www.yourdomainname.com --cert-file /etc/letsencrypt/live/yourdomainname.com/cert.pem --key-file /etc/letsencrypt/live/yourdomainname.com/privkey.pem --fullchain-file /etc/letsencrypt/live/yourdomainname.com/fullchain.pem -w /home/yourdomainname.com/public_html –-force && systemctl restart lsws
Could someone advise, please? Thanks in advance.
The SSL renewal is auto in CyberPanel. Like after 90 days this cron will automatically run to issue SSL in cyberpanel you can see the command in the CyberPanel main log but if due to some issue like forceful redirection or anything SSL not successfully issued you have to issue manually then.
Related
I developed an application for a client which I host on a subdomain, now the problem is that I don't own the main domain/website. They've added a DNS record to point to the IP on which I host that app. Now I want to request a Free & automatic certificate from Let's Encrypt. But when I try the handshake it says
Getting challenge for subdomain.example.com from acme-server...
Error: http://subdomain.example.com/.well-known/acme-challenge/letsencrypt_**** is not reachable. Aborting the script.
dig output for subdomain.example.com:subdomain.example.com
Please make sure /.well-known alias is setup in WWW server.
Which makes sense cause I don't own that domain on my server. But if I try to generate it without the main domain I get:
You must include your main domain: example.com.
Cannot Execute Your Request
Details
Must include your domain example.com in the LetsEncrypt entries.
So I'm curious on how I can just set up a certificate without owning the main domain. I tried googling the issue but I couldn't find any relevant results. Any help would be much appreciated.
First
You don't need to own the domain, you just need to be able to copy a file to the location serving that domain. (You're all set there it sounds like)
Second
What tool are you using? The error message you gave makes me think the client is misconfigured. The challenge name is usually something like https://example.com/.well-known/acme-challenge/jQqx6qlM8u3wpi88N6lwvFd7SA07oK468mB1x4YIk1g. Compare that to your error:
Error: http://example.com/.well-known/acme-challenge/letsencrypt_example.com is not reachable. Aborting the script.
Third
I'm the author of Greenlock, which is compatible with Let's Encrypt. I'm confident that it will work for you.
Install
# Feel free to read the source first
curl -fsS https://get.greenlock.app/ | bash
Usage with existing webserver:
Let's say that:
You're using Apache or Nginx.
You confirm that ping example.com gives the IP of your server
You're exposing http on port 80 (otherwise verification will fail)
Your website is located in /srv/www/example.com
Your email is jon#example.com (must be a real email address)
You want to store your certificate as /etc/acme/live/example.com/fullchain.pem
This is what the command would look like:
sudo greenlock certonly --webroot \
--acme-version draft-11 --acme-url https://acme-v02.api.letsencrypt.org/directory \
--agree-tos --email jon#example.com --domains example.com \
--community-member \
--root /srv/www/example.com \
--config-dir /etc/acme
If that doesn't work on the first try then change out --acme-url https://acme-v02.api.letsencrypt.org/directory for --acme-url https://acme-staging-v02.api.letsencrypt.org/directory while you debug. Otherwise your server could become blocked from Let's Encrypt for too many bad requests. Just know that you'll have to delete the certificates from the staging environment and retry with the production url since the tool cannot tell which certificates are "production" and which ones are "testing".
The --community-member flag is optional, but will provide me with analytics and allow me to contact you about important or mandatory changes as well as other relevant updates.
After you get the success message you can then use those certificates in your webserver config and restart it.
That will work as a cron job as well. You could run it daily and it will only renew the certificate after about 75 days. You could also put a cron job to send the "update configuration" signal to your webserver (normally HUP or USR1) every few days to cause it to start using the new certificates without even restarting (...or just have it restart).
Usage without a web server
If you just want to quickly test without even having a webserver running, this will do it for you:
sudo greenlock certonly --standalone \
--acme-version draft-11 --acme-url https://acme-v02.api.letsencrypt.org/directory \
--agree-tos --email jon#example.com --domains example.com \
--community-member \
--config-dir /etc/acme/
That runs expecting that you DO NOT have a webserver running on port 80, as it will start one temporarily just for the purpose of the certificate.
sudo is required for using port 80 and for writing to root and httpd-owned directories (like /etc and /srv/www). You can run the command as your webserver's user instead if that has the correct permissions.
Use Greenlock as your webserver
We're working on an option to bypass the middleman altogether and simply use greenlock as your webserver, which would probably work great for simple vhosting like it sounds like you're doing. Let me know if that's interesting to you and I'll make sure to update you about it.
Fourth
Let's Encrypt also has an official client called certbot which will likely work just as well, perhaps better, but back in the early days it was easier for me to build my own than to use theirs due to issues which they have long since fixed.
Whats important is the sub domains A record. It should be the IP Address of from where you are trying to request the sub domains certificate.
I'm having issues with TLS enabling in Mattemost. In my server I configured a lot of virtualHosts plus the mattermost files. In http everything was working fine.
Today I tried to setup TLS and https. I followed the instuctions as in https://docs.mattermost.com/install/config-tls-mattermost .html. Now I get this:
Please notice the error: I'm trying to access domain1.mywebsite.com and the error is "its security certificate is signed by domain2.mywebsite.com". domain2.mywebsite.com is one of the websites configured as virtualhosts in apache.
I did not configure any virtualhost for Mattermost, since I don't thing any is needed (and it worked flawlessly without one, and without TLS). But how can I tell mattermost (or the browser?) that the server of domain2.mywebsite.com is the same of domain1.mywebsite.com?
I generated the certificates using letsencrypt with the standalone option (sudo certbot certonly --standalone -d domain1.mywebsite.com) and didn't move any file, just enabled "UseLetsEncrypt": true, in config.json file.
Do you happen to have any idea about how I could fix this?
Thank you
Marco
You'll need to configure TLS on Apache. You'll needs to use separate certificates for each virtual host.
Here is information that might help you: https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html
Don't configure TLS on Mattermost if TLS is being handled by the proxy.
I followed this guide to set-up Let's Encrypt https://www.linode.com/docs/security/ssl/install-lets-encrypt-to-create-ssl-certificates
I created the certificate for one of my sites using:
sudo -H ./letsencrypt-auto certonly --standalone -d example.com
and now need to add it to Apache. I started following this guide but it lists different certificate extensions.
I've just found the following article https://www.upcloud.com/support/install-lets-encrypt-apache/ which seems like a more straight forward process.
What's the best way to remove what I've done so far and go this alternative route?
I followed this guide https://certbot.eff.org/#debianjessie-apache
and when it took me through the install process it allowed me to update the existing certificate.
I've got a server which had an expired letsenrypt certificate. To fix that, I simply ran certbot --apache which ran without problems and solved the expired certificate.
To prevent this problem in the future, I wanted to have the certificate automatically renew itself, so following the instructions here I ran certbot renew --dry-run, but that ends in an error:
Attempting to renew cert from /etc/letsencrypt/renewal/cms.ourdomain.com.conf produced an unexpected error: Failed authorization procedure. cms.ourdomain.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up CAA for cms.ourdomain.com. Skipping.
Since certbot --apache worked perfectly well I wouldn't know why this renewal would fail with a DNS problem. To be sure I ran certbot --apache again to force and renew the cert again, which again worked fine. So nothing seems to be wrong with the DNS.
Does anybody know what could be the cause of this problem or how I can debug this? All tips are welcome!
From what I have seen, certbot and certbot --apache actually take some significantly different code paths. Perhaps try certbot --apache --dryrun?
Incidentally, I have given up on the Apache specific implementation. I have found that stopping apache and running certbot certonly --standalone -d example.com does a good job of generating keys and certs (point to them manually in your apache config) and then certbot renew with pre and post hook scripts in /etc/letsencrypt/renewal-hooks/{pre|post}/apache2.sh to stop and start apache works really well.
My scripts look like:
#!/bin/bash
# certbot pre renewal
# stop apache
systemctl stop apache2
sleep 5s
#!/bin/bash
# certbot post renewal
# start apache
systemctl start apache2
I'm having issues trying to renew a recently expired certificate issued with let's encrypt.
I tried launching the following commands:
./letsencrypt-auto renew
and
sudo ./letsencrypt-auto certonly --text --agree-tos --email dev#intuizone.com --renew-by-default --webroot --webroot-path /home/lovegistics -d lovegistics.it
which was the code I used to issue the certificate. Both of the command said that the certificate was succesfully renewed/issued, but it still gives me unsecure connection.
Since I was on WHM, I took a look on the manage SSL page, and it says that the certificate has actually expired yesterday.
The output for the second command:
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/lovegistics.it/fullchain.pem. Your cert will
expire on 2016-11-20. To obtain a new or tweaked version of this
certificate in the future, simply run letsencrypt-auto again. To
non-interactively renew *all* of your certificates, run
"letsencrypt-auto renew"
I'm sorry, but I lost the output for the first one. Strangely, when I try to relaunch the renew command, it says that the certificates are not due for renewal yet.
How can I renew this certificate?
Thank you all in advance for your help.
EDIT: I restarted the web server (Apache) after each of these commands
Finally I managed to solve my problem. The certificates were created successfully, but since I was on a CPanel server, they must be installed. In the following link there is an explanation directly from the cpanel team with a pearl code to copy-paste and execute when you have generated the certificate.
cpanel forum explanation
Happy coding!
Check certificate:
certbot certificates
Renew command:
certbot renew --force-renewal --cert-name api2.example.in --deploy-hook "sudo service nginx restart"
have to go through a minimum number of measures to [instal Let's Encrypt SSL certificates][1].
First, by accessing active domains such as http:/yourdomain.com:2083 or http:/yourdomain.com/cpanel, go to cPanel.
When you proceed to the protection tab, the Let's Encrypt SSL icon is visible to you.
Click on the + Issue button as soon as you proceed to the Issuing a New Certificate arena.
You've got to click on your domain name then. Email the server when you're done with it. Then pick, and confirm, HTTP-01.
Click the problem button once you finish it.