Difference between revisions of "Funny Curly things"
Line 15: | Line 15: | ||
=CA & sub-CA setup= | =CA & sub-CA setup= | ||
− | - | + | First we create a Certificate Authority (CA) using the <tt>easy-rsa</tt> scripts as found in OpenVPN. The resulting <tt>ca.pem</tt> has the following subject: |
+ | $ openssl x509 -subject -issuer -noout -in ca.pem | ||
+ | subject= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=Nikhef CA | ||
+ | issuer= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=Nikhef CA | ||
+ | |||
+ | Next we create a sub-CA and sign it using the CA from the previous step: | ||
+ | $ openssl x509 -subject -issuer -noout -in subca.pem | ||
+ | subject= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=subca | ||
+ | issuer= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=Nikhef CA | ||
+ | |||
+ | The server certificate for host 127.0.0.1 is signed by the CA itself: | ||
+ | $ openssl x509 -subject -issuer -noout -in server.pem | ||
+ | subject= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=127.0.0.1 | ||
+ | issuer= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=Nikhef CA | ||
+ | |||
+ | But the client certificate is signed by the subCA: | ||
+ | $ openssl x509 -subject -issuer -noout -in client.pem | ||
+ | subject= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=client | ||
+ | issuer= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=subca | ||
+ | |||
+ | A tarball containing the entire certificate setup used for this investigation is available: [curl-ca.tar.gz] | ||
+ | |||
+ | The idea behind this CA and sub-CA setup is that we will configure the server to trust all certificates signed by the CA only. If a client certificate is signed by the sub-CA then the client must present both its certificate and the sub-CA certificate to the server. This is more or less the reverse to what happens with most SSL-enabled websites: the browser trusts only a set of root CAs so the HTTPS webserver has to present all intermediary certificates to the browser, otherwise the browser will not trust the server. | ||
=Testing setup= | =Testing setup= |
Revision as of 14:25, 21 September 2011
Introduction
The curl tool is sometimes very handy to query grid services. For example, you can use curl to query the status of grid jobs, and in theory you could even submit a grid job using curl.
Starting with Fedora 12, RedHat has decided to change the way curl is built by default. As Fedora 12 is the 'baseline' for RedHat Enterprise Linux 6, this also affects the curl command in RHEL6, CentOS6 and Scientific Linux 6. In the past, curl was built and linked using the OpenSSL libraries. With Fedora 12+/RHEL6+, curl is now built and linked using the NSS library. This has an impact on how you can use curl to query different grid services.
The problem does not apply to grid services only, every site that requires a client-side certificate chain, that is, the client needs to present both a certificate and an intermediary key, is affected.
This page is the result of a comparison of the different SSL libraries that curl can be built against. The following SSL libraries were tested, using curl-7.22.0, which was the latest and greatest version of curl at the time of writing:
- OpenSSL 1.0.0d
- NSS 3.12.10
- GnuTLS 2.8.6
- PolarSSL 0.14.3
CA & sub-CA setup
First we create a Certificate Authority (CA) using the easy-rsa scripts as found in OpenVPN. The resulting ca.pem has the following subject:
$ openssl x509 -subject -issuer -noout -in ca.pem subject= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=Nikhef CA issuer= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=Nikhef CA
Next we create a sub-CA and sign it using the CA from the previous step:
$ openssl x509 -subject -issuer -noout -in subca.pem subject= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=subca issuer= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=Nikhef CA
The server certificate for host 127.0.0.1 is signed by the CA itself:
$ openssl x509 -subject -issuer -noout -in server.pem subject= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=127.0.0.1 issuer= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=Nikhef CA
But the client certificate is signed by the subCA:
$ openssl x509 -subject -issuer -noout -in client.pem subject= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=client issuer= /C=NL/L=Amsterdam/O=Nikhef/OU=Curl-test/CN=subca
A tarball containing the entire certificate setup used for this investigation is available: [curl-ca.tar.gz]
The idea behind this CA and sub-CA setup is that we will configure the server to trust all certificates signed by the CA only. If a client certificate is signed by the sub-CA then the client must present both its certificate and the sub-CA certificate to the server. This is more or less the reverse to what happens with most SSL-enabled websites: the browser trusts only a set of root CAs so the HTTPS webserver has to present all intermediary certificates to the browser, otherwise the browser will not trust the server.
Testing setup
- openssl s_server
Appendix: building curl
For completeness' sake this appendix lists how the different versions of curl were actually built.
All builds were done on a Fedora 14 x86_64 machine.
curl/OpenSSL
$ tar xzf curl-7.22.0.tar.gz $ mv curl-7.22.0 curl-7.22.0-openssl $ cd curl-7.22.0-openssl $ ./configure --with-ssl=/usr/include --without-nss $ make
To verify that the right curl, and more importantly, libcurl.so were created I ran
$ LD_LIBRARY_PATH=lib/.libs src/.libs/curl -V curl 7.22.0 (x86_64-unknown-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.0 zlib/1.2.5 Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp Features: IPv6 Largefile NTLM NTLM_WB SSL libz
curl/NSS
$ tar xzf curl-7.22.0.tar.gz $ mv curl-7.22.0 curl-7.22.0-nss $ cd curl-7.22.0-nss $ ./configure --with-nss --without-ssl $ make
To verify that the right curl, and more importantly, libcurl.so were created I ran
$ LD_LIBRARY_PATH=lib/.libs src/.libs/curl -V curl 7.22.0 (x86_64-unknown-linux-gnu) libcurl/7.22.0 NSS/3.12.10.0 zlib/1.2.5 Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp Features: IPv6 Largefile NTLM NTLM_WB SSL libz
curl/GnuTLS
$ tar xzf curl-7.22.0.tar.gz $ mv curl-7.22.0 curl-7.22.0-gnutls $ cd curl-7.22.0-gnutls $ ./configure --with-gnutls=/usr/include --without-nss --without-ssl $ make
To verify that the right curl, and more importantly, libcurl.so were created I ran
$ LD_LIBRARY_PATH=lib/.libs src/.libs/curl -V curl 7.22.0 (x86_64-unknown-linux-gnu) libcurl/7.22.0 GnuTLS/2.8.6 zlib/1.2.5 Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp Features: IPv6 Largefile NTLM NTLM_WB SSL libz
curl/PolarSSL
$ tar xzf curl-7.22.0.tar.gz $ mv curl-7.22.0 curl-7.22.0-polarssl $ cd curl-7.22.0-polarssl $ ./configure --with-polarssl=/usr/include --without-nss --without-ssl --disable-ntlm-wb $ make
Note: if I did not add --disable-ntlm-wb then the build failed in the linking phase
To verify that the right curl, and more importantly, libcurl.so were created I ran
$ LD_LIBRARY_PATH=lib/.libs src/.libs/curl -V curl 7.22.0 (x86_64-unknown-linux-gnu) libcurl/7.22.0 PolarSSL zlib/1.2.5 Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp Features: IPv6 Largefile SSL libz