aboutsummaryrefslogtreecommitdiff
path: root/docs/SSLCERTS.md
diff options
context:
space:
mode:
authorDaniel Stenberg <daniel@haxx.se>2016-08-09 12:03:46 +0200
committerDaniel Stenberg <daniel@haxx.se>2016-08-09 12:03:46 +0200
commit615a12cbad3ca87b3ff499abe9ae39479e915322 (patch)
tree18683e9bf6774851826f960f1da8cbe8b19a85f8 /docs/SSLCERTS.md
parentd263e83079722586c3a491dd11bf403fdc6fd707 (diff)
SSLCERTS.md: renamed to markdown extension
Diffstat (limited to 'docs/SSLCERTS.md')
-rw-r--r--docs/SSLCERTS.md163
1 files changed, 163 insertions, 0 deletions
diff --git a/docs/SSLCERTS.md b/docs/SSLCERTS.md
new file mode 100644
index 000000000..7755609c4
--- /dev/null
+++ b/docs/SSLCERTS.md
@@ -0,0 +1,163 @@
+SSL Certificate Verification
+============================
+
+SSL is TLS
+----------
+
+SSL is the old name. It is called TLS these days.
+
+
+Native SSL
+----------
+
+If libcurl was built with Schannel or Secure Transport support (the native SSL
+libraries included in Windows and Mac OS X), then this does not apply to
+you. Scroll down for details on how the OS-native engines handle SSL
+certificates. If you're not sure, then run "curl -V" and read the results. If
+the version string says "WinSSL" in it, then it was built with Schannel
+support.
+
+It is about trust
+-----------------
+
+This system is about trust. In your local CA certificate store you have certs
+from *trusted* Certificate Authorities that you then can use to verify that the
+server certificates you see are valid. They're signed by one of the CAs you
+trust.
+
+Which CAs do you trust? You can decide to trust the same set of companies your
+operating system trusts, or the set one of the known browsers trust. That's
+basically trust via someone else you trust. You should just be aware that
+modern operating systems and browsers are setup to trust *hundreds* of
+companies and recent years several such CAs have been found untrustworthy.
+
+Certificate Verification
+------------------------
+
+libcurl performs peer SSL certificate verification by default. This is done
+by using a CA certificate store that the SSL library can use to make sure the
+peer's server certificate is valid.
+
+If you communicate with HTTPS, FTPS or other TLS-using servers using
+certificates that are signed by CAs present in the store, you can be sure
+that the remote server really is the one it claims to be.
+
+If the remote server uses a self-signed certificate, if you don't install a CA
+cert store, if the server uses a certificate signed by a CA that isn't
+included in the store you use or if the remote host is an impostor
+impersonating your favorite site, and you want to transfer files from this
+server, do one of the following:
+
+ 1. Tell libcurl to *not* verify the peer. With libcurl you disable this with
+ `curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, FALSE);`
+
+ With the curl command line tool, you disable this with -k/--insecure.
+
+ 2. Get a CA certificate that can verify the remote server and use the proper
+ option to point out this CA cert for verification when connecting. For
+ libcurl hackers: `curl_easy_setopt(curl, CURLOPT_CAPATH, capath);`
+
+ With the curl command line tool: --cacert [file]
+
+ 3. Add the CA cert for your server to the existing default CA certificate
+ store. The default CA certificate store can changed at compile time with the
+ following configure options:
+
+ --with-ca-bundle=FILE: use the specified file as CA certificate store. CA
+ certificates need to be concatenated in PEM format into this file.
+
+ --with-ca-path=PATH: use the specified path as CA certificate store. CA
+ certificates need to be stored as individual PEM files in this directory.
+ You may need to run c_rehash after adding files there.
+
+ If neither of the two options is specified, configure will try to auto-detect
+ a setting. It's also possible to explicitly not hardcode any default store
+ but rely on the built in default the crypto library may provide instead.
+ You can achieve that by passing both --without-ca-bundle and
+ --without-ca-path to the configure script.
+
+ If you use Internet Explorer, this is one way to get extract the CA cert
+ for a particular server:
+
+ - View the certificate by double-clicking the padlock
+ - Find out where the CA certificate is kept (Certificate>
+ Authority Information Access>URL)
+ - Get a copy of the crt file using curl
+ - Convert it from crt to PEM using the openssl tool:
+ openssl x509 -inform DES -in yourdownloaded.crt \
+ -out outcert.pem -text
+ - Add the 'outcert.pem' to the CA certificate store or use it stand-alone
+ as described below.
+
+ If you use the 'openssl' tool, this is one way to get extract the CA cert
+ for a particular server:
+
+ - `openssl s_client -connect xxxxx.com:443 |tee logfile`
+ - type "QUIT", followed by the "ENTER" key
+ - The certificate will have "BEGIN CERTIFICATE" and "END CERTIFICATE"
+ markers.
+ - If you want to see the data in the certificate, you can do: "openssl
+ x509 -inform PEM -in certfile -text -out certdata" where certfile is
+ the cert you extracted from logfile. Look in certdata.
+ - If you want to trust the certificate, you can add it to your CA
+ certificate store or use it stand-alone as described. Just remember that
+ the security is no better than the way you obtained the certificate.
+
+ 4. If you're using the curl command line tool, you can specify your own CA
+ cert path by setting the environment variable `CURL_CA_BUNDLE` to the path
+ of your choice.
+
+ If you're using the curl command line tool on Windows, curl will search
+ for a CA cert file named "curl-ca-bundle.crt" in these directories and in
+ this order:
+ 1. application's directory
+ 2. current working directory
+ 3. Windows System directory (e.g. C:\windows\system32)
+ 4. Windows Directory (e.g. C:\windows)
+ 5. all directories along %PATH%
+
+ 5. Get a better/different/newer CA cert bundle! One option is to extract the
+ one a recent Firefox browser uses by running 'make ca-bundle' in the curl
+ build tree root, or possibly download a version that was generated this
+ way for you: [CA Extract](https://curl.haxx.se/docs/caextract.html)
+
+Neglecting to use one of the above methods when dealing with a server using a
+certificate that isn't signed by one of the certificates in the installed CA
+certificate store, will cause SSL to report an error ("certificate verify
+failed") during the handshake and SSL will then refuse further communication
+with that server.
+
+Certificate Verification with NSS
+---------------------------------
+
+If libcurl was built with NSS support, then depending on the OS distribution,
+it is probably required to take some additional steps to use the system-wide
+CA cert db. RedHat ships with an additional module, libnsspem.so, which
+enables NSS to read the OpenSSL PEM CA bundle. On openSUSE you can install
+p11-kit-nss-trust which makes NSS use the system wide CA certificate store. NSS
+also has a new [database format](https://wiki.mozilla.org/NSS_Shared_DB).
+
+Starting with version 7.19.7, libcurl automatically adds the 'sql:' prefix to
+the certdb directory (either the hardcoded default /etc/pki/nssdb or the
+directory configured with SSL_DIR environment variable). To check which certdb
+format your distribution provides, examine the default certdb location:
+/etc/pki/nssdb; the new certdb format can be identified by the filenames
+cert9.db, key4.db, pkcs11.txt; filenames of older versions are cert8.db,
+key3.db, secmod.db.
+
+Certificate Verification with Schannel and Secure Transport
+-----------------------------------------------------------
+
+If libcurl was built with Schannel (Microsoft's native TLS engine) or Secure
+Transport (Apple's native TLS engine) support, then libcurl will still perform
+peer certificate verification, but instead of using a CA cert bundle, it will
+use the certificates that are built into the OS. These are the same
+certificates that appear in the Internet Options control panel (under Windows)
+or Keychain Access application (under OS X). Any custom security rules for
+certificates will be honored.
+
+Schannel will run CRL checks on certificates unless peer verification is
+disabled. Secure Transport on iOS will run OCSP checks on certificates unless
+peer verification is disabled. Secure Transport on OS X will run either OCSP
+or CRL checks on certificates if those features are enabled, and this behavior
+can be adjusted in the preferences of Keychain Access.