Curl Command for Https ( Ssl )

curl: how to specify target hostname for https request

Indeed SNI in TLS does not work like that. SNI, as everything related to TLS, happens before any kind of HTTP traffic, hence the Host header is not taken into account at that step (but will be useful later on for the webserver to know which host you are connecting too).

So to enable SNI you need a specific switch in your HTTP client to tell it to send the appropriate TLS extension during the handshake with the hostname value you need.

In case of curl, you need at least version 7.18.1 (based on https://curl.haxx.se/changes.html) and then it seems to automatically use the value provided in the Host header. It alo depends on which OpenSSL (or equivalent library on your platform) version it is linked to.

See point 1.10 of https://curl.haxx.se/docs/knownbugs.html that speaks about a bug but explains what happens:

When given a URL with a trailing dot for the host name part: "https://example.com./", libcurl will strip off the dot and use the name without a dot internally and send it dot-less in HTTP Host: headers and in the TLS SNI field.

The --connect-to option could also be useful in your case. Or --resolve as a substitute to /etc/hosts, see https://curl.haxx.se/mail/archive-2015-01/0042.html for am example, or https://makandracards.com/makandra/1613-make-an-http-request-to-a-machine-but-fake-the-hostname
You can add --verbose in all cases to see in more details what is happening. See this example: https://www.claudiokuenzler.com/blog/693/curious-case-of-curl-ssl-tls-sni-http-host-header ; you will also see there how to test directly with openssl.

If you have a.example in your /etc/hosts you should just run curl with https://a.example/ and it should take care of the Host header and hence SNI (or use --resolve instead)

So to answer your question directly, replace

curl --header 'Host: a.example' https://x.example

with

curl --connect-to a.example:443:x.example:443 https://a.example

and it should work perfectly.

Invoking mutual 2 way SSL webservice using CURL

The --cacert is used to specify the file with the public certificate of the Certification Authority (CA). If you installed 3rd party CA certificate on your system, this option is not needed.

With the --cert you specify the signed client certificate which was issued to you based on your CSR. From man curl:

-E, --cert <certificate[:password]>

Tells curl to use the specified client certificate file when getting a file with HTTPS, FTPS or another SSL-based protocol. The certificate must be in PKCS#12 format if using Secure Transport, or PEM format if
using any other engine. If the optional password isn't specified, it will be queried for on the terminal. Note that this option assumes a "certificate" file that is the private key and the client certificate concate‐
nated! See -E, --cert and --key to specify them independently.

Currently, you are passing CSR (certificate signing request) via --cert parameter. Your command should look something like this:

curl --cacert ./3rd-party-ca-cert.pem --key ./myfile-pr.key --cert ./serverfile.pem --pass <password>   https://serverpost:port/getEmployeeInfo

As I mentioned, the --cacert might not be needed if you already added this CA (e.g. on ubuntu https://superuser.com/a/719047).

Check serverfile.pem to make sure it contains only client certificate, and not 3rd party CA certificate chain as well.

How to check if PHP CURL SSL works

On the server side, php -i | grep openssl will tell you if SSL is enabled. If you want to test the SSL protocol, just use https:// in a curl request: curl https://your_server_name.

cUrl with mutual authentication

Yes you need to add --cacert option to the curl command if you have it downloaded or a self-signed certificate (in my case)

curl --key client.key --cert client.crt --cacert bundle.pem -X GET -v https://x.x.x.x:xxxx/folder/endpoint.

The bundle.pem has the server.crt and rootCA.crt.

cat server.crt rootCA.crt >> bundle.pem



Related Topics



Leave a reply



Submit