Showing results for 
Show  only  | Search instead for 
Did you mean: 
Former Member
Not applicable
Report Inappropriate Content
Message 1 of 7

Using client certficates for authentication on wg


I already have a kerberos authentication / WebGateway ruleset working as per this excellent guide.

Jon ScholtenHow To: Setup Kerberos Authentication on Web Gateway 7.x

I now want to extend the authentictaion to handle browser/device which offer a client certificate (actually Safari on IPads).

I am looking for a bit of advice on what to do.

I understand that I can create a new authentication method under settings which is of type "SSL client Certificate".

What are the next steps ? I see candidate rules sets in the library but not sure which ones are appropriate

any guidance gratefully recieved



6 Replies
Former Member
Not applicable
Report Inappropriate Content
Message 2 of 7

Re: Using client certficates for authentication on wg

Hi Marduk!

I'm glad you liked my Kerberos guide! I hope I can help with x509 stuff too!

This is something that has been brought up here:

To achieve this we need to modify the default "Authentication Server" rules. Details on the "Authentication Server" can be found here:

Effectivley, all that is done with the "authentication server" rules is; you redirect the user to a URL on the MWG; the MWG then authenticates them (using whatever method (NTLM kerberos x509) and then MWG stores a "session" which ties the user's IP to their username for X ammount of time.

In the thread raised by jps (, he setup his iPads with a separate proxy pac file. He was then able to create a separate proxy port for those users, and create separate authentication rules to apply to them.

I would suggest using this method (distiguishing the users based on proxy port) in order to decide if you want to perform certificate authentication or not.

Attached is a ruleset you can use to TEST this out.

It consists of two main ruleset components.


1. "Check for valid authentication session" - This is where MWG looks in its internal session database. If it finds a valid entry for your IP address, then it populates all of your authentication information accordingly. If it does not find a valid session for your IP address, then it will redirect you to the URL configured in the "Authentication Server (port 444)" settings.

2. "Authentication Server" - This is where the MWG actually authenticates you after you have been redirected according to "Authentication Server (port 444)". Read over "" for more details on this. This ruleset can be moved out on its own at the top of the ruleset if needed.

Some of the subcomponents are:

1. You need to create an additional proxy port, just for the Authentication Server communication (in the example I used port 444). This is done on each MWG under Configuration > Proxies, then add a new listener and set ports treated as SSL to '*'.


2. Redirect URL - Leave alone to start. This will need to be configured correctly such that the client machine does not complain. The default is set to:

https://$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.ip"/>$:444


3. Enrollment page or MWG generated certificates - How will the clients be getting their certificates? If they fail to present a certificate how do you want MWG to handle it? In the rules you can configure a fail over page, where MWG will redirect them to your enrollment web page to get a certificate.


4. Certificate for authentication server - The communication with MWG must be secure. As such you will need a web server certificate configured in the rules this is done under Default Certificate Based Authentication > Authentication Server > SSL Handling > Accept Incoming HTTPS Connections


5. Certificate for verifying certs presented by the clients - In order for x509 auth to work, you need a CA that is signing all of the client certificates. The public certificate can be imported into the MWG, so the MWG can verify the authority on the client cert.


I hope to add this to my authentication guide, but this should help you and others get started.



Former Member
Not applicable
Report Inappropriate Content
Message 3 of 7

Re: Using client certficates for authentication on wg

One flaw in this ruleset.

I forgot to include group lookups. I will have to add this tomorrow, this can be done by adding a group lookup using LDAP.



Re: Using client certficates for authentication on wg

This gave me some serious headaches, but I seem to have gotten it working. I'll have to post some of my findings when I finish testing. But, I need to confirm: it seems to be working without opening a separate port. Rule traces and packet traces confirms this. I've also disabled the extra port, and it's authenticating. The redirection happens, but the port on the URL isn't picked up by the browser, which is what the browser is supposed to send to the proxy, and I don't see how the browser is supposed to be told to redirect to a different proxy. Yet, I can see the certificate exchange on the main proxy port, though Wireshark won't interpret it as such. I have to read the certificate DN through the binary dump. So, does this make sense, or am I looking in the wrong places?

Re: Using client certficates for authentication on wg

I'm trying to get this working now. Any tips you can provide from your experience?

Re: Using client certficates for authentication on wg

Turns out Mozilla's odd behavior is in part a fluke. The proxy should not attempt to proxy itself, meaning that the browser's proxy settings should include the proxy in the proxy exception list. The fact that Mozilla was able to work without the proxy exception settings being correct is just strange, and Wireshark couldn't decode the SSL either because it was port 80 or because it thought is was proxy traffic.

Re: Using client certficates for authentication on wg -- FQDN Redirection

I was able to set the redirection to the authentication server to use the FQDN of the proxy, with this:

https://$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.system.hostname"/>$

This was necessary because VMware's AirWatch browser can only set the browser's proxy exception list to FQDN's; or at least, it cannot take IP addresses (which is lame).


You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community