romenskiy2012/curl
1
0
Fork 0
mirror of https://github.com/curl/curl.git synced 2026-08-26 00:33:34 +03:00
Code Issues Projects Releases Packages Wiki Activity

docs: reduce/avoid English contractions

Browse source 
You're => You are
Hasn't => Has not
Doesn't => Does not
Don't => Do not
You'll => You will
etc

Closes #7930
This commit is contained in:
Daniel Stenberg 2021-10-31 16:34:44 +01:00
parent d3d079c138
commit a28464ae77
No known key found for this signature in database
GPG key ID: 5CC908FDB71E12C2
265 changed files with 926 additions and 925 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/SSLCERTS.md
View file

@ -13,7 +13,7 @@ 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
certificates. If you are not sure, then run "curl -V" and read the results. If
the version string says `Schannel` in it, then it was built with Schannel
support.
@ -22,11 +22,11 @@ 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
server certificates you see are valid. they are 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
operating system trusts, or the set one of the known browsers trust. That is
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.
@ -42,8 +42,8 @@ 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
If the remote server uses a self-signed certificate, if you do not install a CA
cert store, if the server uses a certificate signed by a CA that is not
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:
@ -103,11 +103,11 @@ server, do one of the following:
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
4. If you are using the curl command line tool, you can specify your own CA
cert file 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
If you are 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
@ -122,7 +122,7 @@ server, do one of the following:
way for you: [CA Extract](https://curl.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 that is not 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.