1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
Peer SSL Certificate Verification
=================================
libcurl performs peer SSL certificate verification by default. This is done
by using CA cert bundle that the SSL library can use to make sure the peer's
server certificate is valid.
If you communicate with HTTPS or FTPS servers using certificates that are
signed by CAs present in the bundle, you can be sure that the remote server
really is the one it claims to be.
Until 7.18.0, curl bundled a severely outdated ca bundle file that was
installed by default. These days, the curl archives include no ca certs at
all. You need to get them elsewhere. See below for example.
If the remote server uses a self-signed certificate, if you don't install a CA
cert bundle, if the server uses a certificate signed by a CA that isn't
included in the bundle 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 cert bundle.
The default path of the CA bundle used can be changed by running configure
with the --with-ca-bundle option pointing out the path of your choice.
To do this, you need to get the CA cert for your server in PEM format and
then append that to your CA cert bundle.
If you use Internet Explorer, this is one way to get extract the CA cert
for a particular server:
o View the certificate by double-clicking the padlock
o Find out where the CA certificate is kept (Certificate>
Authority Information Access>URL)
o Get a copy of the crt file using curl
o Convert it from crt to PEM using the openssl tool:
openssl x509 -inform DES -in yourdownloaded.crt \
-out outcert.pem -text
o Append the 'outcert.pem' to the CA cert bundle 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:
o openssl s_client -connect xxxxx.com:443 |tee logfile
o type "QUIT", followed by the "ENTER" key
o The certificate will have "BEGIN CERTIFICATE" and "END CERTIFICATE"
markers.
o 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.
o If you want to trust the certificate, you can append it to your
cert_bundle 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:
http://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
cert bundle, will cause SSL to report an error ("certificate verify failed")
during the handshake and SSL will then refuse further communication with that
server.
Peer SSL Certificate Verification with NSS
==========================================
If libcurl is build 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. With OpenSuSE this lib is missing, and NSS
can only work with its own internal formats. Also NSS got a new database
format:
https://wiki.mozilla.org/NSS_Shared_DB
Starting with version 7.19.7 libcurl will check for the NSS version it runs,
and add automatically the 'sql:' prefix to the certdb directory (either the
hardcoded default /etc/pki/nssdb or the directory configured with SSL_DIR
environment variable) if a version 3.12.0 or later is detected.
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, modsec.db.
Usually these cert databases are empty; but NSS also has built-in CAs which are
provided through a shared library libnssckbi.so; if you want to use these
built-in CAs then create a symlink to libnssckbi.so in /etc/pki/nssdb:
ln -s /usr/lib[64]/libnssckbi.so /etc/pki/nssdb/libnssckbi.so
|
