cancel
Showing results for 
Search instead for 
Did you mean: 

Using Let's Encrypt certificates with Brocade vADC

Occasional Contributor

Letsencrypt.org is a free and automated Certificate Authority that makes it easy for organizations to secure websites. It can set up TLS certificates very easily, limited to one domain name (i.e., www.domain.com) and has the advantage that it supports both RSA and ECC certificates.

 

In this article, we show an example of how to configure Let’s Encrypt to work with Brocade vADC, including:

  • Issue new certificates
  • Automated renewal of certificates
  • Install certificates and tools
  • Use both RSA and ECC for performance and maximum compatibility
  • Enable automatic OCSP stapling

 

Introduction

Let’s Encrypt relies on the ACME protocol for Automated Certificate Management Environment, which was developed with automation in mind:

 

  • The software client connects to Let’s Encrypt to issue or renew a certificate
  • An authorization/signature happens to verify you are the owner of the domain
  • The certificate is generated and sent back to the software client

 

We'll use an open source client (acme.sh) to manage communications with Let’s Encrypt and we install a short script (letsencryptforvtm.sh) into Brocade vTM, which is used to issue and renew certificates. Then, we use the Brocade vTM alerting and scripting to trigger certificate renewal automatically through the open source script (acme.sh) to talk to Letsencrypt.org. The steps are as follows:

 

  1. Install the open-source acme.sh client
  2. Install our action script (letsencryptforvtm.sh)
  3. Create a new action type for Brocade vTM
  4. Create a new alert for Brocade vTM
  5. Create a resource pool to manage responses from Letsencrypt.org
  6. Create a TrafficScript rule to manage responses from Letsencrypt.org

 

LetsEncrypt-Pic.png 

 

Installation procedure

This installation procedure can be applied the same way if you're running the Brocade vTM appliance or the Brocade vTM software on your own Linux distribution.

 

Install acme.sh

First, we need to download the open source component to manage the ACME protocol. Login as admin into your vTM through SSH, then run the following commands:

 

curl -LO https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh
chmod +x acme.sh
./acme.sh --install --nocron

 

More options are available when installing acme.sh. For more information, please read https://github.com/Neilpang/acme.sh/wiki/How-to-install.

 

Install letsencryptforvtm.sh

Next, we need to download and install the short script that is used to issue and renew certificates and communicate with the acme.sh component.

 

 

This script can be run manually to issue a new certificate and insert into Brocade vTM, but we need to load it into the Brocade vTM Catalog, so that it can be called automatically to renew certificates.

 

  • Connect to the Brocade vTM Web UI, then navigate to
    Catalogs > Extra Files > Action Programs
  • Click on the Choose File button and point to the letsencryptforvtm.sh script
  • Click on the Upload Program button

L-UploadProgram.png

 

Set up a new Action

Now, we need to create a new action, which will be called when a certificate is about to expire.

 

  • Connect to the Web UI, then navigate to System > Alerting
  • Click on the Manage Actions link
  • Complete the "Create new action" form:

 Name: letsencrypt_renewal

 Type: Program

 

L-CreateAction.png

 

  • Click on Add action
  • On the next page, in Additional Settings:

Program: choose letsencryptforvtm.sh

  • Click on the Updatebutton at the bottom of the page

L-CreateAction-AdditionalSettings.png

 

Create a new Alert mapping

In Brocade vTM, an alert maps an event to an action. In our case, we'll match the event "Certificate is about to expire" to the action we've created at the step before.

 

  • Connect to the Web UI, then browse System> Alerting
  • In Select Event Type, choose SSL Certificate Expiry
  • As an action, choose letsencrypt_renewal

L-CreateMapping.png

 

Note: the SSL Certificate Expiry will match for all certificates configured into Brocade vTM, whether or not they were issued by Let’s Encrypt. It is possible to create a copy of this event, named SSL Certificate Expiry Lets Encrypt and match only the vservers where your Let’s Encrypt certificates are enabled.

 

Create a pool for the acme.sh script

The purpose of this pool is to send ping back from Let’s Encrypt. While we are running acme.sh, we will need to make it listen for http requests on port 88.

Note that once the certificate has been renewed or issued, then acme.sh will shutdown the port.

 

  • Connect to the Web UI, then browse Services > Pools
  • Complete the Create a new pool form as below:

Pool name: p_letsencrypt

Nodes: 127.0.0.1:88

Monitor: Ping

 

  • Click on the Create Pool button

L-CreatePool.png

 

Create a new TrafficScript rule

The purpose of this rule is to route ping back from letsencrypt.org to the pool which we created (p_letsencrypt) - which itself will route the request to the acme.sh script.

 

  • Connect to the Web UI, then browse Catalogs > Rules
  • Complete the Create a new rule form with the following information:

Name: route_to_acme.sh

Check the Use TrafficScript Language
 option

Click on the Create Rule button

  • In the next page, complete the form as below:

Notes: Route traffic related to acme.sh (letsencrypt)

Rule: As shown here:

$path = http.getPath();
if( string.containsI( $path, "acme-challenge" ) ) {   
   pool.use("p_letsencrypt");
}

  • Click on the Update button
  • Later, you will add this rule to the vserver for your application

L-CreateRule.png

 

 

Complete your environment

If you have not already set up your application with a vserver, you will need to create a vserver listening on port 80 on the IP address pointed by the domain for which you are issuing the certificate.

 

Now you can enable the TrafficScript rule route_to_acme.sh into the vserver which is managing the domain. This should be one of the first rules in the list.

 

Generate a new certificate

In order to generate a new certificate for our application, we need to run the script to request a new certificate from Let’s Encrypt:

 

  • Connect to vTM using ssh
  • Run the following command for an ECC certificate:
./letsencryptforvtm.sh --issue c_www.domain.com_ecc

 

  • Alternatively, run this command to request an RSA certificate:
./letsencryptforvtm.sh --issue c_www.domain.com_rsa

 

The new certificate is automatically inserted into Brocade vTM, which you can confirm by navigating to Catalogs > SSL. You can now navigate to your vserver, enable SSL offloading and select the new certificate.

 

Let’s Encrypt certificate chain

The letsencryptforvtm.sh script takes care of this task for you. When inserting the certificate into Brocade vTM, the script uses the full chain, including the certificate for the domain and the required intermediaries.

 

Renew a Let’s Encrypt certificate

When the certificate is due for renewal, our script should take care of the certificate renewal. Seven days before expiration, the alert mapping will run the letsencryptforvtm.sh script with the name of the certificate as an argument.

If, for some reasons, Let’s Encrypt is not available at the first execution, Brocade vTM will attempt to call letsencryptforvtm.sh every hour until the certificate is renewed.

 

OCSP stapling

Brocade vTM can use information available in the certificate to process OCSP stapling automatically. This feature works out of the box with Let’s Encrypt certificates.

 

All you need to do is to enable ssl_ocsp_stapling in your vserver when configuring SSL Decryption.

 

L-OCSP.png

 

Using the TEST environment variable

It is highly recommended to use the Let’s Encrypt test / staging environment during the installation phase. Otherwise, Let’s Encrypt may blacklist your domain if you generate too many certificates.

 

In order to use the test environment, edit letsencryptforvtm.sh script and search for the TEST variable: uncomment the TEST variable and re-upload the script into Catalogs > Extra Files > Actions.

 

Once the full procedure is validated and you want to move to production, simply comment out the TEST variable line and re-upload the script into Catalogs > Extra Files > Actions.

 

21 Comments
New Contributor

Hello,

 

In vTM 10.4r1, this is not possible to name an Event Type with a quote, so I'd edit the following note not to suggest calling it "SSL Certificate Expiry Let’s Encrypt"

 

Otherwise you can't create an Alert Mapping.

 

 

Note: the SSL Certificate Expiry will match for all certificates configured into Brocade vTM, whether or not they were issued by Let’s Encrypt. It is possible to create a copy of this event, named SSL Certificate Expiry Let’s Encrypt and match only the vservers where your Let’s Encrypt certificates are enabled.

 

Arnaud

Contributor

Thanks ArnaudM, well spotted - let me know if the correction is ok

 

New Contributor

Yes this is fine

Occasional Contributor

Baptiste Assmann wrote:

This installation procedure can be applied the same way if you're running the Brocade vTM appliance or the Brocade vTM software on your own Linux distribution.

 

First of all thank you for developing this lets-encrypt-workaround. 

 

An annotation for anyone who follows these step-by-step-instructions:

 

I set up and tested  the process with the TEST variable enabled. Even after disabling TEST for production, I kept getting test certificates ("CN=Fake LE Intermediate X1" ) for the domains that i used during the test. Probably acme.sh was caching some values? Since I didn't have the time for extended debugging, I simply deleted the .acme.sh directory and re-installed acme.sh. From then on, correct production certs were generated.

Great!

 

Now I wonder  how to  protect the letsencrypt setup from being erased on every system upgrade if using the (virtual/VMware) Appliance ? Currently, I am hiding my custom stuff inside a directory on the /logs/ partition .... But maybe  the next update already contains the native LetsE-Support  so no protection is needed?

Regards,

Ulrich

N/A

the latest acme.sh uses socat instead of nc and the vtm 17.3 does not provide this package. does anybody already has a workaround for this?

New Contributor

If I wanted to generate a cert for a domain that had an alias (example: example.com and alias www.example.com), how would I accomplish this? 

New Contributor

@lbasp assuming you are running ubuntu, you can install socat by using command: "sudo apt-get update && sudo apt-get install socat"

Contributor

Thanks @tenajsystems - you can install socat under the open access policy for the Virtual Appliance. We may also review the install profile of the Virtual Appliance for future releases. Thanks!

 

N/A

Thanks!

New Contributor

@PaulWallace, when I run the script "./letsencryptforvtm.sh --issue c_example.com_rsa" Its able to request for the cert and everything is successful but I am getting the errors below:
Broken installation: missing components.
Broken installation: missing components.

 

As a result, the cert is not uploading into the VTM catalog. What I'm I missing? I am running VTM version 17.3

New Contributor

Regarding my previous comment on the error about "Broken installation: missing components". I figured out what was causing it. I forgot to delete the brocade VTM installer after I installed VTM so the find command in the script to locate zcli was finding both the zcli from the installer and the zcli tool on the system and couldn't figureout which zcli tool to use. After I deleted the VTM installer, the error went away.

Occasional Contributor

I am using a vATM virtual appliance. 3 months after successfully installing a letsencrypt cert, I encountered the first expiry action.

According to zxtm/log/errors, the script was called with the following parameters when the expiry alert was triggered:

[08/Nov/2017:12:48:43 +0100]    INFO    actions/letsencrypt_renewal     handler_ignore  Running program: /opt/zeus/zxtm/conf/actionprogs/letsencryptforvtm.sh "--eventtype=LetsEncrypt SSL Certificate Expiry" "WARN vservers/MY_VHOST vssslcerttoexpire expires=1510742940 Public SSL certificate 'c_www.MYDOMAIN.XX_rsa' will expire on Wed, 15 Nov 2017 10:49:00 GMT"
[08/Nov/2017:12:48:45 +0100]    INFO    actions/letsencrypt_renewal     handler_ignore  Program finished

However, there was no new cert, the expiry warning persisted. Since there is no other logging output, I could not figure out what went wrong. Calling the script manually using the "admin" account (= root on the vATM) on the command line with the exact same parameters worked fine, so I assume it might have been a permission problem on the .acme.sh subdirectory.

 

I would suggest to revise the acme.sh postinstallation instructions regarding the permissions, +x is probably not sufficient.

 

Regards,

Ulrich

New Contributor

@ubabiak, what permissions was sufficient that worked for you? I am also waiting for the automatic renewal to trigger so it would be nice to fix this before that time comes. Also, once the persmisson is changed, does it need to be reinstalled?

Occasional Contributor

Hi,

 

I did the renewal on the command line first, and only afterwards I looked into the permissions. So I can't tell you whether the changes were sufficient.  The renewal process touches/creates some files below the .acme.sh directory, so I made this directory and the specific vhost subdirectory  world writable.  However there is a one week period between the first alarm event and the expiry, so that should give you enough time to renew the cert.

 

These are the files that were modified:

 

#find .acme.sh -mtime -2 
.acme.sh/account.conf
.acme.sh/www.MYDOMAIN.de
.acme.sh/www.MYDOMAIN.de/www.MYDOMAIN.de.conf
.acme.sh/www.MYDOMAIN.de/ca.cer
.acme.sh/www.MYDOMAIN.de/www.MYDOMAIN.de.cer
.acme.sh/www.MYDOMAIN.de/zcli_www.MYDOMAIN.de.script
.acme.sh/www.MYDOMAIN.de/www.MYDOMAIN.de.csr.conf
.acme.sh/www.MYDOMAIN.de/fullchain.cer
.acme.sh/www.MYDOMAIN.de/www.MYDOMAIN.de.csr
.acme.sh/http.header

Regards

Ulrich

New Contributor

 So for the letsencryptforvtm script, I am trying to make it take domains that have alternate names (example: domain.com and www.domain.com). I have tried changing CERTNAME="${2}" to CERTNAME="$@" and CERTNAME=$(echo "${2}" | sed -n "s/.*'\([^']\+\)'.*/\1/p") to CERTNAME=$(echo "$@" | sed -n "s/.*'\([^']\+\)'.*/\1/p") but it keeps getting stuck at echo "error: wrong CERTTYPE". I am running it like this: 

./letsencryptforvtm.sh --issue c_domain.com_rsa c_www.domain.com_rsa

 What I'm i doing wrong? I want to be able to request an ssl cert for a domain that has multiple aliases. 

The script does not currently support multiple domain names, and assumes that the domain name can be extracted from the certificate name.
 
The problem with just changing ${2} to ${@} is that ${1}, i.e. "--issue", will be included in the array, so parsing a certificate type from it will fail. Try using shift; CERTNAME="$@".
However, there should be only one certificate file and only one certificate type, so you might want to derive them from ${2} in any case.
 
Where the script passes -d ${CERTFILE} to acme.sh, you will want to pass all your domains, for example:
acme.sh --issue -d example.com -d www.example.com -d cp.example.com
The details of changing the script to handle an array of names here are beyond the scope of this comment.

In the "# $1 is eventtype and may be ignored" case, vTM will only generate alerts for a single certificate at once, so you would have to retrieve details of the existing certificate before trying to renew it for the same list of domains. Doing so is also beyond the scope of this comment.
New Contributor

@Alan.Braggins, Thanks for your response. If i understand you correctly, you can't have one cert with multiple alternate domain names in that one cert file? I want to make sure I am not missing anything. When I say multiple domain names, I don't mean different domain certs.

New Contributor

Is there a reason why a pool listening on 127.0.0.1:88 needs to be created? and the below rule is used to route the traffic

$path = http.getPath();
if( string.containsI( $path, "acme-challenge" ) ) {   
   pool.use("p_letsencrypt");
}

I know the the acme standalone uses port 88. When I don't have the rule above or pool in place, everything still works. I want to make sure I fully understand the process. If someone can share some light on this, that would be much appreciated

@tenajsystems You can use certificates with multiple domain names in Pulse Virtual Traffic Manager (formerly Brocade vADC), but this script can't be used in its current state to request such certificates, nor to correctly renew them. (We do know that would be a useful improvement, but if you can give more details of your use case to support or a sales engineer, that might be helpful. I can't commit to any improvements or dates though.)

 

 

I'm surprised that everything appears to work without the p_letsencrypt pool; https://letsencrypt.org/how-it-works/ is slightly out of date, but the purpose of the rule is effectively to implement the "The CA verifies the signature on the nonce, and it attempts to download the file from the web server and make sure it has the expected content" step.

 

The ACME protocol says 'The path at which the resource is provisioned is comprised of the fixed prefix "/.well-known/acme-challenge/", followed by the "token" value in the challenge. The value of the resource MUST be the ASCII representation of the key authorization.'

There are other ways in which this could be done, but the only ways I can think of that would accidentally seem to work without deliberate work would be:

  • You don't have a virtual server listening on port 80, acme.sh is running in standalone mode on port 80, and Let's Encrypt is talking to acme.sh directly
  • You have a virtual server listening on port 80, and your default pool is a webserver which shares a file system with the one the acme standalone script was using in a way that meant the right response was served by default.

I can imagine that being possible in a testing environment, but it seems unlikely.

(https://letsencrypt.org/how-it-works/ says "Provisioning an HTTP resource under a well-known URI on https://example.com/", but https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md says "Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS" and "This request MUST be sent to TCP port 80 on the HTTP server".) 

Occasional Visitor

Hi all, 

We have a behaviour close to what @ubabiak reported for the renewal.

 

When the action triggers the script ends with no error, but there's no new certificate and the warning persists. After making the script a little more verbose, we finally saw this from acme.sh '....is not a issued domain, skip' :

 

 

INFO 07/Dec/2017:01:33:19 +0100 INFO Action SSL_RENEWAL: Program finished
Thu Dec 7 01:33:15 CET 2017 'domain.example.com' is not a issued domain, skip.
Thu Dec 7 01:33:15 CET 2017 Renew Done!
Thu Dec 7 01:33:15 CET 2017 Renew: 'domain.example.com'
INFO 07/Dec/2017:01:33:15 +0100 INFO Action SSL_RENEWAL: Running program: /opt/zeus/zxtm/conf/actionprogs/letsencryptforvtm.sh "--eventtype=Letsencrypt SSL Certificate Expiry" "WARN vservers/vs-https vssslcerttoexpire expires=1513210020 Public SSL certificate 'c_domain.example.com_rsa' will expire on Thu, 14 Dec 2017 00:07:00 GMT"
INFO 07/Dec/2017:01:33:15 +0100 INFO
WARN 07/Dec/2017:01:33:15 +0100 WARN Virtual Server vs-https: Public SSL certificate 'c_domain.example.com_rsa' will expire on Thu, 14 Dec 2017 00:07:00 GMT

 

But running the exact same command as root runs fine:

root@zeus01:~# /opt/zeus/zxtm/conf/actionprogs/letsencryptforvtm.sh "--eventtype=Letsencrypt SSL Certificate Expiry" "WARN vservers/vs-https vssslcerttoexpire expires=1513210020 Public SSL certificate 'c_domain.example.com_rsa' will expire on Thu, 14 Dec 2017 00:07:00 GMT"

[Thu Dec  7 02:39:45 CET 2017] Renew: 'domain.example.com'
[Thu Dec  7 02:39:45 CET 2017] Standalone mode. 
[Thu Dec  7 02:39:45 CET 2017] Single domain='domain.example.com'
[Thu Dec  7 02:39:45 CET 2017] Getting domain auth token for each domain
[.....]
[Thu Dec  7 02:39:53 CET 2017] Success
[Thu Dec  7 02:39:53 CET 2017] Verify finished, start to sign.
[Thu Dec  7 02:39:54 CET 2017] Cert success.

 

Any idea what could be wrong ?

Regards,