617

I am trying to make a curl request to one of our local development servers running a dev site with a self-signed SSL cert. I am using curl from the command line.

I saw some blog posts mentioning that you can add to the list of certificates or specify a specific (self signed) certificate as valid, but is there a catch-all way of saying "don't verify" the ssl cert - like the --no-check-certificate that wget has?

cwd
  • 45,389

4 Answers4

817

Yes. From the manpage:

-k, --insecure

(TLS) By default, every SSL connection curl makes is verified to be secure. This option allows curl to proceed and operate even for server connections otherwise considered insecure.

The server connection is verified by making sure the server's certificate contains the right name and verifies successfully using the cert store.

See this online resource for further details: https://curl.haxx.se/docs/sslcerts.html

See also --proxy-insecure and --cacert.

The reference mentioned in that manpage entry describes some of the specific behaviors of -k .

These behaviors can be observed with curl requests to test pages from BadSSL.com 

curl -X GET https://wrong.host.badssl.com/
curl: (51) SSL: no alternative certificate subject name matches target host name 'wrong.host.badssl.com'

curl -k -X GET https://wrong.host.badssl.com/
..returns HTML content...
Freiheit
  • 9,669
  • 22
    Love the fact that it has a one letter short option – kizzx2 Jan 20 '13 at 09:39
  • 3
    Is there any way in curl config to make this option default? – Wins Apr 05 '16 at 08:48
  • 11
    @Wins, that would be a horrible idea. Right an alias if you need to use it repeatedly, so you know what it does and don't accidentally send your passwords unencrypted.

    alias insecure-curl="curl -k"

     – Alex Huszagh Dec 05 '16 at 15:12
  • 6
    @AlexanderHuszagh At work, I only use curl from a single server with a self-signed certificate; there is never a time I want to do full certificate checking. Just because something seems like a horrible idea in most cases doesn’t mean it always is. – Daniel H Jun 06 '17 at 17:59
  • 10
    @DanielH That is why I suggested an alias: so you get the added convenience with the explicit knowledge that it is insecure. Workflows change: you should still know in some limited fashion when you are trading security for convenience, however. – Alex Huszagh Jun 06 '17 at 21:49
  • Is there a way to specify this option using environment variable? – Piotr Dobrogost Nov 23 '17 at 14:02
  • Ack -- the wording is bad... even if it does come straight from the manpage.. Just to be clear -- "making sure the server's certificate contains the right name" is the normal way, and "-k" ignores that check.. Right? Cause that's what your badssl example does... Or is there a nuance..? – Gerard ONeill Apr 05 '19 at 18:45
  • @GerardONeill the examples listed do not represent a comprehensive list of examples. You should visit https://badssl.com/ and try curl against other examples of common SSL mistakes and problems. curl -k would also let curl tolerate a site with a self-signed certificate like https://self-signed.badssl.com/, it is not just a cert+hostname check. – Freiheit Apr 05 '19 at 18:56
  • @Freiheit I get that there are other examples.. Its just that the exact example you chose seems to contradict that exact line that occurs underneath the -k description on the web page... The error was: no hostname match. The line says it checks that the cert has the right name... So.. Any explanation? – Gerard ONeill Apr 05 '19 at 23:42
  • I got nothing. Im in over my head. The author of the tool caught a mistake and now there is apparently an inconsistent example. – Freiheit Apr 07 '19 at 00:38
  • @GerardONeill - I had a good nights sleep and I thought about how to answer your question. I still do not know the answer but I think I know how someone could figure it out. Would your question be addressed if the behavior of -k were shown against EVERY case at BadSSL.com? I think that is scriptable. curl without -k should just work against the "good" cases and should fail against the "bad" cases. Then curl -k should work against all cases, good and bad. – Freiheit Apr 08 '19 at 13:35
  • Thanks @Freiheit; It is easy enough to just try it out myself and know what I have to do. I was more just trying to find out if I had missed something, and of course have a summary explaining why that sentence exists and is ambiguous. – Gerard ONeill Apr 08 '19 at 17:48
  • 1
    -k as in inseKure? Nice.. :) – Kristof Jozsa Jul 06 '21 at 11:54
49

You may use the following command to apply the changes for all connections:

$ echo insecure >> ~/.curlrc

On Windows just create _curlrc text file with 'insecure' text in it in your %HOME%, %CURL_HOME%, %APPDATA%, %USERPROFILE% or %USERPROFILE%\Application Data directory.

Advantage of using above solution is that it works for all curl commands, but it is not recommended since it may introduce MITM attacks by connecting to insecure and untrusted hosts.

kenorb
  • 20,988
  • 86
    This seems like bad advice: disabling these checks for all connections should not be the default, even if you do this to yourself via per-user configuration. If you need to suppress security checks, at least do it piecemeal. – Christopher Schultz May 22 '14 at 21:07
  • 7
    Anytime I am using curl, I either control or trust the machine at the other end. – Eric Hartford Sep 03 '14 at 18:00
  • 17
    @EricHartford: Well, good for you, but that still doesn't make it a good general advice imho. One might use curl, for instance when downloading homebrew on osx and end up with a modified version of the tools because he enabled this as a default blindly. – ereOn Oct 19 '14 at 03:02
  • 13
    Also @EricHartford are you sure you always do trusted curl stuff? Have you ever ran any bash install script you got off of internet? Granted, you can be in the black there anyway, but this increases the chances. – Zlatko May 08 '15 at 06:56
  • 2
    this is the real @EricHartford. The previous message was posted by someone else impersonating me. Because I trusted all machines ;-) – Anand Rockzz Jul 18 '19 at 04:19
  • If you're a developer or DevOps, you're dealing with SSL issues on daily basis, insecure isn't that bad, it's just less headache (it doesn't affect web-browsers, and you don't curl to to the bank anyway, lol). Secondly, having verification enabled for SSL certificates won't protect you from scammers anyway. Certificates does NOT validate the CONTENTS of the site!. It’s up to THE USER to check whether you're connecting to the right place or not. So having secure won't prevent you from downloading a malware anyway. – kenorb Jul 18 '19 at 10:45
  • Obtaining verified SSL certificates by scammers/hackers is no brainer nowadays, you can get it in few minutes. So if somebody is stupid enough to run some random bash install scripts from the internet, verifying certificates won't really help. There are plenty of scam sites which have "verified" SSL certificates. So installing Linux by layman because it's secure vs installing Windows by expert, won't help, as the responsibility is with the user. Just be smart, be safe, and have a common sense. – kenorb Jul 18 '19 at 10:58
  • 2
    How do you reverse it? :) – Steve Payne Jun 26 '20 at 05:10
15

You are using a self-signed cert. Why don't you appended the CA to your trusted CA bundle (Linux) or add to the trusted Certificate store (windows)? Or simply use --cacert /Path/to/file with the contents of your trusted self-signed cert file.

The other answers are answering the question based on the wget comparable. However the true ask is how do I maintain a trusted connection with a self-signed cert using curl. Based on many comments security is the top concern in any one of these answers, and the best answer would be to trust the self-signed cert and leave curls security checks intact.

Victor Yarema
  • 148
user3258557
  • 161
  • 1
  • 2
  • Good suggestion. Unfortunately on Windows at least curl still had an issue with my trusted CA and self-signed cert combo (works great in browsers and iOS) due to a failed revocation check. The --ssl-no-revoke option takes care of that though. – Jeff Camera Jun 09 '21 at 15:22
6

Adding to user3258557 's answer, let's say that you need to test some fake server of your own with your own root CA etc. And you just don't want to use curl's -k option.

First, let's create a RSA key for your Root CA:

openssl genrsa -des3 -out rootCA.key 4096

Then, using that key, let's sign a certificate for our own CA:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt

Now, you have a Root CA with private Key and Certificate.

Let's now generate keys and certificates for our own websites:

openssl genrsa -out mainsite.net.key 2048

Now, before creating the certificate, we will need a Certificate Signing Request (CSR) first. Then our Root CA will "sign" the CSR and generate the certificate for our website.

openssl req -new -key mainsite.net.key -out mainsite.net.csr

Let's finally create the certificate for our website:

openssl x509 -req -in mainsite.net.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out mainsite.net.crt -days 500 -sha256

For ease of use, let's generate a .pem file using our .crt and .key files as:

cat mainsite.net.key mainsite.net.crt > mainsite.net.pem

Now, you can run a simple server with this .pem file. Say this server is running at 127.0.0.1:12345

For curl request, you can just do this:

curl --cacert "rootCA.crt" https://127.0.0.1:12345/

Going a step further, if you want to host multiple sites on a port using SNI, you can generate the key for each site, sign the CSR's and use a curl request like below:

curl --resolve subsite1.mainsite.net:12345:127.0.0.1 -X GET --cacert "rootCA.crt" --cert "subsite1.mainsite.net.crt" --key "subsite1.mainsite.net.key" https://subsite1.mainsite.net:12345/
Rahul Bharadwaj
  • 225