I don't know, but the following articles might help with the process once you have one: https://community.pulsesecure.net/t5/Pulse-Secure-vADC/Are-there-guides-to-assist-me-with-migrating-from-Stingray/td-p/36573 https://community.pulsesecure.net/t5/Pulse-Secure-vADC/Upgrading-and-reinstalling-SteelApp-Traffic-Manager-Virtual/ta-p/32981   (Apologies if you've already seen them and that's part of why you want a test lab.) ... View more

vTM can be configured to use a RADIUS server for authentication, would that be a possible solution for your use case? I haven't tried it, but Duo say "Duo integrates with almost any device or system that supports using RADIUS for authentication. In this type of configuration, users will append Duo passcodes — or factor names like phone or push — to their existing passwords when logging in." https://duo.com/docs/radius ... View more

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

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

@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.) ... View more

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

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

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, yo u 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. ... View more