Certificates Managed by Check Point
WAF as a Service deployment does not require manual setup, as it is automatically configured. However, for each domain in each of the assets, protected by a WAF SaaS in a specific region, you must perform the following 2 steps (possibly 3) and only afterwards will your traffic be secure.
Adding domains to an existing asset, or adding the WAF SaaS profile to protect an existing asset that wasn't protected by it until now, will also require completing the same steps before the newly added domains are protected.
If a domain needs to be edited, add the correct domain to the asset, complete the steps, and delete the incorrect domain.
Step 1: Prove ownership for each of your domains in each of your assets to be issued certificates
Browse to Policy -> Profiles and select the CloudGuard WAF SaaS profile that was automatically created during the Asset creation wizard. You will see the domains that are pending action.
Upon clicking on a domain you will see the first instruction - proving ownership of that domain. You will need to perform this action for each of your domains. For example, if you are protecting both www.myapp.com and api.myapp.com, you will need to prove ownership of each domain separately.
In your DNS configuration, where the current domain is configured, add a CNAME record with the name and value you can copy and paste from the WAF management.
Adding this DNS record allows our certificate management system to approve issuing certificates for your domain.
Step 2: Connect your domain to WAF SaaS
Before performing this stage, disable any existing AWS CloudFront configuration for your website's address if you have any.
Once ownership of the domain is proved, a CNAME record value will be issued. This may take up to 30 minutes.
Once issued, change the existing DNS CNAME record for the domain you wish to protect and change its value to the copied string. Once the DNS records worldwide are updated, traffic will now pass through WAF SaaS and then be routed to your internal web server.
Step 3: Make sure your internal web server is accessible from WAF SaaS PoP IP addresses
During this step you will add IP addresses to the access list allowed by your internal web server, and you may also be required to remove IP addresses that are no longer needed.
Since DNS propagation of new configuration can take up to 72 hours, we recommend you will only add IP addresses as needed, but not remove any access from the web server until 72 hours have passed and you have tested your connectivity to the web site through WAF SaaS.
In each asset protected by WAF SaaS you configured the upstream URL for the Reverse Proxy function of WAF SaaS. Traffic will reach WAF SaaS through the web site's domain, and will be sent, after inspection, to the internal address.
You must configure that address to allow access from the IP addresses provided by the deployment form in CloudGuard WAF UI, and only from those addresses.
i.e. if the domain was publicly exposed until now, you must reduce accessibility and allow traffic from only those IP addresses. And if the domain was only accessible from a previously configured Reverse Proxy, you must add the IP addresses of WAF SaaS to the access list and consider removing irrelevant IP addresses of the previous Reverse Proxy.
Step 4: Test access to your site
After completing all previous steps, make sure access to your site exists.
Please note that changing DNS records can take up to 72 hours to propagate worldwide, although it typically takes a few hours.
Make sure you have not left a publicly exposed domain in your previous environment!
Last updated
Was this helpful?