cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7084
Views
42
Helpful
9
Replies

Where and What to get for IKE certificates

NLO56933
Level 1
Level 1

Good morning, We've been configuring a Client to Site VPN on a R340 and deciding to go for certificate auth on IKEV2. Totally new to this and would like to ask some question

.

We have 1 website company with one domain.

Looking at some CA authority (DigiCert,Sectigo, GoDaddy)

 

which certificate should we purchase?

Is it a TLS/SSL Certificate with a (Domain Validation) DV SLL?

Also I believe once we purchase and get signed certificate , certifcate will be installed on the router RV340 after being signed. But how about the VPN CLient (workstation) do we load the same certificate or do we have to purchase certificates also for the Clients.

If we have to purchase which certificate for the Clients.

Any help would be appreciated Thank you

1 Accepted Solution

Accepted Solutions

nagrajk1969
Spotlight
Spotlight

So please find attached the sample configs that need to be applied/configured on the RV34X vpn-server (also the same on RV260/160 routers too)

 

 

View solution in original post

9 Replies 9

Hi,

For client authentication, you need to have one cert per client. You need
to have CA server to generate a certificate per client. You can't buy
certificate per client from public CA. This is not practical.

You can use internal CA server with SCEP proxy feature to generate
certificates for clients and use them for authentication.

**** please remember to rate useful posts

Thanks for the answer, but I have 2 questions.

 

1.  We are a small organization we need only about at most less than 10 persons that need the VPN, is it still not practical, do we still need to do an internal CA server

 

2. You answer makes me realize we might not be deciding correctly.  In our case would a PSK be just as safe as a certificate?  In my mind the great advantage of cert is that we can expire/invalidate certifcates thru the CA, but if there are just 10 of us and just 1 site I could easily cancel or change the PSK.  What do you think.   Again Thanks for the answer

Mike.Cifelli
VIP Alumni
VIP Alumni

Adding additional information:
But how about the VPN CLient (workstation) do we load the same certificate or do we have to purchase certificates also for the Clients.

-Each client will enroll for it's own personal identity cert that can/will be used during the onboarding process during negotiation.  The clients will require the certificate chain (root/intermediate certs) to be properly imported into its trust stores so that the identity cert of the external client is trusted.  This will help better understand using certs, and the overall idea of how things work.  Take a peek at this: How To Implement Digital Certificates in ISE - Cisco Community 

nagrajk1969
Spotlight
Spotlight

Hi

 

1. Firstly, what @Mohammed al Baqari said is absolutely correct. It would make more sense to have your own "Internal" PKI-Certificate-Infrastructure in place for VPN-tunneling requirements

a) Managing multiple clients with commercial-bought Certs would be "cumbersome" and quite "expensive"

b) Each vpn-client (workstation) will require a separate certificate (machine certificate and not user-certificate) that needs to be installed in that workstation's machine-cert-store

Note: Both Windows and MacOS have separate Certificate Stores, one for Local-Machine-Certs (used for IPsec-VPN) and another for general purpose User-Certificate-Store (used by Browser/sslvpn clients etc). So you need to install certs for ipsec in the machine-store only

 

2. How many ikev2 ipsec clients are you planning to connect to the C2S-IKEv2-VPN-Server on RV340?

- this will decide for you the above point 1b, whether to buy from commercial cert sites or have your own internal CA-server

 

3. What type of IKEv2-VPN-Clients (workstations) will you be using - all Windows-IKEv2-Native-clients (on windows-laptops/PCs) or will there be MacOS/iOS-clients, Greenbow-IKEv2-VPN-Clients too? ???

- iam asking about client types, becos there are some specific  implementation quirks built-into the windows/macos/ios clients that require certain settings in the certificate that you will use for the vpn-server-gateway (the RV340)

 

4. Please note, say if your organization domain name is "example.com", so:

 

a) if your public dns-name/FQDN-fully-qualified-domain-name of your RV340 is say "rv340gw.example.com", then wherever you decide to get the device certificate for RV340/vpn-server (either commercial or internal-CA), ensure that in the CSR, you should set  the Common-Name/CN=rv340gw.example.com and you should also set the subject-Alt-name to rv340gw.example.com

 

b) Becos in windows-ikev2-client configuration using Certs/EAP,

 

- you should ensure to install the RootCA-certificate that signed the VPN-server certificate and 

 

- you should mention the server-address as "rv340gw.example.com" (which will be resolved by the dns-server used by the windows-client to the public-ipaddress of the wan1/wan2 interface of RV340)

 

- and the point-4a becomes important becos, during the IKE-negotiation, when the vpn-server sends its certificate to the windows-client, the client will try to match the server-address (the dns-name/fqdn) in either the CN/common-name field of the server-certificate or in the subject-alt-name field of the server-certificate....one of them should match, else the ike-negotiation is stopped by the client

 

- A similar process happens on MacOS/ioS ikev2-clients using Certs/EAP

 

Note: This is a quirk/behavior on the clients not on RV340 (or any other IKEv2-vpn-server), these clients are implemented like this

 

 

Thanks for the answer nagrajk I am still trying to understand a lot of what you are saying.  Bute let me answer some

 

- How many ikev2 ipsec clients are you planning to connect to the C2S-IKEv2-VPN-Server on RV340?

Clients will be less than 10

 

- What type of IKEv2-VPN-Clients (workstations) will you be using - all Windows-IKEv2-Native-clients (on windows-laptops/PCs) or will there be MacOS/iOS-clients, Greenbow-IKEv2-VPN-Clients too? ???

It will be all Windows - Laptops/PC. 

Still deciding on VPN Client , but it seems Greenbow is the one we know how to make it work

 

nagrajk1969
Spotlight
Spotlight

Hi

 

>>>We are a small organization we need only about at most less than 10 persons that need the VPN, is it still not practical, do we still >>>need to do an internal CA server

1. Well it depends. If you dont have any issues with costs/budget/expenses for buying separate certificates for VPN-server and 10 vpn-clients, then you could go ahead and procure the certificates from a commercial-CA, and install these certs in RV340 and in the 10 clients

 

2. BUT either-way (either procure from a commercial CA or create your own certificates by installing your own Internal-CA on a internal-machine) you MUST remember 1 thing:

- For the certificate on VPN-Server (RV34X), ensure that

a) the "Common Name/CN" fieild value is set to a FQDN/DNS-name of the vpn-server such as your registered dns domain-name (say for assumption its "example.com") such as vpnservergw.example.com or rv34x.example.com OR if you are using dyns-dns server, then it could be rv34x.dyndns.org or vpnservergw.dyndns.org

b) the same FQDN in the CN/CommonName should also be set as "subject-Alt-Name" in the certificate:

DNS:rv34x.example.com 

or

DNS:vpnservergw.example.com

or

DNS:rv34x.dyndns.org  

 

- For the 10 clients-certificates, ensure that each of the client-certificates has a individual/separate value for subject-alt-name field in the client-certificate in the form of email-id, such as below (assuming that you are using your registered domain-name "example.com"

 

for client1 cert, the subject-alt-name should be set as for example: client1@example.com

for client2 cert, the subject-alt-name should be set as for example: client2@example.com

for client3 cert, the subject-alt-name should be set as for example: client3@example.com

....and so on

 

>>>>You answer makes me realize we might not be deciding correctly.  In our case would a PSK be just as safe as a certificate?  In my >>>mind the great advantage of cert is that we can expire/invalidate certifcates thru the CA, but if there are just 10 of us and just 1 site I >>>could easily cancel or change the PSK.  What do you think.

 

Ok the info you should be aware of with reference to IKEv2-VPN-servers for IKEv2-VPN-Clients is:

 

There could be different methods that could be confgured/set, but by standard basic configurations, there are 3 methods to confgure/use the IKEv2-vpn-server for vpn-clients 

 

1. The IKEv2 vpn server using PSK for authentication

- Here the psk-authentication is to mutually authenticate the vpn-server and the vpn-clients as ipsec peers, and therefore there is NO username/password involved in this tunnel establishment

- Only Greenbow and MacOS/iOS IKEv2 clients support this method

- The native windows-IKev2 client does not support PSK-based ikev2-auth (it only supports Certificates-Only and EAP-Mschapv2 with username/passwd, and also EAP-TLS)

 

2. IKEv2 VPN Server using Certificates for ike-authentication

a) Here too, Only Certficates are used on both vpn-server and clients for Mutual-Authentication of the IPsec peers (server and client)

 - and there is no use of username/password for extended-authentication

- The native Windows-IKEv2 client supports this (you have to select "machine certificates" radio button in the client config sections)

- The Greenbow and MacOS/iOS clients also supports this

- In this case both server and clients need to have their own separate certificates  that will be used for doing mutual IKEv2-authentication of the peers

 

b) So how does each of the client types get the ikev2-authentication done using certs?

 

On Windows-Native IKEv2 Client

----------------------------

- As for the native windows-ikev2-client, there is no config to set/select the subject-alt-name value in the client-cert.

- So windows first server will send its server-cert which will be verified/authenticated on the windows-client using the Root-CA cert of the server cert that was imported into client earlier. Next the windows client itself will simply send the subject-name field (known as DN field or simply ASN1DN) of its client-cert to the vpn-server which will be verified and validated on the vpn-server using the rootCA-cert that had signed the client-cert

 

 On Greenbow-client

-------------------

- On this client, it would be preferably using the U-FQDN value in its client-certificate as Local-ID

- and so first it will authenticate the server;s certificate using the Root-CA cert that signed the server-cert

- and then next, the GB client will send its certificate to the server, where depending on the configs, the vpn-server will use either the subject-field of the client-cert OR checks the subject-altname for the U-FQDN value (clientX@example.com) in the client-cert and matches to the value of the Remote-Identifier that has been configured on the vpn-server

 

On MacOS client

---------------

- Here we will be configuring the UFQDN value in the subject-alt-name field of the client-cert installed on this macOS

 - This value will be configured as Local-ID in the macOS client

- The process of vpn-server cert getting authenticated on mac-client using the RootCA cert, and the client getting authenticated based on the value of the Remote-ID field set on server. The required/relevant ID is checked in the subject-alt-name field of the client-cert

 

3. IKEv2 VPN Server using EAP methods (such as EAP-Mschapv2 with username/passwd)

- Here in this case, the vpn-server will be authenticated using the server-cert sent to client (verified on client using the RootCA-cert that you had imported on the client in the beginning itself)

- And on the client, there is NO certificate installed. 

- And the client will authenticate itself using EAP (in this case it will be EAP-Mschapv2 using the username-passwd configured on the clients)

 

 

 

 

nagrajk1969
Spotlight
Spotlight

So please find attached the sample configs that need to be applied/configured on the RV34X vpn-server (also the same on RV260/160 routers too)

 

 

Nagrajk , 

 

Thank you,  You are so very helpful,  One last question  I am trying to purchase the certs but there are so many selections that I cant tell which is which.

 

If you can bear with me look at this website

which one should I buy?

 

 

I believe for server we need an Basic OV TLS/SSL Certificates,

 

https://www.digicert.com/tls-ssl/business-tls-ssl-certificates

 

but for the clients what do we get Client do we get the same Basic OV Certificate?

 

nagrajk1969
Spotlight
Spotlight

Hi

 

>>>I believe for server we need an Basic OV TLS/SSL Certificates,

Ok. But try to ensure the below settings in the signed cert

a) Ensure that the CN/Common Name is set to the fqdn/dns-name of the vpn-server (such as rv34x.cisconet.local) and also the subjectAltName is set to the same fqdn/dnsname

 

b)  request (or select it yourselves if its avaiable)  the following additional settings/parameters(extended-Key-Usage - EKU)  in the server-cert

 


Parameter OID 1.3.6.1.5.5.7.3.5 is used for the IPSec End System

and/or

IP Security IKE Intermediate" EKU with OID 1.3.6.1.5.5.8.2.2

 

 

>>>>but for the clients what do we get Client do we get the same Basic OV Certificate?

- The same as servergw, but here too:

 

a) ensure that common-name/CN is set to a clientname

AND

- ensure that a subjectAltName is set for each of the client-certs separately  in U-FQDN format (such as client1@example.com)

- and also ensure to request for setting the above shown  OIDs (in EKU) in the client-certs too,