Using Let’s Encrypt with Imperva Cloud Application Security

Starting as an initiative by a few engineers, Let’s Encrypt is now a certificate authority that provides free automated X.509 certificates to millions of internet sites. With Let’s Encrypt users have access to a more secure and private internet since sites can now provide secure encrypted transport.

How the Certificates Work

In this post, we’ll look into the details of TLS interaction from your web browser. First, you’ll notice that the address of many web sites, such as www.imperva.com, starts with HTTPS, rather than HTTP. This indicates that traffic to that site is encrypted, so that no one can eavesdrop on your communication with the site. The encryption is provided by the TLS protocol between your browser and the web server it is accessing.

A TLS certificate with the encryption keys must be provided and signed by a recognized certificate authority. Creating and maintaining the certificate requires cost and effort, which can be prohibitive for a small site. Let’s Encrypt takes care of these obstacles by providing recognized certificates for free with an automated process.

Let’s Encrypt Certificates

The certificates by Let’s Encrypt are recognized by all major browsers. Their rapid deployment furthers the goal of making TLS-enabled HTTPS the default protocol, as recommended in this Chrome proposal to label HTTP sites as non-secure.

Many hosting providers have built-in Let’s Encrypt support that you can request. If you’re using a provider that does not yet provide the support, use a client that supports ACMS protocol, such as Certbot that automates the process.

×

Nov 26 Upcoming Webinar

The True Cost of API Insecurity and Bot Attacks in 2024

Register Now

How to Get a Certificate

Briefly the steps to obtain a certificate, as detailed at the site, are:

• Demonstrate your control of the site domain, which results in an authorized key pair
• Submit a PKCS#10 Certificate Signing Request signed with the authorized key
• If the signatures are verified, a certificate is issued with the public key from the request

Note that domain-validated certificates are available, but not organization validated or extended validation certificates.

Overcoming Certbot’s Reverse Proxy Limitation

Let’s Encrypt uses a tool called Certbot to automate the lifecycle management of a certificate on a web server. Certbot can automatically install and renew certificates for websites that are detected on the web server. This process requires verifying the challenge key that is used by Let’s Encrypt to validate the web server.

However, this automated process has an existing limitation that prohibits the automation of certificate management when the web server is behind any reverse proxy solution such as Incapsula. The root cause of this limitation is in the TLS handshake that is used to confirm the authenticity of the web server through a challenge verification.

The following steps illustrate the normal Certbot process to issue and install a new certificate:

• Step #1: Obtaining a new certificate
• Step #2: Performing the following challenges:
• Step #3: tls-sni-01 challenge for <domain . com>
• Step #3a: Waiting for verification…
• Step #3b: Cleaning up challenges
• Step #4: Deploying Certificate for <domain . com> to VirtualHost /etc/apache2/apache2.conf

Failure sequence:

• Step #1: Obtaining a new certificate
• Step #2: Performing the following challenges:
• Step #3: tls-sni-01 challenge for <domain . com>
• Step #3a: Waiting for verification…
• Step #3b: Cleaning up challenges
  FAILURE: Failed authorization procedure. domain.net (tls-sni-01): urn:acme:error:tls :: The server experienced a TLS error during domain verification :: remote error: tls: alert(112)

Step 3 is where the authorization procedure fails as Let’s Encrypt’s Certbot attempts to validate the challenge key using port 443 through a reverse proxy-based solution. The TLS handshake sequence on the proxy ultimately breaks the transaction by design as Let’s Encrypt expects a direct handshake with the web server.

To bypass this limitation, you’ll need to use the http-01 method instead of tls-01 by using the following command:

certbot --webroot -w /var/www/ -d 

Result:

root@domain.com-bk2:/var/log/letsencrypt# certbot certonly --webroot -w /var/www/ -d www. domain . com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for 
Using the webroot path /var/www for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Clean up challenge directory /var/www/.well-known/acme-challenge

Important Notes:
Important Notes:
Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/www.domain.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/www.domain.com/privkey.pem
Your cert will expire on 2018-02-11. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run “certbot renew”
This http-01 method syntax can now be scheduled with cron job.

Incorporating Let’s Encrypt Certificates to Incapsula

Incapsula generates certificates via GlobalSign, and also provides an interface to upload a site’s custom certificate. Use that interface if you have Let’s Encrypt certificates that you prefer to continue using. You can upload that certificate from the Incapsula Management Console or, more likely, using the Incapsula API.

See the basic syntax in the API and then proceed to invoke the upload custom certificate API with the following script, using parameters:

• site_id
• certificate file in base64 format
• private key of the certificate in base64 format
• passphrase used to protect the certificate – optional

#!/bin/sh
CERT_B64=`base64 -i a.crt`
KEY_B64=`base64 -i a.key`
curl -d api_id=12345 -d api_key=48d69342-eaec-44cf-8a5c-56c4ff1cd5e8 -d site_id=14081980 -d certificate="$CERT_B64" -d private_key="$KEY_B64" -d passphrase=12345678 https://my.incapsula.com/api/prov/v1/sites/customCertificate/upload

The response structure to the command, when successful, is

{
   "res": 0,
    "res_message": "OK",
    "debug_info":{
        "details":{
            "active":true,
            "expirationDate":1460100446000,
            "revocationError":false,
            "validityError":false,
            "chainError":false,
            "coverageError":true
        },
        "id-info":"999999"
    } 
}

You can use these steps to automate certificate lifecycle management to publish and rotate certificates for websites protected by Incapsula.

Summary

Let’s Encrypt certificates are a great solution to easily and at no cost provide TLS encryption for a site. Incapsula supports the ability to easily upload those certificates to your Incapsula-protected sites by using the Incapsula API.