Automatic HTTPS Certificates for Web Applications/Services with Custom Domain
Secure Access Cloud supports allows delivering Zero Trust Secure Access to Web Applications and Services hosted anywhere (from on-premises datacenters to IaaS/PaaS) in a completely transparent way by using the customers' DNS Domains.
This article explains the mechanism for automatic allocation of HTTPS certificates for such Web Applications and Services using LetsEncrypt CA.
LetsEncrypt Certificate Authority allows creating of universally-recognized frequently-refreshed domain validated HTTPS Certificates. Secure Access Cloud allows using its certificates management automation cycle for custom domains in order to streamline provisioning of access to Web Applications and Services.
The process of automatic generation of certificate for a custom domain is initiated upon defining a Web Application with custom domain in Secure Access Cloud Web UI and updating the DNS records to CNAME pointing at Secure Access Cloud dynamically-generated aliases.
The stages of the process are described in the below diagram:
1 - The administrator defines a Web Application with custom domain in Secure Access Cloud Admin UI and updates the DNS record in their domain (app.mycompany.com) with CNAME pointing at Secure Access Cloud DNS Zone (xxx.mycompany.luminatesec.com)
2 - Secure Access Cloud requests an HTTPS certificate for app.mycompany.com from LetsEncrypt Certificate Authority.
3 - The Certificate Authority resolves the domain app.mycompany.com, going to the DNS Zone for mycompany.com.
Please note that at this point, the DNS response should contain the CNAME record pointing at the xxx.mycompany.luminatesec.com. If the original A record for app.mycompany.com had a long TTL, at this point, it is not guaranteed that the certificate authority will retrieve the CNAME record, rather than cached response. It might be, therefore, recommended to change the TTL of an A record to a short one, prior to initiating the whole process.
4 - The response the Certificate Authority should receive, as a result of a CNAME record, is a dynamically-generated sub-domain representing the application, xxx.mycompany.luminatesec.com
5 - The Certificate Authority tries to resolve xxx.mycompany.luminatesec.com
6 - An IP Address leading to the relevant Secure Access Cloud Point of Delivery (PoD) is returned
7 - The Certificate Authority requests proof of ownership for the domain
8 - Proof of ownership is returned successfully by Secure Access Cloud
9 - Certificate is delivered by the Certificate Authority to the Secure Access Cloud
If a CNAME DNS record is not propagated properly due to long TTL of the previous A record, the proof of ownership request will be sent not to Secure Access Cloud, but directly to the IP Address that used to represent the server and will fail. Steps 7-9 will be repeated periodically until they succeed. Before that happens, the application will not be accessible via Secure Access Cloud.
After the above procedure is completed, any access via the internet to the custom domain representing the application (app.mycompany.com) will work according to the flow in the below diagram:
1 - The user opens a web browser and navigates to app.mycompany.com. The Web Browser sends a DNS query (that is either served by a cached DNS or reaches the authoritative DNS for mycompany.com)
2 - The client gets a response with a CNAME reference to xxx.mycompany.luminatesec.com
3 - The client sends another DNS query to resolve xxx.mycompany.luminatesec.com
4 - The client receives an IP address of the relevant Secure Access Cloud Point of Delivery (PoD)
5 - The client opens a session to Secure Access Cloud Point of Delivery (PoD
Subscribing will provide email updates when this Article is updated. Login is required.