cancel
Showing results for 
Search instead for 
Did you mean: 

Using Let's Encrypt certificates with Brocade vADC

Baptiste Assmann
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.

 

47 Comments
ArnaudM
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

PaulWallace
Contributor

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

 

ArnaudM
New Contributor

Yes this is fine

ubabiak
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

lbasp
Not applicable

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?

tenajsystems
Occasional 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? 

tenajsystems
Occasional Contributor

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

PaulWallace
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!

 

lbasp
Not applicable

Thanks!

tenajsystems
Occasional 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

tenajsystems
Occasional 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.

ubabiak
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

tenajsystems
Occasional 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?

ubabiak
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

tenajsystems
Occasional 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="[email protected]" and CERTNAME=$(echo "${2}" | sed -n "s/.*'\([^']\+\)'.*/\1/p") to CERTNAME=$(echo "[email protected]" | 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. 

Alan.Braggins
Pulser
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="[email protected]".
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.
tenajsystems
Occasional 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.

tenajsystems
Occasional 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

Alan.Braggins
Pulser

@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.

Alan.Braggins
Pulser

(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".) 

bastos
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:

[email protected]:~# /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,

tenajsystems
Occasional Contributor

So, two of my letsencrypt certs are due for renewal on Feb 1 but the alert trigger doesn't seem to be doing anything. When I look at the zxtm/logs/errors, i just see messages about the certs expiring. These messages repeat every hour. Why isn't the alert script for letsencrypt triggering to auto renew the certs?

Update:

So I set the logging to verbose and from that, I have been able to determine that the renewal is been processed successfully and the cert files are been generated with no issues but its not automatically uploading the cert into vtm after its been renewed. 

 

@ubabiak did you end up figuring out why it wasn't working for you? I have checked the persmission of the .acme directory and both the user and owner have write permissions.

 

@bastos Any luck figuring out a solution for your situation without having to manually run it on the command line?

 

@PaulWallace @Alan.Braggins @Baptiste Assmann any thoughts on these issues? Are any Pulsers monitoring this support forum trend to providing help to customers with these issues? Any assistance with these issues would be greatly appreciated.

Alan.Braggins
Pulser

@tenajsystems I'm afraid nothing immediately springs to mind, but I'm investigating.
Is this a software install, or a virtual appliance? vTM installed as root?
What versions of vTM and of acme.sh are you using?

 

If you add "--debug" to ACMEOPTIONS, do you get any more information?

https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh

(You might want to uncomment the definition of TEST while trying things:

https://github.com/bedis/letsencryptforvtm/blob/master/letsencryptforvtm.sh#L36)

(It's also possible that adding "--home=${ACMEHOME}" to ACMEOPTIONS will help, though I don't think it should be necessary; the acme.sh issues that suggest it are about running from cron or as a systemd service.)

tenajsystems
Occasional Contributor

@Alan.Braggins, its a software install and I believe it was installed as root. I am running vTM 17.4 and acme.sh version v2.7.4

 

I did figureout what the problem was and the fix I implemented was similar to adding ""--home=${ACMEHOME}". Our vTM is running in a cluster so when i configured our setup, I used a shared storage for the vTM. When I initially set it up and requested the ssl cert, it did use the parameter that I set for ACMEHOME but when its time to renew and the vTM alert triggers, acme.sh doesn't use the parameter that is set for ACMEHOME but instead it creates a directory called (/.acme.sh locally on the vTM) and installs the certs there. With this happening and since the alert triggers on all the cluster vTMs they all create the /.acme.sh locally with thier own private keys and when its done requesting the certs, all the cluster then tries to upload thier own version of private and public keys so there is a conflict during the ssl cert update which gives you an error message saying the cert and private key is not a match. Obviously, if the vTM is not in a cluster, then it would work great.

 

Below is what I implemented to kinda fix it (unfortunately, when I figured out this was what was happening, it was already too late and I had already hit the rate limit for duplicate certs.)

 

I added a new parameter in letsencryptforvtm.sh called ACME_CONFIG="--config-home '"/root/.acme.sh/" and then also added it to $ACMEHOME/acme.sh $TEST $ACME_CONFIG $ACMEOPTIONS $ACMEACTION -d ${CERTFILE} $ACMEKEY after that, I manually run the trigger and that seemed to have gone through all the vlaidation process successfully but again, I couldn't get a new cert because I had already hit the rate limit. Should i submit a pull request for these changes? 

 

Note: in order to see what is going on when the alert is triggered, you would have to set the alert mapping to verbose to get the full log entries in zxtm/logs/errors. If you don't set it to verbose, all you will see in the logs would be an alert about the certificates expiring.

Alan.Braggins
Pulser

@bastos, sorry I hadn't seen your post earlier, does setting --home and/or --config-home help in your case?

pwallace
Community Manager

Thanks to @tenajsystems and @ubabiak for your input on this. There is a lot of extra detail in this thread, we will look to roll up all the information into an updated article soon, with more information on deployment options for Let’s Encrypt.

 

P, ...

 

ubabiak
Occasional Contributor

@pwallace: a wrap-up would be great!

Let me add just one more observation: I compared the environment vars between the ( failing ) action-triggered call and the (successful) manual . The only relevant difference seems to be the presence of

LE_WORKING_DIR=/root/.acme.sh

BTW we are on a vmware virtual appliance , running 17.2r1

 

### Environment of automatically triggered script call
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin:/bin
PWD=/opt/zeus
ZEUSHOME=/opt/zeus
LANG=en_US.UTF-8
SHLVL=1
_=/usr/bin/env
### ----------------------------
### Environment of manual call (shortened)
LC_ALL=en_US
USER=admin
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
PWD=/opt/zeus/zxtm/conf/actionprogs
ZEUSHOME=/opt/zeus
LANG=en_US.UTF-8
SHLVL=1
HOME=/root
LOGNAME=admin
LE_WORKING_DIR=/root/.acme.sh

regards

Ulrich

tenajsystems
Occasional Contributor

@Alan.Braggins, so the rate limit for the domain that I was trying to request ssl cert for reset over the weekend so was able to finally renew the certs but was getting this error in the logs: Failed to update SSL Certificate for 'c_domain.com_rsa': Certificate/private key pre-check failed: private key and certificate are not a pair [different 'n'] and A certificate called 'c_domain.com_rsa' already exists so I renamed the cert name in vTM and as soon as I did that, the renewal certs appeared in the vTM catalog. Would you by any chance know why it wasn't able to update the cert untill I went in to manually rename the cert in the vTM for the new cert to show up? 

 

Also, --home=${ACMEHOME} or --config-home=${ACMEHOME} would doesn't work (it gives you Unknown parameter : --config-home=/path/to/certs/directory) as it will give you errors when the alert it triggered. Instead this is what it's supposed to be --home ${ACMEHOME} or --config-home ${ACMEHOME} with no equal sign

Alan.Braggins
Pulser

@tenajsystems Sorry, I don't know why the previous failures would leave the data in a state where a rename is needed to clear a problem. Thanks for the corrections on the home parameter style.

jda
New Contributor

Hi,

 

I am trying to make it work with a wildcard certificate.

I have ready edited the "letsencryptforvtm.sh" file to change the ACMEOPTIONS to "--dns ..." and the certificate is correctly created and stored on the file system.

 

But then I’m struggling on the last part, the importation. The following line does not like the "*" character and treat it as a wildcard.

echo "Catalog.SSL.Certificates.setRawCertificate ${CERTNAME} \"$crt\" " > $CERTDIR/zcli_${CERTFILE}.script

$ZCLI $CERTDIR/zcli_${CERTFILE}.script

 

 

I found a way to make the wildcard work but It’s ugly and there is probable a huge room for improvement.

  

First, you need to make the following change to the "letsencryptforvtm.sh" file:

Replace:

ACMEOPTIONS="--standalone --httpport 88"

With:

ACMEOPTIONS="--dns dns_ovh --dnssleep 240"

Of course if you are not using OVH you gonna have to follow the instruction there https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert to get your file

 

To fix the fact that VTM refuse to have a * in a certificate name:

 

Add the following lines at the begining of the script:

WLD1='c_*.'
WLD2='c_\*.'
WLD3='c_wildcard.'

 

Add the following lines juste before [CERTFILE=$(echo "${CERTNAME}" | cut -d'_' -f 2)]:

CERTNAME="${CERTNAME/$WLD3/$WLD1}"

 

Add the following lines juste before the first [echo "Catalog.SSL.Certificates]:

CERTNAME="${CERTNAME/$WLD2/$WLD3}"

 

Then, you need to create the certificate enclosing the name in single quotes:

./letsencryptforvtm.sh --issue 'c_*.domain.com_rsa'

 

I continue to make more test to validate everything but it's a start...

Alan.Braggins
Pulser

I think just double quoting "$CERTDIR/zcli_${CERTFILE}.script" should fix that, though I haven't tested it, but I suspect there will be other problems.
Edit: I see you've already solved it while I was answering (and that there were other problems), but there doesn't seem to be an option to delete redundant replies, only edit.

jda
New Contributor

Thx for your help!

 

Now i'm trying to make the renew work now. The main problem is that the certificate is named 'c_wildcard.domain.com_rsa' and the script expect 'c_*.domain.com_rsa'

OK... I thnik i found a solution, i'll edit my orriginal post.. I'ts still dirty Smiley Sad

ubabiak
Occasional Contributor
Hey, what about integrating Letsencrypt process as a native feature? That must have been on the roadmap as far as I remember, wasn't it? Given that from now on Chrome is flagging all http sites as insecure, it becomes more and more necessary to automatically renew the certificates in a safe and less clumsy way. Regards Ulrich
pwallace
Community Manager

Thanks @ubabiak - this is something that a number of our customers are already using - if you have a moment, send me a PM - it would be interesting to discuss your own experiences of using Let's Encrypt.

 

ubabiak
Occasional Contributor

Just a short status update regarding the automatic renewal: even after the latest upgrade (18.2 on a VMware appliance) the renewals are not completed automatically . Actually we are using the letsencryptforvtm.sh script from this thread, which was of course not changed by the 18.2 upgrade, but I was thinking that maybe the environment might have changed in 18.2.

 

According to the zxtm error log, the renewal command ran fine, but the certificates are not placed into their respective directory. I looked into letsencryptforvtm.sh, all the steps/commands seem to have been executed. The last step there is to execute the generated *.script files with zcli. Since these *.script files are generated correctly, I manually ran

 

/opt/zeus/zxtm/bin/zcli MYDOMAIN/zcli_MYDOMAIN.script

Result: no error messages, but also no certifcates in the cert directory. After that, I ran the renewal command exactly as logged in the error log:

 

[17/Sep/2018:10:17:24 +0200] INFO actions/letsencrypt_renewal handler_ignore Running program: /opt/zeus/zxtm/conf/actionprogs/letsencryptforvtm.sh "--eventtype=LetsEncrypt SSL Certificate Expiry" "WARN vservers/xxxxxx_ssl vssslcerttoexpire expires=1537764393 Public SSL certificate 'c_xxxxxx_rsa' will expire on Mon, 24 Sep 2018 04:46:33 GMT"

 Manual execution:

/opt/zeus/zxtm/conf/actionprogs/letsencryptforvtm.sh "--eventtype=LetsEncrypt SSL Certificate Expiry" "WARN vservers/xxxxxx_ssl vssslcerttoexpire expires=1537764393 Public SSL certificate 'c_xxxxxxx_rsa' will expire on Mon, 24 Sep 2018 04:46:33 GMT"

 Result: after manually executing the command, the certificates were renewed sucessfully.

 

Regards Ulrich

uostg
Member

I have been waiting for this feature to be introduced natively as I have hit an issue where the vTM doesn't have the socat package which acme.sh requires. However, I can't wait any longer and would like to get it it working as-per the details in this article.

 

@pwallace (or others) - how do I install socat on a Virtual Appliance?

Alan.Braggins
Pulser

@uostg If you can upgrade to a later version of vTM, 18.1 and later include socat.

Otherwise, ssh in to your appliance as the admin user (or see the appropriate section of the Virtual Appliance Installation and Getting Started Guide on console access) and apt-get install socat should do it.

@pwallace, can you give a link to the open access policy and/or more detailed instructions?

uostg
Member

Thanks @Alan.Braggins. I had actually already tried apt-get install socat but it does not exist.

 

[email protected]:~# apt-get install socat
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package socat
pwallace
Community Manager

@uostg - Can you confirm which version you are using? 

 

uostg
Member

@pwallace 17.4

pwallace
Community Manager

@Alan.Braggins asked if I could post a reference to instructions for installing additional software. @ldarby pointed me to this earlier post:

https://community.pulsesecure.net/t5/Pulse-Secure-vADC/Installing-Software-on-a-Traffic-Manager-Appl...

 

 

IngoReimann
New Member

Hi all,

 

thanks for this work. We are using LE-Certificates for a some hundreds of sites. Up to now, we did not use them on the Traffic managers for 2 reasons: Clustering and GLB/DNS round robin.

 

As far as i read this conversation, the clustering problem has been solved, but didn`t make it into the script letsencryptforvtm, right?

Our second problem is - how would you handle two or more clusters, that do not need to know about each other, but serving the same FQDN. You`d have to create the Cert on one node, distribute the challenge token to all other nodes in this cluster, as well as to the other cluster(s). When validation is complete, the certificate has to be installed on the other cluster(s).

 

Simple in theory, but is there any progress in this direction?

 

Best regards,

 

Ingo

metaschemer
Regular Visitor

Having freshly followed these instructions, I am dealing with a slightly different problem. I get the following errors, presumably when the trigger is trying to get a new certificate. I can get a new cert on the command line, but this seems to suggest that acme.sh has exited by the time the request comes back in when automatically triggered.  Obviously, this also triggers all kinds of other alerts throughout our devops. Any suggestions as to where I can look at any logs and why this might be happening? Syslog has failed to reveal anything of import.  

 

Thanks,

 

M.

 

15/Feb/2019:19:44:15 +0000 INFO Virtual Server staging-SSL"Connect failure - Connection refused"  S ******** "letsencrypt" "127.0.0.1:88" - "-" w 491 0 0 0 0 0 0 0 - GET "https://staging.********/.well-known/acme-challenge/13362ac3-f3e3-4638-91d8-50ed18a36158" 

 

15/Feb/2019:19:44:15 +0000 SERIOUS Pool letsencrypt: Pool has no back-end nodes responding

tenajsystems
Occasional Contributor

@metaschemer perhaps

/usr/local/zeus/zxtm/log/errors

might help. Assuming you used the default path during the install. If I recall correctly, that log will show you the command the load balancer runs when the trigger occurs. I would suggest you use that command and run it on the command line to troubleshoot

 

Its been a while but I believe when it triggers, it doesn't run

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

 The load balancer uses a different command during renewal. Hope this helps.

tenajsystems
Occasional Contributor

@pwallace When will LetsEncrypt feature be built into Pulse Secure vTM. This would benefit a lot of vTM customers.

Jay
Occasional Visitor

Followed the instructions above but struggling to get this fully working.

Certificate issuance is fine but nothing showing in the catalog, although no errors at the end of the script.

I will be grateful if anyone able to direct me.

 

J

 

 

jda
New Contributor

Have anyone tried switch to Certbot for certificate management?