A brief question on authenticating Anyconnect via certificates. I've looked through a bunch of deployment guides and blogs but can't seem to get this straight in my head. If anyone could clarify the issue for me, or point me in the direction of an appropriate install guide I'd be very grateful.
I'm trying to deploy the Anyconnect client on a number of mobile devices, the ultimate goal being to authenticate the mobile clients via certificate and AAA; i.e. only a client which presents a trusted certificate and a suitable username and password combination will be authenticated. The certificates here will be acquired from a 3rd party CA, there is no internal CA with which the devices can enroll.
I understand the process of generating a CSR from the ASA, installing the returned identity certificate and then also installing the CA certificate from the authority, that makes sense to me on the server side.
What I don't understand is how this works from the client side. As I understand from the Anyconnect deployment guide, if it tries to connect to the ASA then it will see the certificate the ASA is trying to present. If this isn't already trusted, it'll throw up a dialog and prompt the user to trust and install the certificate. In future connection attempts, this won't happen as the certificate will have been installed and trusted. This behaviour could also be bypassed by installing the certificate in the mobile device Anyconnect client prior to the first connection attempt.
Basically, this identifies the server to the client, and the client will trust the server if the user wishes. This isn't the behaviour that I'm interested in creating however. I want a client to be able to connect to the VPN only if it has a trusted certificate already installed, I don't want the ASA to offer it out, but rather identify and validate the client as a trusted device based on the presence of a certificate. I'm happy for the clients to all have the same certificate (it's the only option here really as there's no internal CA).
Would someone be able to clarify the situation to me?
Implementing Anyconnect with certificate authentication could be done in 2 way:
- Generate the user certificate, import it into mobile device, configure anyconnect app to use this certificate for authentication
- Create a policy to connect a user to the VPN, Anyconnect will ask to generate his user certificate and reconnect to the VPN using this certificate.
The 1st method is manual.
The 2nd is automatic and need that CA server has SCEP capability. This is the method used from ASA when a user is connecting to VPN and need to enroll the certificate.
PS: Please don't forget to rate and mark as correct answer if this solved your issue.
Thanks for your reply.
So we can install a certificate manually on the client that the ASA will trust, assign it to the Anyconnect app, set the ASA to authenticate the VPN via certificate and this will work correctly.
If I understand you correctly, if the certificate wasn't installed on a client and the ASA was expecting certificate authentication, then the VPN wouldn't successfully connect at all. It won't prompt to install a certificate based on the public key of the certificate installed on the ASA as I outlined above. The only way a certificate could be installed on the fly when connecting would be is if there was an auto enrollment policy in place and it requested a certificate on the fly from the CA.
Am I understanding correctly?
Ok maybe I've explained correctly.
For manual installation, everything clear.
In case a client is connecting through VPN that requires certificate but was not enrolled before connection: I assume that you don't want anybody connecting without a certificate
- You have to create at least 2 policies
- Users connect through VPN using user/password
- ASA will accept VPN connection. This VPN has limited access. While the user is connected, ASA/Anyconnect will generate the user certificate by using SCEP protocol between your ASA and your CA server.
- User certificate is then automatically installed, same for the new VPN connection profile that will require certificate to mount the connection.
Then to answer your question, Yes ASA will do automatic enrollment of user certificate (you need to configure SCEP on your CA server as well).
Is it more clear?
I have done some labs on this topic for some customers. If I found my document related to that topic, I will drop it.
PS: don't forget to rate and mark as correct answer
Okay, yes, that process makes perfect sense, thanks.
Maybe a slightly different question then; is it possible to do this without a CA environment in your control? I.e. Install a server certificate from a 3rd party CA e.g. Verizon on the ASA, and install another separate user certificate from the same 3rd party CA on the clients (same certificate on each client, manually installed).
I suspect this isn't possible and this is the whole source of my confusion.
When you say 3rd party, you can do if this 3rd party is offering SCEP enrollment.
You need to verify with your certificate provider.
However you need to have 1 third party that send certificate on ASA and user.
If SCEP is not supported, you need to enroll user certificates manually and deploy it on your clients.
PS: please don't forget to rate and mark as correct answer
Okay, so in short, clients need to enroll to get a certificate, either with a 3rd party or an internal CA. They mint a certificate on the fly when they connect to the VPN for the first time.
There's no way of using the same certificate from a single CSR to a 3rd party on every single device to connect, there needs to be some kind of enrollment infrastructure in place.
My initial thoughts were that I'd have:
- The ASA with one certificate
- The client with a separate certificate
Both generated via a third party CA as there is no internal CA where I am working.
The same client certificate would be installed on each device that needs to connect as to generate a certificate per client is not scaleable (or affordable) with a 3rd party CA. This is how the ASA would identify the device.
That was my initial design thought, and what I was trying to work out whether was possible.
From what you say however, the best way of doing this design wise would be to go through the process of setting up the internal CA infrastructure to handle enrollment. This is also how all the design guides refer to deployment.
Yes better solution with internal CA.