- Openvpn Does Server Generate Keys For Clients Free
- Openvpn Does Server Generate Keys For Clients For Mac
May 31, 2012 First off, I only have a basic understanding of VPNs and OVPN so apologies for my ignorance in what follows I own an Asus DSL-AC68U that has server and client capability. I’m trying to setup the client capability. I’m hoping to be able to set my router as a VPN client to my VPN service provider. Only problem is. A master Certificate Authority (CA) certificate and key which is used to sign each of the server and client certificates. OpenVPN supports bidirectional authentication based on certificates, meaning that the client must authenticate the server certificate and the server must authenticate the client certificate before mutual trust is established. Aug 22, 2016 Generating certificates for new clients. I installed OpenVPN on a Ubuntu machine, and generated certificates to allow another Linux client to connect. Verified it's working, and the client is forced to use the VPN tunnel. In the example I followed, the server certs (including the DH pem file) were moved to /etc/openvpn. Home; VPN Server. With VPN connection, you can set up multiple VPN clients to access Yeastar S-Series VoIP PBX securely. OpenVPN Certificates and Keys. Before you start to set up the OpenVPN network, you need to make the related certificates and keys for VPN server and VPN clients. OpenVPN 2.0 expands on the capabilities of OpenVPN 1.x by offering a scalable client/server mode, allowing multiple clients to connect to a single OpenVPN server process over a single TCP or UDP port. OpenVPN 2.3 includes a large number of improvements, including full IPv6 support and PolarSSL support.
Introduction
Openvpn Does Server Generate Keys For Clients Free
Static key configurations offer the simplest setup, and are ideal for point-to-point VPNs or proof-of-concept testing.
Static Key advantages
- Simple Setup
- No X509 PKI (Public Key Infrastructure) to maintain
Static Key disadvantages
- Limited scalability — one client, one server
- Lack of perfect forward secrecy — key compromise results in total disclosure of previous sessions
- Secret key must exist in plaintext form on each VPN peer
- Secret key must be exchanged using a pre-existing secure channel
Simple Example
This example demonstrates a bare-bones point-to-point OpenVPN configuration. A VPN tunnel will be created with a server endpoint of 10.8.0.1 and a client endpoint of 10.8.0.2. Encrypted communication between client and server will occur over UDP port 1194, the default OpenVPN port.
Generate a static key:
Copy the static key to both client and server, over a pre-existing secure channel.
Server configuration file
Client configuration file
Firewall configuration
Make sure that:
- UDP port 1194 is open on the server, and
- the virtual TUN interface used by OpenVPN is not blocked on either the client or server (on Linux, the TUN interface will probably be called tun0 while on Windows it will probably be called something like Local Area Connection n unless you rename it in the Network Connections control panel).
Bear in mind that 90% of all connection problems encountered by new OpenVPN users are firewall-related.
Testing the VPN
Run OpenVPN using the respective configuration files on both server and client, changing myremote.mydomain in the client configuration to the domain name or public IP address of the server.
To verify that the VPN is running, you should be able to ping 10.8.0.2 from the server and 10.8.0.1 from the client.
Expanding on the Simple Example
Use compression on the VPN link
Add the following line to both client and server configuration files:
Make the link more resistent to connection failures
Deal with:
- keeping a connection through a NAT router/firewall alive, and
- follow the DNS name of the server if it changes its IP address.
Add the following to both client and server configuration files:
Run OpenVPN as a daemon (Linux/BSD/Solaris/MacOSX only)
Run OpenVPN as a daemon and drop privileges to user/group nobody.
Add to configuration file (client and/or server):
Allow client to reach entire server subnet
Suppose the OpenVPN server is on a subnet 192.168.4.0/24. Add the following to client configuration:
Then on the server side, add a route to the server’s LAN gateway that routes 10.8.0.2 to the OpenVPN server machine (only necessary if the OpenVPN server machine is not also the gateway for the server-side LAN). Also, don’t forget to enable IP Forwarding on the OpenVPN server machine.
I did this a couple of years ago, with certificates that had a 1 year expiry date. Then my certs expired, and I’d forgotten what to do. So I figured it out again, and this time I’m writing it down.
Generate a rsa key comman. There are two ways to setup client auth in OpenVPN, a shared secret and TLS certificates. TLS certificates are the preferred way if you can manage them, as they make it possible to revoke access to devices without having to change the shared secret for every other device.
To do this you need to setup a certificate authority and sign and issue your own certificates. Most OpenVPN guides tell you how to do this using OpenSSL and it’s associated long cryptic commands. I like my method better.
XCA is a cross platform graphical key and certificate management tool. And I find it far more convenient to use than OpenSSL since I can point and click my way through what I need to get done.
You can download XCA from their official project page at: https://sourceforge.net/projects/xca/
Install it, and start it. Generate public and private key online.
Before you get started, you should change the default hashing algorithm from SHA1 to SHA256. This is set under File -> Options.
Setting up Certificate Templates
TLS certificates have various parameters that dictate what they can be used for (i.e. digital signature, web client auth, web server auth, etc.). OpenVPN requires that the certificates have certain key usage paramters set for either client or server usage. Plus there are some things we might not want to have to fill in all the time too.
Switch to the Templates tab.
And click new template.
This will pop up a window asking what preset template value to start with. Choose nothing.
On the first tab we can setup subject related parameters. OpenVPN only cares about the
commonName
parameter, but that has to be set specifically and differently for each client certificate.Set the Internal Name value to what you want to call the template. You’ll need to setup 2 templates, one or the server certificate and one for the client certificates. OpenVPN Server, and OpenVPN Client are good names, but anything will do.
The next tab is the extensions tab. It’s useful here to set a time range if you want the certificates to be valid for more than a year by default. If you check
no well-defined expiration
the certificates will remain valid effectively indefinitely.There’s a balance between security and usability in terms of setting an expatriation length. For my home network, I don’t want to keep having to issue certificates every year, and reinstalling them. But I don’t want them to last indefinitely either. Pick a number that makes sense to you, and for your application.
On the Key usage tab, you’ll want to check the following options for the server template:
And for the client template:
Once you’ve got the key usage setup, click OK to save the template.
Openvpn Does Server Generate Keys For Clients For Mac
Setting up the CA
OpenVPN uses a certificate authority to insure that all the keys are signed by a central source, and so the server can verify that the clients haven’t had their certificates revoked. So we need to set one up.
Switch to the
Certificates
tab and click the New Certificate
button.Since this is the CA, it has to be a self signed certificate, so you’ll want to leave the signing set to
Create a self signed certificate with the serial
. I’m not aware of any advantages to changing the serial number, so you can leave at it one.The signature algorithm should be SHA256, like we set the default when we started.
Since this is a CA the template should be
[default] CA
, and click Apply All
under that drop down.Moving on to the Subject tab.
Like the template file, the
Internal Name
filed is what XCA will display in the UI. I’m calling this certificate OpenVPN CA so I know what it is. The only other field that’s relevant, AFAIK, is the commonName
field, set this to something that will be unique within your CA, like OpenVPN_CA or similar.We also need to generate a key to sign the certificatel. You’ll want to have unique keys for every certificate you create. You probably shouldn’t reuse old keys, but it’s okay if you mess up the certificate creation and need to regenerate the certificate.
Click Generate a new Key and you’ll get the following dialog.
XCA will automatically populate the name of the key with the value that was set in the internal name for the certificate.
In my experience RSA keys are the most straight forward and just work, and work pretty much everywhere. Keysize should be at least 2048. OpenVPN will support 4096 bit keys for the best possible security.
Presently, the benefits for >2048 bit keys is small, and there is overhead for processing them. For someone concerned about state-level attacks against their networks, bigger keys would be desirable.
Finally set the time range or valid end date on the extensions tab to how long you want your CA’s cert to be valid.
Click OK to create the certificate and you’ll be returned to the main window.
For the client and server certificates, start by right clicking on the CA entry, and clicking new from the context menu. This will set that certificate as the CA that will sign the new certificate by default.
For the OpenVPN server, you’ll repeat the same process as you did for the CA, only you want to change the
Template for the new certificate
drop down to the template you created previously for the OpenVPN server.Also double check that the CA is signing the certificate and that the signature algorithm is SHA256 as set by default.
The rest of the process is the same as the CA certificate. Fill in the
Internal Name
and commonName
(this can be the hostname of the OpenVPN server) fields for your server certificate, set the end date, double check that the same Key Usage fields are set as shown in the template setup. And click when everything is done.Client certificates are created in an identical fashion, only using the OpenVPN Client template (or whatever you called yours) instead of the OpenVPN server template.
When you’ve created your server and client certificates you should have something that looks similar to the following image (with different internal and common names and probably more certificates).
Building the CRL
A CRL, or certificate revocation list, is a file that tells the OpenVPN server which client certificates are no longer valid. This is what’s used to disable clients that have been lost or need to be blocked from being able to access the server. And ultimately is the whole point of setting up a certificate based auth instead of just using a shared key.
To do this right-click on the CA certificate and from the CA entry in the context menu, click Generate CRL.
All of the settings can be left at the defaults here. Just click OK.
There will now be a CRL on the Revocation Lists tab, and a CRL Expiration date on the CA line in the Certificates tab.
Exporting Certificates
To use the certificates you need to export them, in a format that you can upload to your server and devices.
The OpenVPN server needs:
- The CA’s certificate
- The CA’s revocation list (CRL)
- The Server’s certificate
- The Server’s key file
Each OpenVPN client will need:
- The Client’s certificate
- The client’s certificate’s key file
For OpenVPN clients, the certificates and keyfiles should be exported as a single PCKS #12 file with a password to insure the security of the certificate between XCA and when you install it on your device.
To export a certificate or revocation list, click on the cert you want to export and click Export on the right column.
For the CA cert, Server cert, you want to use the PEM (*.crt) export format.
For the Client cert, if you’re going to iOS devices, you want to set the Export Format to PKCS #12 (*.p12). This will also require you to set a password on the exported file when you export it and it will include the key file for the client cert.
Upload the respective files to their respective devices, and being the configuration process of OpenVPN itself.
Diffie-Hellman Params (DHParam)
One final thing to export from XCA is a
dhparam
file for your server. To generate this go under the Extra
menu and select Generate DH parameter
. You’ll be prompted to set the parameter bits, set this to 2048 or higher.Many sources recommend setting your
hdparam
file to match the size of your private keys.Upload this to your server along with the certificates from the last step.
On the server, you’ll need to move the ca.crt, server.crt, server.pem, ca.pem (CRL), and dhparam files into your OpenVPN config folder (typically /etc/openvpn) and change the permissions so that they can be read by your OpenVPN user.
I’ve provided below an example annotated server config file. If you copy this for your server, make sure you change the certs to reflect the names of your certificate files.
FWIW, I’ve had persistant problems getting the tls-cipher directive to work properly with the iOS OpenVPN client. It may be necessary to remove or comment that out.
To test OpenVPN, start it from the command line using
openvpn server.conf
. This will display the output to the terminal instead of logging it.Assuming you installed OpenVPN from a package, once you’ve tested everything you can use the regular service/systemctl/rc.d scripts to start the service.
OpenVPN’s iOS client requires a two stages for the config.
First you must export from XCA your client’s certificates in PKCS #12 format. You’ll also need a copy of the CA certificate for the server so that the client can verify that the server is properly signed.
Depending on what methods you have at your disposal getting the client certificate to the iOS device is kind of a hassle. You can mail it to your self, or if you have a web server on your local network that you can upload it to you can install it through Safari. Remember, that while the PKCS12 format is encrypted, it’s still a good idea now to go posting it all over the place if you can avoid it.
Uploading the OpenVPN configuration file is a little easier, that can be done through iTunes. Not it must have the extension ovpn for OpenVPN to detect it.
Below I’ve included a sample configuration for the client config. Like the server, you’ll need to change this to reflect your specific settings.
That should about cover the basics. At least I should say that should be enough for me to remember what I need to do next time I have to do this in n-years.