I have some issues to generate a new certificate with certbot. i use certbot 0.10.2 and I want to upgrade it and Acme2 but I have some error when I type sudo certbot certonly --apache:
Could not choose appropriate plugin: The requested apache plugin does not appear to be installed
The requested apache plugin does not appear to be installed
Try install python3-certbot-apache
Related
There is a LetsEncrypt SSL cert on a Digital Ocean OpenLiteSpeed sever I'm managing, which has the wrong name. Does anyone know if there is a way I can either remove the cert and make a new one or edit it? If I add a second cert with the correct information, does anyone know how that would play out? Thank you in advance for any help you can offer.
for removing ssl in digital ocean you can use
$ sudo certbot delete
there is no way to edit ssl becasue SSL is an encrypted format system.you can delete ssl from ssl or make a new ssl for your domain
first of all, if you are applying the wrong domain or subdomain and you want to correct it so no need to correct it. change your SSL by using these steps :
Open DigitalOcean Console :
Step1: login with your username and password.
Step2: use this command sudo add-apt-repository ppa:certbot/certbot
Step 3: command sudo apt-get update
Step 4: sudo apt-get install python-certbot-apache
Now The certbot Let’s Encrypt client is now ready to use.
Set Up the SSL Certificate
Step 5: sudo certbot --apache -d example.com <<<<use your own domain or subdomain instead of example.com
Verifying Certbot Auto-Renewal
sudo certbot renew --dry-run
If you want to delete SSL CERTBOT from your site use these commands:
Command to Delete Certbot Certificate
$ sudo certbot delete
Delete Certbot Certificate by Domain Name
$ sudo certbot delete --cert-name example.com
I guess you are asking about how to update the new LE cert on OpenLiteSpeed.
Basically you can follow this official doc to apply the cert and update the correct certificate & key path to the listener>SSL via web admin at port 7080.
Best
As part of an automated build, we run download some code from github. Minimal example:
wget github.com
Recently, the command started failing with a certificate error:
URL transformed to HTTPS due to an HSTS policy
--2017-10-05 11:43:45-- https://github.com/
Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
ERROR: cannot verify github.com's certificate, issued by 'CN=DigiCert SHA2 Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US':
Unable to locally verify the issuer's authority.
I tried updating the certificate store, and wget itself:
update-ca-certificates
apt-get install wget
The error is still the same.
My wget version is GNU Wget 1.17.1, and the OS is Ubuntu 16.04.3.
You can avoid checking the validity of the certificate adding the --no-check-certificate option on the wget command-line.
The answer turned out to lie somewhere in packet configuration. Unfortunately, I am unable to tell exactly why. The suspicion is some mono version installed from a ppa was messing with our cert store.
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 just upgraded from ISPConfig 3.0 to 3.1.2 on Debian 7.
According to the Changelog, Let's Encrypt is now supported.
However, I don't see any Let's Encrypt specific options. I can create an SSL certificate from the SSL tab of a Website, but accessing the domain using https:// results in the following error in Chrome:
This site can’t provide a secure connection.
Is Let's Encrypt only available for new (clean) installations?
- or will the proper options emerge if I install e.g. CertBot or some other package?
It seems CertBot has a plugin for Apache that automates everything, but I'm worried ISPConfig and CertBot will conflict when both trying to control configuration files.
Thanks in advance for any guidance.
Jimmy
I realized that HowToForge would be the ideal place to ask. Here is the response I received from Till Brehm:
"1) You have to install certbot and just certbot, no certbot apache plugin. and do not create ssl certs with certbot at install time, when it asks for that, choose cancel.
2) then login to ispconfig, go to the website settings amd emable the checkbox labeled "Letsencrypt" which is on the first tab of the site settings. The SSL tab is not used for letsencrypt."
It worked just the way he said.
https://www.howtoforge.com/community/threads/ispconfig-lets-encrypt-not-available-after-upgrade.75540/#post-355688
I am getting the below error while making ssl connection with self signed certificate.
"Peer certificate cannot be authenticated with known CA certificates"
It is working fine with CA signed certificate.
I am setting the below using curl_easy_setopt().
curl_easy_setopt(MyContext, CURLOPT_CAPATH, CA_CERTIFICATE_PATH)
curl_easy_setopt(MyContext, CURLOPT_SSL_VERIFYPEER,TRUE);
The curl version:
libcurl-7.19.7-26
Openssl version is:
0_9_8u
Please let me know how to solve this issue.
By default CURL will generally verify the SSL certificate to see if its valid and issued by an accepted CA. To do this, curl uses a bundled set of CA certificates.
If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. Here's an example:
curl --noproxy -k \* -D - https://127.0.0.1:443/some-secure-endpoint
Security issue: This answer disables a security feature. Do not use this in production!
For php it is possible to switch off curl's verification of the certificate (see warning below) e.g. for curl_exec
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
http://php.net/manual/en/function.curl-setopt.php
(evaluate the security risk yourself, in my case it was on a partner company's server and the file required contained no secure information - just happened to be on a secure server)
We fixed a similar issue on CentOS 6 by updating curl to the latest version available in the standard repositories and installing the newest ca-certificates bundle:
yum update curl
yum install ca-certificates
libcurl performs peer SSL certificate verification by default. This is done
by using CA cert bundle that the SSL library can use to make sure the peer's
server certificate is valid.
If you communicate with HTTPS or FTPS servers using certificates that are
signed by CAs present in the bundle, you can be sure that the remote server
really is the one it claims to be.
Until 7.18.0, curl bundled a severely outdated ca bundle file that was
installed by default. These days, the curl archives include no ca certs at
all. You need to get them elsewhere. See below for example.
For more to know about Peer SSL Certificate Verification visit http://curl.haxx.se/docs/sslcerts.html
Though this error happened in the case of using git clone rather than with using curl, I've recently stumbled across an identical error message:
Peer certificate cannot be authenticated with known CA certificates
Similar to Arth's findings, something that worked for CentOS 6 (in order to successfully use HTTPS URLs with git clone for related GitLab repositories) involved updating the trusted certificates on the server (i.e., the server that is using HTTPS), using the following steps:
sudo yum install ca-certificates
sudo update-ca-trust enable
sudo cp /path/to/your_new_cert.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
Perhaps the same certificate steps can be applied for the case of curl (or other similar scenarios) for users on CentOS in the future.
Security issue: This answer disables a security feature. Do not use this in production!
In 'C'
curl_easy_setopt(curl_handle, CURLOPT_SSL_VERIFYPEER, 0);
worked for me
As we checked and observed/ Found in Centos 8 .
Due to Proxy issue your packages not allowing you to get accessible to update or download any packages.
try to add sslverify=0 in file /etc/dnf/dnf.conf
Its worked for me.
Also make sure you must have proper internet acess on your server.