StrongSwan: Difference between revisions
m Saved progress so far |
m →Packaging the required certificates and keys for Windows: Added password required |
||
Line 93: | Line 93: | ||
# Use OpenSSL to create the PKCS#12 package: | # Use OpenSSL to create the PKCS#12 package: | ||
#:<pre>openssl pkcs12 -export -inkey private/client1key.pem -in certs/client1cert.pem -name "Windows Client 1 VPN Certificate" -certfile cacerts/CAcert.pem -caname "strongSwan Root CA" -out client1.p12</pre> | #:<pre>openssl pkcs12 -export -inkey private/client1key.pem -in certs/client1cert.pem -name "Windows Client 1 VPN Certificate" -certfile cacerts/CAcert.pem -caname "strongSwan Root CA" -out client1.p12</pre> | ||
# Type a password you will remember when asked. This will protect the private key while it is in transit. | |||
# Retype the passsword you just typed. | |||
The name field gives the certificate a friendly name when installed in Windows and can be anything. The p12 file needs to be copied locally to the Windows machine that the certificates and keys need installing on. | The name field gives the certificate a friendly name when installed in Windows and can be anything. The p12 file needs to be copied locally to the Windows machine that the certificates and keys need installing on. |
Revision as of 02:44, 11 July 2018
strongSwan is a VPN server that allows a connection over the insecure internet to a secure private network. The connection is encrypted and authenticated for confidentiality and to prevent tampering of the data. It allows the following:
- Secure internet browsing over an insecure, open Wi-Fi connection.
- Allows full access to your internal network securely over the insecure internet.
We will be setting up the connection to allow a connection from this server to a Windows 10 1803 (Spring Creators Update) client. Windows 10 1803 supports the Internet Key Exchange v2 (IKEv2), which is a modern VPN protocol and has some provisions for working over the internet, such as MOBIKE. This helps in situations where the internet connection maybe poor and has to reconnect. Windows 10 1803 supports the use of the following modern ciphers:
- Certificate authentication.
- ECDSA certificates (256 and 384-bit keys).
- ESP supports AES-GCM 128 & 256-bit for both encryption and authentication.
We will be configuring our connection to use ECDSA 384-bit certificates and AES256-GCM encryption/authentication, currently the strongest supported settings.
Note that Windows initially uses VERY weak encryption and authentication schemes by default (from the Windows 2000 days) so it is very important to set up the connection correctly and not use the default Windows settings.
During the writing of this guide, the version of strongSwan was 5.6.0 in openSUSE Leap 15.0.
What is needed
Make sure the following packages is installed:
strongswan
openssl
Allow any dependencies the packages asks for.
Creating the certificates
IKEv2 can use a Username/Pre-shared Key (PSK) for authentication. This is a very weak method of authenticating and is easily brute-forced. Certificates, especially when created correctly, are the strongest possible way to authenticate.
We will be creating modern, elliptic curve certificates. These use very short keys (384-bits) compared to RSA keys (4096-bits) but provide the same amount of security.
Initial setup
- As most of this work will require root privileges, open a Terminal and elevate to root by typing
su
. Type the root user password. - Move to the correct path. If strongSwan is installed correctly, you should be able to type
cd /etc/ipsec.d
. This is strongSwan's PKI directory.
Creating a self-signed certificate authority (CA)
To sign out certificates we will be creating, we first need to create a CA certificate.
- Make sure you are in the correct directory above.
- Generate a private key for the CA:
ipsec pki --gen --type ecdsa --size 384 --outform pem > private/CAkey.pem
- Change the permissions of the private key, so that only root can access it:
chmod 600 private/CAkey.pem
- Now we have the private key, generate the CA certificate:
ipsec pki --self --ca --lifetime 3650 --in private/CAkey.pem --type ecdsa --dn "C=GB, O=strongSwan, CN=strongSwan Root CA" --outform pem > cacerts/CAcert.pem
You now have a self-signed CA certificate, ready to sign any certificates to be used by the VPN server.
IMPORTANT: The private key, created in the private folder must NEVER be disclosed. If anybody were to obtain access to this key, they would be able to create any certificate they like, impersonate you and connect to the server. As this is the CA certificate, a compromise would require a whole new CA key, certificate and any certificates signed by the old, compromised CA. KEEP THIS SAFE.
Creating a certificate for the server
- Make sure you are still in the correct directory.
- Generate a private key for the certificate:
ipsec pki --gen --type ecdsa --size 384 --outform pem > private/serverkey.pem
- Change the permissions of the private key, so that only root can access it:
chmod 600 private/serverkey.pem
- Now we have the private key, generate the server certificate:
ipsec pki --pub --in private/serverkey.pem --type ecdsa | ipsec pki --issue --lifetime 365 --cacert cacerts/CAcert.pem --cakey private/CAkey.pem --dn "C=GB, O=strongSwan, CN=thinkserver.freddythechick.uk" --san thinkserver.freddythechick.uk --flag serverAuth --outform pem > certs/servercert.pem
The certificate created will be used to authenticate the VPN server. Only one needs creating.
IMPORTANT NOTES
When customising to fit your server, certain parts of the certificate generation must be done correctly for Windows to allow the certificate to be used. If not done correctly, Windows will refuse to connect. It is advisable to make sure these are correct in the first place to avoid errors further down the line and painstaking troubleshooting.
- The Common Name (
CN
) part of the Distinguishable Name (DN) MUST be the DNS resolvable name you will be using to connect to the VPN server from Windows. - The SAN MUST also be the DNS resolvable name you will be using to connect to the VPN server from Windows. It MUST also match the
CN
from the DN. - It MUST contain the
serverAuth
flag.
Creating a certificate for clients
Each client that needs to connect to the server requires a certificate to be generated for it.
- Make sure you are still in the correct directory.
- Generate a private key for the certificate:
ipsec pki --gen --type ecdsa --size 384 --outform pem > private/client1key.pem
- Change the permissions of the private key, so that only root can access it:
chmod 600 private/client1key.pem
- Now we have the private key, generate the server certificate:
ipsec pki --pub --in private/client1key.pem --type ecdsa | ipsec pki --issue --lifetime 365 --cacert cacerts/CAcert.pem --cakey private/CAkey.pem --dn "C=GB, O=strongSwan, CN=username@freddythechick.uk" --san username@freddythechick.uk --outform pem > certs/client1cert.pem
The CN
in the DN this time is a username@the root DNS address. The CN
can actually be anything in this instance. No flags are required.
Packaging the required certificates and keys for Windows
All the keys and certificates required for the connection can be packaged into a PKCS#12 package, to allow easy installation on Windows.
- Make sure you are still in the correct directory.
- Use OpenSSL to create the PKCS#12 package:
openssl pkcs12 -export -inkey private/client1key.pem -in certs/client1cert.pem -name "Windows Client 1 VPN Certificate" -certfile cacerts/CAcert.pem -caname "strongSwan Root CA" -out client1.p12
- Type a password you will remember when asked. This will protect the private key while it is in transit.
- Retype the passsword you just typed.
The name field gives the certificate a friendly name when installed in Windows and can be anything. The p12 file needs to be copied locally to the Windows machine that the certificates and keys need installing on.
Configuring strongSwan
Configuring Windows
This part is arguably the trickiest part of the whole procedure. The Windows "Agile VPN" client has particular ways it must be configured or the VPN connection will fail. Error messages emitted when the connection fails are generally unhelpful and need manual troubleshooting to find the problem. If followed correctly, these procedures will allow you to connect successfully first time.