Deploying Cisco AnyConnect with client certificate

[jelockwood]

We are currently evaluating Casper Suite and as part of its planned use we would like to be able to deploy Cisco AnyConnect with unique client (i.e. client device not user) certificates rather than using a pre-shared-key or the same certificate for all devices.

To do this we will need some way to automate generating the client certificate and pushing it along with the Cisco AnyConnect software and profile to the client device and telling it to use that client certificate.

I am presuming the client certificate generated and used by Casper itself for the client device cannot be used for this purpose as well.

As background we use Open LDAP, we are planning to use EJBCA (Enterprise Java Beans Certificate Authority) as an external CA to Casper, and as should be obvious the Cisco AnyConnect client instead of the Apple built-in client.

Related to the above would be a desire to be able to revoke an individual client device certificate and for this to be recognised by EBJCA and the Cisco ASA server.

I would expect some Casper users have had similar requirements i.e. AnyConnect with client certificates previously and therefore might be able to share some ideas.

Thanks.

[rcorbin]

@jelcokwood did you come up with a way to implement this ? Starting to look at AnyConnect and deployment options here. You say you were evaluating Casper Suite. Did you go with it ?

[jelockwood]

The power that be ended up using Profile Manager (and other tools) however the same issues applied to using Profile Manager and wanting to deploy Cisco AnyConnect.

We eventually discovered that we could create a configuration for AnyConnect that would look for a specific type of certificate in a specific keychain. We then wanted to deploy individual client certificates which would logically be done via SCEP as configured via Profile Manager. Unfortunately Apple's own SCEP server only seems to work for use with Profile Manager enrolments and cannot be used as a general purpose SCEP and in any case Apple do not provide adequate tools for managing certificates and revocation of them. We therefore has planned to use EJBCA (Enterprise Java Beans CA) but discovered a bug between Mac clients and EJBCA after we told Profile Manager to push those SCEP settings.

EJBCA currently expects a message parameter along with a command parameter for the GetCACaps command even though that command does not need a message parameter. Macs therefore do not send a message parameter (an empty one would have worked). EJBCA therefore rejects the request. I reported this to the EJBCA team and a fix for this is supposed to be in the next release.

There is unfortunately a dearth of PKI tools like EJBCA, Microsoft have some as part of Active Directory which supposedly work with Macs but that presumes you use Active Directory. This is a gap that Apple ideally would fill in Server.app.

[rcorbin]

Thanks for the update @jelockwood Good information….

[thansen]

I was looking for help on a login.keychain vs system.keychain issue and found this. We are using Certs much like what you described with AnyConnect. Here's the high-level for anyone else that stumbles upon this:
Mac's are NOT AD Joined. Users are all local.
AD Cert Svc for Private PKI.
JSS/SCEP configured with an External PKI, pointed to ADCS
Config Profile drops Certs for Private-PKI Trust
Config Profile uses SCEP to get Certs for the User-Machines. Each Cert is specific to a User on that Machine.
AnyConnect is set to look for userID, and DNS Name. If the cert doesn't match the VPN login values - Fail. If the cert isn't valid according to the Private-PKI (ADCS) - Fail.

It's working well, with one exception, our AnyConnect Client want to see the Cert in Login.Keychain, and it's deposited in System.Keychain. We have to educate users to manually move it, and I want to find a solution.

[jelockwood]

@thansen I don't know if this will help but something to consider is that for Profile Manager at least if you push a certificate in a profile via device group it will be added to the System keychain as it should, and if you push it via a user group it will end up in the users login keychain.