usingcurl/tls/verify.md: mention --ca-native

and reword a little

Fixes curl#330

index-words

@@ -2,6 +2,7 @@
 --alt-svc
 --anyauth
 --basic
+--ca-native
 --compressed
 --compressed-ssh
 --connect-timeout
@@ -54,6 +55,7 @@
 --post302
 --post303
 --proxy
+--proxy-ca-native
 --proxy-http2
 --proxy-user
 --proxy1.0

usingcurl/tls/verify.md

@@ -5,8 +5,8 @@ be certain that you are communicating with the **correct** host. If we do not
 know that, we could just as well be talking with an impostor that just
 *appears* to be who we think it is.
 
-To check that it communicates with the right TLS server, curl uses a set of
-locally stored CA certificates to verify the signature of the server's
+To check that it communicates with the right TLS server, curl uses a "CA
+store" - a set of certificates to verify the signature of the server's
 certificate. All servers provide a certificate to the client as part of the
 TLS handshake and all public TLS-using servers have acquired that certificate
 from an established Certificate Authority.
@@ -21,24 +21,39 @@ a TLS server even if the certificate verification fails. You then accept the
 fact that your communication may be subject to Man-In-The-Middle attacks. You
 lower your guards with the `-k` or `--insecure` option.
 
-## CA store
+## Native CA stores
 
-curl needs a "CA store", a collection of CA certificates, to verify the TLS
-server it talks to.
+Operating systems like Windows and macOS tend to have their own CA stores.
 
-If curl is built to use a TLS library that is "native" to your platform,
-chances are that library uses the native CA store as well. If not, curl has to
-either have been built to know where the local CA store is, or users need to
-provide a path to the CA store when curl is invoked.
+If you run curl with Schannel on Windows, curl uses Windows' own CA store by
+default.
+
+If you run curl with Secure Transport on macOS, curl uses macOS' own CA store
+by default.
+
+If you use curl with any other TLS backend than Schannel or Secure Transport,
+it uses a CA store provided in a separate file or directory, independently of
+the native CA store. However, for some of them you can still ask curl to
+instead prefer the native CA store using the `--ca-native` command line
+option. This option is supported with OpenSSL (and forks), wolfSSL and GnuTLS.
+
+For HTTPS proxies, the corresponding option is called `--proxy-ca-native`.
+
+## CA store in file(s)
+
+If curl is not built to use a TLS library that is native to your platform
+(like Schannel or Secure Transport), it has to either have been built to know
+where the local CA store is, or users need to provide a path to the CA store
+when curl is invoked.
 
 You can point out a specific CA bundle to use in the TLS handshake with the
 `--cacert` command line option. That bundle needs to be in PEM format. You can
 also set the environment variable `CURL_CA_BUNDLE` to the full path.
 
-### CA store on windows
+## CA store on windows
 
-curl built on windows that is not using the native TLS library (Schannel), have
-an extra sequence for how the CA store can be found and used.
+curl built on windows that is not using the native TLS library (Schannel),
+have an extra sequence for how the CA store can be found and used.
 
 curl searches for a CA cert file named `curl-ca-bundle.crt` in these
 directories and in this order: