1. Overview

An important activity we often perform during sanity testing of an application URL is validating certificates.

In this tutorial, we’ll discuss the usage of the curl command in Linux. We’ll also look at various methods to validate certificates using curl.

2. What Is cURL Used For?

In Linux, cURL stands for “Client URL“. Virtually every internet-using human on the globe uses curl daily. Linux command lines or scripts use curl to transfer data. cURL finds its use in cars, television sets, routers, printers, audio equipment, mobile phones, tablets, set-top boxes, and media players. It’s the internet transfer engine for thousands of software applications in over ten billion installations.

2.1. Checking Certificates

Validating certificates can be complex. First, we have to look for a CDP or OCSP AIA. Only then do we make a request, parse the response, and check that the response is signed against by a CA that is authorized to respond for the certificate in question. 

If it’s a CRL, we need to see if the serial number of the certificate we’re checking is in the list. On the contrary, if it’s OCSP, then we need to see if we’ve received a “good” response. Additionally, we may want to verify that the certificate is within its validity period and chains to a trusted root. We can check the root certificate by querying our platform using the following cURL command: 

$ curl --verbose https://www.google.com

 If the connection is successful and verified by the root certificate, we’ll see the following entry: 

* SSL certificate verify ok.

2.2. Checking Certificate Serial Number & Fingerprint

It’s important to check the serial number and fingerprint of each certificate before installation. We can validate the serial number and fingerprint of a certificate using OpenSSL. Running the following command will return the serial number and SHA1 fingerprint: 

$ openssl x509 -noout -serial -fingerprint -sha1 -inform dem -in RootCertificateHere.crt

We should as well do revocation checks against every intermediate and check the certificate’s fingerprint against the explicit blacklists that Mozilla/Apple/Google/Microsoft maintain.

3. Certificate Validation Methods with cURL

curl performs peer SSL certificate validation by default. This is done using a certificate store that the SSL library can use to make sure the peer’s server certificate is valid.

3.1. Validating Certificates with Command Line Options

When we communicate with HTTPS, FTPS, or other TLS servers using certificates that are signed by CAs present in the store, we can be sure that the remote server is the one it claims to be. However, in order to make sure if:

  • The remote server uses a self-signed certificate
  • We do not install a CA cert store
  • The server uses a certificate signed by a CA that is not included in the store we use
  • The remote host is an impostor impersonating your favorite site, and we want to transfer files from this server

curl, with its command line options, solves our problem and proved to be useful. Let’s quickly check a few of the cases. Firstly, we can tell curl not to validate the peer. With the curl command line tool, we can disable this with:

-k/--insecure

Secondly, to verify the remote server when connecting, we can point out the CA cert with the curl command line tool: 

--cacert [file]

Thirdly, we can add the CA cert for our server to the existing default CA certificate store (usually concatenated in PEM file format) with the following configure options:

--with-ca-bundle=FILE
--with-ca-path=PATH

Lastly, it’s also possible to rely on the built-in default that the crypto library provides. We can achieve this by passing both:

--without-ca-bundle and,
--without-ca-path

Ignoring one of the above methods will cause SSL to report an error (“certificate verify failed”) during the handshake. In consequence, SSL will then refuse further communication with that server.

3.2. Validating Certificates with .pem

Repeatedly, we’ve noticed that there could be a scenario where a site might need to validate more than one cert. In such situations, we have to add the cert for our server to the existing default certificate store. CA certificates in this default certificate store are concatenated in PEM format. 

Let’s, for example, take an embedded device that can contain only a very limited number of server certificates. Now, we want to verify the PEM file we’re putting on the device with curl. However, first, we need to create the PEM file. To create the PEM file, we use openSSL:

$ openssl s_client -connect icanhazip.com:443 -showcerts > icanhazip_com.pem

After storing the certificate part in icanhazip_com.pem, we’ll try to validate with curl:

$ curl --verbose --cacert icanhazip_com.pem https://icanhazip.com

3.3. Validating Certificates with –cert-status

curl has a –cert-status option. As the name implies, it validates the status of the server certificate. 

But, it does not work for many:

$ curl --cert-status https://www.google.com
curl: (91) No OCSP response received

This is because it does not cause curl to make its CSP request. However, it only works if the server is configured with OCSP stapling. Many had better success validating the server certificate’s status using OpenSSL.

3.4. Validating Certificates with HTTPS Proxy Support

We know for a fact that curl can do HTTPS to the proxy separately from the connection to the server. In addition to this, we should also know that this TLS connection is handled separately from the server connection. So, to control the certificate validation, we must use –proxy-insecure and –proxy-cacertWith these options, we ensure that the TLS connection and the trust of the proxy can be kept separate from the TLS connection to the server.

4. Conclusion

In this article, we briefly covered what curl command can do in Linux. Although the focus of the article was on validating certificates using curl, we also discussed how to check the certificate serial number and fingerprint. We then looked at certificate validation methods that use various curl command line options.

Some of these methods employed tools like OpenSSL, depicting the idea that we can obtain an enhanced result by smartly using some of the other popular Linux tools. Towards the end of the article, we did exactly that.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.