NSX ALB LetsEncrypt script parameters and usage

    In one of my previous posts about NSX ALB (Avi) and Let's Encrypt integration LINK, I explained how useful could be implementing service like this, especially in Customer environment where large number of different DNS records exist, serving different virtual services using legitimately known and signed digital certificate. Based on main part of this functionality, GitHub script used for certificate management service inside NSX ALB (LINK - v0.9.7 actual at the time of writing), I would like to show you different options available and useful depending on different use cases and scenarios.
    Parameters used by script are well defined and usable inside certificate management configuration on NSX ALB:
  • user / password - self explained and needed by certificate management service for successful run of script. Permissions using custom role defined as read & write access enabled for Virtual Service, Application Profile, SSL/TLS Certificates and Certificate Management Profile, inside NSX ALB (Avi);
  • tenant - used inside NSX ALB (Avi), by default admin created on initial setup;
  • dryrun - parameter which can use True/False values. I recommend using this parameter as Dynamic, which enables direct change during certificate creation if needed and leaving it as False as already on default. Main purpose of this parameter is to avoid Let's Encrypt rate limiting penalties described HERE, and in case having large number of certs generated inside NSX ALB this could happen easily. Dryrun-ed certificates can't be used on production virtual services, but limits on their generation is much higher because they are using staging environment of Let's Encrypt service (described HERE). Important note here - if you upgraded NSX ALB (Avi) and because of that upgrade you needed to change Let's Encrypt script version, which is very real scenario, you may encounter hitting Let's Encrypt rate limiting penalties because there will be large number of unsuccessful certificates in renewal process (ie old script v0.9.5 is not working properly on NSX ALB (Avi) v21.1.5, like myself 😞) - which means that best option is to change this dryrun parameter to TRUE, until proper validation of new script version interoperability with upgraded NSX ALB (Avi) version is confirmed;
  • contact - self explained inside script as E-mail sent to Let's Encrypt during account creation;
  • directory_url - in case you need to change ACME server from default Let's Encrypt Production, if you setup something in-house for these activities;
  • overwrite_vs - self explained inside script content, just be careful on fact that it changes on backup/restore activities using Export/Import function on virtual service inside NSX ALB (Avi);
  • letsencrypt_key - Let's Encrypt account key - useful parameter in case of large numbers on certificates resolved using this public service. If not specified every resolved certificate will use new account key, but for large integrators it's useful to use one key (as described HERE). In case you decide to go with this parameter just generate any RSA 4096 key length key and pass as value for this parameter, which is going to be used always for future certs generation.
    One of not described parameters, and useful scenarios where it can be used is disable_check, but you can find more on that HERE.   
    As always, planned activities on upgrades and patching must be planned accordingly, covering script integration like Let's Encrypt inside NSX ALB (Avi) and making sure that beside operational symptoms you do not get banned or rate limited from this useful digital cert automation system 👍

Comments

Post a Comment

Popular posts from this blog

NSX ALB LetsEncrypt with DNS-01 challenge - BIND example

    In some of my previous posts, mentioned here LetsEncrypt script integration and Script parameter usage , I explained how useful it can be for NSX advanced load balancing solutions to utilise this kind of approach for free and automatic certificate manipulation, especially in environments with large number of web services inside. This approach utilises HTTP-01 based challenge with LetsEncrypt systems and L7 HTTP/S virtual services on NSX ALB side.     Now, from some time ago there is enhancement in this area, developed by official Avi Networks devops page, in terms of using DNS-01 challenge also. I tried on-prem option using Bind DNS as server which works very well.     Steps are pretty much similar to HTTP-01 option, which can be summarised as following:      - Create L7 virtual service with publicly available FQDN - certificates resolved can be in both options RSA or ECDSA, as configured during creation;        - Do...
Read more

VMware SD WAN - multiple locations - LAN IP address space overlapping with NAT

Image
     Different scenarios are possible in terms of routing, NAT-ing and IP overlapping setups using VMware Velocloud SD WAN technology in Customer environments.      Recently I had an PoC with my Customer for the on-prem option with this VMware solution, where different use cases were interesting to show and demonstrate - one of them is something I would like to share and it relates to possibility of LAN-side NAT on Edge (branch) locations, with purpose to have IP overlapped on these setups. Next picture is showing typical Hub&Spoke setup where it can be possible to make this type of configuration: Picture 1. VMware SD WAN lab on-prem environment     Basically thing which needs to be accomplished is appropriate NAT solution for LANs on every branch Edge which are and needs to be the same (192.168.1.0/24 in this example) - as it is shown on Picture 1.      Honestly speaking, NAT is not one of so powerful things insi...
Read more

NSX-T Layer 2 bridging - scenarios & use cases

Image
     Layer 2 bridging is very useful feature of NSX-T, which provides connection to a VLAN backed port group or a device, such as a gateway, that resides outside of NSX-T DC environment. Useful scenarios, among others, are: Workload migration from VLAN-backed to NSX overlay segment, NSX-V to NSX-T migration in Customer environments, Security features leverage using NSX-T Gateway firewall etc. L2 bridging feature requires usage of Edge clusters and Edge Bridge profiles.      Deployments should consider different options, with most important scenarios, for implementation below (this covers Edge VM deployment option as typical use case): Edge VM on VSS portgroup  --> promiscuous and forged transmit on portgroup REQUIRED / ESXi host (with Edge VM) command " esxcli system settings advanced set -o /Net/ReversePathFwdCheckPromisc -i 1 " REQUIRED / Active and Standby Edge VMs should be on different hosts, Edge VM on VDS 6.6 (or later) portgroup  -->...
Read more