Who rated this post

@RemieDK 

Oh....i've had my fun with TAC on this one 🙂

Here is everything I have learned to date:

1.  Deploying IOC feeds with authentication via SmartConsole is NOT supported unless your management server is on R81.20. 
1. From what I am told via TAC, R&D is not backporting this despite knowing this is an issue and instead telling folks to upgrade management to R81.20 instead  (i.e. since original release).
1. Which….is really annoying since authentication has been listed as an option in R81 and up but has never worked until R81.20.
1. Just remove it as an option in smartconsole if backporting is not going to occur…..or at least a nice warning message until it is 😉
2. After upgrading our management server to R81.20 this weekend (Take 10), I found some more issues :
1. It looks like the 'test connectivity" option now is only allowed on R81.20 gateways 😞  
1. It displays a warning that I have not attempted on my R81.10 gateway
2. Test connectivity on non-authenticated feeds in R81.10 management worked fine so it seems like this is now removed overall if you upgrade management to R81.20.
2. While still able to deploy with a threat policy install, I can confirm that the auth issue is gone......BUT.....i now have a format issue  😠
1. (New TAC case opened now)  - my format is very simple IP list type like the first IP feed example in SK132193)
3. During our initial testing, we also found a bug that wasn't documented regarding the username used for any authentication
1. Only lowercase usernames are allowed today
1. Note:  R&D did write up a port fix for this for R81.10 Take 95 and I was told it will be wrapped into a future JHF
1. That being said, we just changed our username and moved on.....but just a note for others whom might get the SAME auth error message in smartconsole......it could be your username used  😉
4. Checkpoint is VERY 'by the book' on SSL certificates.   Just cause it can chain up in a browser or other systems doesn't mean it going to work here.
1. Had a lot of back and forth with PKI team with internal certs missing some attributes.
2. And no complains here on on the checkpoint end…..just lessons learned on internal cert requirements.....but would be soooooooo great if there was a CLI or Smartconsole option to bypass cert check (See notes at end of thread)

So....yeah.....still working with TAC now so we can avoid the CLI based deployments.   

Somethings that would have made CLI based deployment 'manageable' IMO:

NOTE:  References here are within the "$FWDIR/conf/ioc_feeder.conf"

1. Allow for deployment using an "obfuscated_password" option
1. Since it’s the same feed being deployed over and over to gateways, it would be nice to add to one site manually (i.e using your 'ioc_feeds add" structure and then manually entering the password afterwards)…..then use the hash here to deploy to the other 100+ FWs. 
1. This option would have been workable for us since you could just run it from a repository script in smartconsole.
2. Add a "no_ssl_validation" option in the CLI add/modify.   
1. This field is mentioned as a workaround to bypass certificate validation (i.e. that internal CA use case issue)
2. While you can VI edit the .conf file post deployment, it is overwritten if you do any 'modify' or remove/add to the feed 😞
1. Not to mention a bigger pain to deploy if you have to edit this every time……
3. This option would have saved me weeks on the internal CA issue I was facing.  
4. The option is there……just add it please on a future request 😉