I run Let’s Encrypt with this command:
./letsencrypt-auto-source/letsencrypt-auto certonly --manual \
--manual-public-ip-logging-ok \
--email john#example.com \
--agree-tos \
--domain example.com \
--domain www.example.com \
--rsa-key-size 2048
I get the following error message:
Skipping bootstrap because certbot-auto is deprecated on this system.
./letsencrypt-auto-source/letsencrypt-auto has insecure permissions!
To learn how to fix them, visit https://community.letsencrypt.org/t/certbot-auto-deployment-best-practices/91979/
Your system is not supported by certbot-auto anymore.
Certbot cannot be installed.
Please visit https://certbot.eff.org/ to check for other alternatives.
So, how to tell Let’s Encrypt to no be as perfectionist as he is? Am just in a test project and no need all this suspicious behavior. Also, there is no need to do all the annoying stuff asked.
So, basically, how to telle Let’s Encrypt “Just let it go. I know what I am doing”?
Related
I am trying to obtain an SSL certificate with certbot and the --webroot setting. My current command is:
sudo certbot certonly --webroot -w <path> -d <URL> -d <*.URL>
Every time I run the command I get this error:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
I tried every similar command I found. Please share some help.
I am using ubuntu 18 with the newest certbot version. I also tried certbot-auto
I figured it out: with the http verification (webroot) it is not possible to obtain wildcards (<*.url>).
But it is possible with a DNS challenge (Reference).
Here is an example command for a manual / DNS challenge wildcard certifiat request:
sudo certbot certonly --manual -d *.<domain> -d <domain> --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 --server acme-v02.api.letsencrypt.org/directory
I want to provide some further reading on this for anyone else struggling - and I'll explain why every solution still didn't work!
Great advice from Letsencrypt ...
https://community.letsencrypt.org/t/client-with-the-currently-selected-authenticator-an-authenticator-script-must-be-provided-when/153921
https://letsencrypt.org/docs/challenge-types/ - see DNS-01. Basically Certbot has to connect with your DNS provider/api to create temporary records to verify your domain.
BUT ... not all providers allow this ...
https://community.letsencrypt.org/t/dns-providers-who-easily-integrate-with-lets-encrypt-dns-validation/86438
And it turns out mine (Namecheap) doesn't. So in short Wildcards + Certbot + Namecheap are not physically possible!
curl -O "https://www.apache.org/dist/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz"
This is the command I am using from terminal to download maven but it's either timed out or curl: (7) Failed to connect to www.apache.org port 443: Operation timed out.
If I use browser to download, no issue.
My assumption is the ssl connection or certificate issue. Any idea how can I resolve the curl issue.
Please take note, I am using this in a Dockerfile to create docker image and here is that:
FROM ******/mule-42x:v2.2.1
ENV MAVEN_VERSION 3.6.3
RUN mkdir -p /opt/maven \
&& cd /opt/maven \
&& curl -O "https://www.apache.org/dist/maven/maven-3/${MAVEN_VERSION}/binaries/apache-maven-${MAVEN_VERSION}-bin.tar.gz" \
&& tar xzvf "apache-maven-$MAVEN_VERSION-bin.tar.gz" \
&& rm "apache-maven-$MAVEN_VERSION-bin.tar.gz"
ENV MAVEN_HOME "/opt/maven/apache-maven-$MAVEN_VERSION"
ENV PATH=$MAVEN_HOME/bin:$PATH
I've tried to run the command presented in the question and encountered the following errors:
curl -O "https://www.apache.org/dist/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz"
curl tries to verify the SSL certificate but fails with the following message:
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
So I've added -k flag as the message suggests.
Now this works, however the http call returns and HTML page with 302 (redirect) to https://downloads.apache.org/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
So the command that has worked for me is:
curl -O -k https://downloads.apache.org/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
An Important side note:
I'm assuming that you've configured the network right and it has all the proper proxy definitions if you're running behind the proxy in your organization, otherwise you should define proxy first.
All in all I suggest you running this command 'manually' first (from the command line not as a part of the build I mean) outside the docker on the machine where you run the docker build and only when you make sure it works run it in a docker file.
I'm trying to create certificate for *.foobar.com
./certbot-auto certonly --standalone-supported-challenges http-01 -d *.foobar.com
But I get the error:
certbot: error: unrecognized arguments: --standalone-supported-challenges http-01
I have google this error but I keep getting answers with example using apache servers. What is the command to make it work with a simple golang webserver serving a typical web app (html, css, js, some svgs, jpgs)
So I followed official certbot instructions:
https://certbot.eff.org/lets-encrypt/ubuntubionic-other
and this is the command that got it working for me:
cd certbot # change into cerbot dir
sudo ./certbot-auto certonly --standalone -d foobar.com
I have to renew Let's Encrypt certificates on my Debian server. By some reason the renew option doesn't works, and nor the certbot-auto script.
This below command works, but asking some questions:
sudo certbot --server https://acme-v02.api.letsencrypt.org/directory -d *.blogginger.com --manual --preferred-challenges dns-01 certonly
Questions while I'm running this command:
Would you like to redirect HTTP to HTTPS? I choose here option 1
Are you OK with your IP being logged?
and press Enter at the end.
How can I skip these questions? Which parameters should I use with certbot?
Thank you!
The solution was this below command to renew all certificate on the server, included the mentioned certificate as well:
sudo certbot renew
I insert this command in crontab for never forget to renew any certificates:
0 4 * * 0 sudo certbot renew
It will send a request at every early morning of Sunday.
Hide standard output and show only errors by addig "-q" parameter:
sudo certbot renew -q
It seems like letsencrypt have forgotten the options used when generating the certs originally.
If you manually run just certbot, with only the least possible options, and when asked, select the "don't alter apache config" option, I think the options will be saved for next run of certbot-auto renew
I'm building an application that will connect to the user's web browser through a secure web socket (SSL). I'm using Websocketd to connect to the web socket, but that shouldn't matter.
Short version:
I really just need help using the add-trusted-cert command... and Apple's man pages really don't help at all if you haven't used this before. How can I add a certificate to the System Keychain and only set the SSL and Basic option to "Aways Trust"?
Long version:
I am generating self-signed certificates and passing them into Websocketd in order to connect to the web socket over SSL. No further steps are required for Firefox and Chrome... they just work with this. Safari however, doesn't trust my self-signed certificates, and I have to go into Keychain Access and add my certificate and change the Trust settings to "Use Custom Settings" with ONLY the SSL option and the X.509 Basic Policy option set to "Always Trust"... any other settings and Safari complains. I don't want my users to have to fiddle with certificates, so my solution was to add my certificate to the System Keychain using a post-install script. Like so:
sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.Keychain" "./certificate.cert"
This successfully adds the certificate to the user's System Keychain... but it sets all of the options to "Always Trust"... for some reason Safari doesn't like this and complains. Only when the SSL and X.509 Basic Policy options are set to Always Trust and the rest set to "No Value Specified" does Safari behave.
Okay so I checked out the man pages for the "security add-trusted-cert" and sure enough there is an option that you can pass in to only set certain options to "Always Trust"... so I came up with this:
sudo security add-trusted-cert -d -r trustRoot -p ssl -k "/Library/Keychains/System.Keychain" "./certificate.cert"
The result of the -p ssl option is that now my certificate gets added to the System Keychain with only the SSL option set to Always Trust... but the basic option isn't! If I replace ssl with basic I can set the basic option to Always Trust:
sudo security add-trusted-cert -d -r trustRoot -p basic -k "/Library/Keychains/System.Keychain" "./certificate.cert"
But this still doesn't solve my issue! I need BOTH set to Always Trust, and the other options left at "No Specified Value"... so I tried this:
sudo security add-trusted-cert -d -r trustRoot -p ssl & basic -k "/Library/Keychains/System.Keychain" "./certificate.cert"
But this doesn't work. I swear I've read all of Google on this subject and I can't find a single example of how to construct this command so that it accomplishes what I am describing. This link confirmed what I need to do but didn't actually provide an example command, and this link is searching the same answer I am... but nobody has replied with a suitable answer yet, and the accepted answer on this stackoverflow question is correct... but they just tell you what you need to do (I already know that), and don't tell you how to actually do it.
So again, how can I add a certificate to the System Keychain and only set the SSL and Basic option to "Aways Trust"?
Thank you!
After another frustrating session of trying to guess the correct command I finally stumbled on the answer, I'll share it here in case anyone needs it:
sudo security add-trusted-cert -d -r trustRoot -p ssl -p basic -s "localhost" -k "/Library/Keychains/System.Keychain" "./certificate.cert"
Note the solution is to simply add another -p flag followed by another constraint. In addition, it is probably wise to specify the policy string using the -s flag... in my case that's just the localhost.
I hope this proves useful! I was dumbfounded that such a routine task has virtually no documentation and no answers on stackoverflow.