Forum Discussion
jase_40648
Nimbostratus
NimbostratusCustom Certificate Checks
Hello. We are trying to do some custom checks for a protected configuration. Specifically, we want to verify that not only did the client give a valid certificate, but that their email address in the certificate is appropriate for the user.
For this protected configuration, all users should have a certificate email in the form of username@COMPANY.COM.
I've tried things such as
session.ssl.cert.email == session.user.username+"@COMPANY.COM"
as well as various combinations of surrounding the variables with '%'. I've dumped the session variables and see that they do exist. And I've successfully checked for a specific user with
session.user.username == "SPECIFIC_USER"
and I've also successfully checked for a specific email address with
session.ssl.cert.email == SPECIFIC_USER@COMPANY.COM"
so I know that the variables exist. Is there a way to do the custom check I am trying to accomplish?
Mike_HoCirrus
Hi Jase,
One thing you can do, outside the scope of a pre-logon inspection, is to create an advanced session variable ( Users -> Session Variables -> Add New Session Variable) to pull out a substring of an existing session variable. Then use your advanced session variable in a protected configuration using a "custom check". Then apply your protected configuration to your master group or set of resources.
To my knowledge there is no comparison operator or function similar to substr() or the SQL LIKE operator that you can use in a pre-logon inspection rule. If you find one be sure to let us know!
jase_40648Thanks for the suggestion. I had already tried creating some advanced session variables, and using those too, but I was not successful. I just tried it again too, but still can't get it to work. I created the following session variables:
myemail: session.user.username+"@COMPANY.com"
certuser: REGEX(session.ssl.cert.email, "|(.*)@COMPANY.com|")
Testing both variables using the Save and Test button give proper output. Then I created a custom check for a protected configuration. Specifically, I did the custom check in the Information Leaks section. I've tried various combinations of the following:
session.ssl.cert.email == "%session.asv.myemail%"
session.ssl.cert.email == %session.asv.myemail%
session.user.username == "%session.avs.certuser%"
session.user.username == %session.avs.certuser%
But none of those work. I always get a System Warning, and don't get access to the protected resource. If I remove the custom check, I can get access.
I think either I must be doing something wrong, or this simply is not supported. Any ideas? Thanks in advance!- Mike_HoYou're close! In your protected configuration try:
session.ssl.cert.email == session.asv.myemail AND session.user.username == session.asv.certuser - jase_40648Thanks again for your response! Both checks are really redundant. I tried each one individually, but could not get either one to work. Of course, removing the custom check allows me access to the protected resources.
Is there any way to show the value of advanced session variables? They don't seem to show up in the Logon report with all of the other session variables.
Any other ideas? Thanks again! - Mike_HoI agree it is annoying that they don't show up in the logon details even when showing session variables, but then again if it's been tested then you should know what is in it.
Did you make sure the case was correct in your advanced session variables? It is not clear if the string comparison performed by the == operator is case sensitive or not. - jase_40648Thanks again for your response! Yes. I have tested the advanced session variables, that they produce the correct output, and everything is lower case, so case comparison should not be an issue.
I must be missing something very basic. Please let me know if you have any other thoughts / ideas. Thanks again!
Jason 
Stephan09_87803Hi all,
Did anyone get to the bottom of this. I am trying to do the exact same thing with a cutom check. I've created the advanced variable, and proved it works by using it as an application name just to see it on the screen. That all work proerly, but using it in a custom check in a protected configuration fails the check as Jase describes.
any solution would be grand
cheers
stephan- Mike_61719Well I do not see why you are wanting this type in the protected configuration. Let me explain.
You create a variable labeled Test and the value is firepass. You can not put in a protected configuration session.bla == Test.....
Like the above poster:
session.ssl.cert.email == "%session.asv.myemail%"
session.ssl.cert.email == %session.asv.myemail%
session.user.username == "%session.avs.certuser%"
session.user.username == %session.avs.certuser%
You can not put in a protected configuration session.ssl.cert.email =="%session.asv.myemail%" Because that will and can be any value depending on the user or how you set it up. It has to be like this.
session.asv.myemail == "SPECIFIC VALUE ALWAYS GENERATED". How does firepass know to trust a changing variable? Firepass needs to be told to always look for instance number 1. The configuration will not work.
Protected configuarions must always meet a value criteria. You can not have it going and saying "any username + any domain name". It has to be equal to check for Mike + check for domain test.
This is like me putting a check for a computer name and putting a protected cofinguration on it. Three thousand laptops and desktops have a unique name, how do you expect it to protect against an ever changing value? A protected configuration will work if you designated the computer domain name must be in the test domain. That variable will not change.