Make sure your REGEX is tight before you go and allow something like "*domain.com" (. before domain omitted on purpose) because a fake domain will pass with the same rule, if it has the same characters in a row of "domain.com" (ex: IHackedYourdomain.com or IHackedYourdomain.comrades.ru). You want a "." before you domain name and a "$" after the "com", and keep it absolute. Also, I noticed not ALL regex will work in Checkpoint, so stick to what they explain here. Regular Expressions . And even with that knowledge, you're not out of the water. The examples given by checkpoint are good but you have 2 problems here with regex and their engine.
Another big reason this kind of exclusion doesn't work is that many companies are utilizing WILDCARD certificates, and that kind of cert does not play well certificate inspection engines, including Checkpoint's. Go to Checkpoint.com and if you observe the "Issued to:" field of their cert (in your browser) you will see "*.checkpoint.com" if you check the cert in your browser. That's a wildcard, and they can spin up "whatever_here.checkpoint.com" subdomain to their heart's content. This community.checkpoint.com, on first glance, appears to be that, but it's not, that's why the rules we're writing, aren't working. That's problem 1.
Then you go look into the certificate and see that in the "Subject" field, the CN actually has an asterisk "*" in it! Checkpoint's CN says "*.checkpoint.com". How can you write that in your regex? That's problem 2. Check this for the note on it How to work with wildcard certificates in HTTPS Inspection and Application Control
Finally, combine the 2 issues, and add a twist. What you typed into the browser (the FQDN) does not match the certificate that is actually in use for the site. You would normally see an error about "certificate name mismatch" in the browser, and then you click the hyperlink to "Continue to this Website (not recommended)" or "SEC_ERROR_BAD_CERT_DOMAIN" to bypass it manually. An unattended device doesn't have fingers & mouse, it can't click past this kind of error, you need to write a rule around that kind of issue. But normally, we're trained to see that error to know we have certificate errors like a hacker intercepting with a fake cert, you signing into a self-signed web site, or your web server certificate that doesn't match the FQDN (certificate name mismatch). Today, all kinds of advanced certs like SANS (multi-domain) certs mess that all up and you get no error when FQDN doesn't match the CN. Now you type in https://community.checkpoint.com in the browser, but if you look at the issues I just outlined, you'd see that a site like this will have a different Common Name than what you typed in the browser! You're trained to think that certificate is from "checkpoint.com" because you received no error. Inspect the certificate, you'll see that the certificate "Issued To" field says vanity4.jiveon.com (or whatever) but that's not what you typed in the browser! When you look into the certificate's Subject field, you'll see something like THIS:
CN = vanity4.jiveon.com
OU = Hosting
O = Jive Software
L = Palo Alto
S = California
C = US
vanity4.jiveon.com does not equal community.checkpoint.com in my brain, nor the Checkpoint engines. This is the last major problem. Aside from the horror of thinking Checkpoint got hacked and their domain hijacked, this is also a common issue. So you'd have to write your sites to combat these top issues, cert mismatch, Alternate-Subjects, Domain forwarding,etc in certs. In any proxy I have, this is a certificate mismatch. You have to write in vanity4.jiveon.com in this particular case.
