• Note -- this tutorial uses PKI via a separate Certificate Authority (CA), but there was an early Dabble I created that deploys an all in one solution here. 
• Note -- this tutorial uses exclusively PKI authentication -- there is a way to tie in OpenLDAP as a part of this process, but that will be saved for a possible future Dabble.

• If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
• Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:

sudo apt-get -y install openvpn

• We need to start by creating a directory for our keys:

• We need to then import the following files into our key folder -- these should be generated through your Certificate Authority and then moved to your VPN server:
• CA Certificate (ca.crt.pem)
• Server Certificate (vpnserver.crt.pem)
• Server Key (vpnserver.key.pem)
• Diffie-Hellman Parameters (dh4096.pem)
• Let's create our server TLS certificate using the following command:

• With the files in place, let's configure our server using the /etc/openvpn/server.conf file.  This will tell OpenVPN how we want it to operate.  I've attached a copy of the file used in this dabble at the end of this lesson for reference.  Make sure to update the following fields:

• With the server configuration complete, we need to update the system control configuration to ensure traffic coming into the VPN is forwarded onto the local network.  To do this, let's edit the /etc/sysctl.conf file using nano.  I've attached a copy of the file used in this dabble at the end of this lesson for reference.  Make sure to update the following field:

• With these changes configured, we need to apply them using the following command:

• OK, OpenVPN is now configured, but we need to update the RaspberryPi's firewall rules to allow traffic to be routed through the Pi.  It's best to use a script to accomplish this and locate it at /etc/firewall-openvpn-rules.sh.  First, create the script by issuing the nano command to edit the file (it is implicitly created) then insert the following lines.  I've attached a copy of the script at the end of this lesson for reference.  

• With the script created, we need to update the file permissions to ensure it is well protected.  Do that by executing the following commands to update the access control list and owner of the file.

• Good, now that we have the script created, we need to have it execute each time the network interface loads.  We do this by editing the /etc/network/interfaces file using nano.  I've attached a copy of the script at the end of this lesson for reference.  Edit the file using the following command and add the following line beneath the iface for eth0:

• Congratulations!  Your VPN is now ready to go!  You should reboot your Pi, validate your port forwarding, and then try to connect by using the external IP address of your router!

• If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
• Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:

• First things first, in the previous dabble, we created the directories for the intermediate Certificate Authority (CA).  Now, we need to create a server key.  
• Note -- this is written from the perspective of a Certificate Authority.  Third parties can also issue their own certificate signing requests (CSR) using their own private keys for us to sign and issue a certificate, but that is a different process for a different dabble.  
• Note -- while the CAs used 4096 bit keys, most server and client certificates use no larger than 2048 bit (many use 1024 bit) keys in the interest of balancing security with the performance of the TLS "handshake".  As a result, this dabble will use 2048 bit keys for the server and client certificates.
• Note -- certificates can be issued with or without passwords.  Passwords do make the certificate much more secure, but they also introduce the need to enter the password before use.  As a result, often server certificates do not use passwords (you would need to re-enter the password each time you restart a webserver, for example), some client certificates focused on services such as LDAPS or authentication of an embedded device also do not use passwords, but passwords should be used for client certificates needed for authentication in services such as VPN to ensure the authorized user is presenting the certificate.  Inclusion of the -aes256 option determines if a password will be tied to the certificate.

• With the key created, we need to generate a Certificate Signing Request (CSR) in order to create the actual certificate.  
• Note -- based on the configuration we used earlier to create the intermediate CA, the CSR details don’t need to match the intermediate CA, but I like to keep everything matching as a best practice. 
• Note -- for server certificates, the Common Name must be a fully qualified domain name (FQDN) such as vpn.academicdabbling.com, whereas for client certificates it can be any unique identifier such as a device name or eMail address. 
• Note -- the Common Name can not be the same as either your root or intermediate certificate.

• Now, to convert our CSR to a certificate, we will use the intermediate CA to sign the CSR.  Since, the certificate is going to be used on a client, we will use the usr_cert extension. 
• Note -- if the certificate were to be used for a server, we would use the server_cert extension instead. 
• Note -- certificates are usually given a validity of one year.  This way, though they are publicly facing and at greater risk of compromise, the risk is limited to a one year period.  Consider -- the one year expiration requires the certificate to be reissued at the end of that period; thus may projects or small businesses will issue for a greater period of time despite the risk.

• Let's make sure the root CA registered the signature process.  To do this, we need to look in the index.txt file of the root CA using the cat command.  Review any entries to ensure our new intermediate CA is listed.

• Good -- we know the certificate was signed, now let's check that the details of the cert look correct using OpenSSL.  Validate the details to ensure they align with your inputs.  In particular, the Issuer should be the intermediate CA and the Subject should refer to the certificate itself.

• OK -- now that we know the details look good, let's validate the intermediate CA cert against the root cert to ensure the chain of trust is intact.  If we get a response of "OK" we know everything worked.

• • If you are using this certificate with an application that requires Diffie-Hellman parameters, you need to add those to the certificate now.  This is optional as many services and applications do not require this.  You should have created a Diffie-Hellman parameter file when you created your intermediate Certificate Authority and it should follow the naming convention "dh<key size>.pem" (ex. dh2048.pem).  Issue the following command to add these parameters to your certificate.  Note, these commands were performed as root.

  sudo su root

  chmod 644 /root/ca/intermediate/VPN/certs/vpn.client.cert.pem

  cat /root/ca/intermediate/VPN/certs/dh2048.pem >> /root/ca/intermediate/VPN/certs/vpn.client.cert.pem

  chmod 444 /root/ca/intermediate/VPN/certs/vpn.client.cert.pem

  
  

  

  
  

  • OK, good.  Let's check our work -- if everything worked as planned, we'll see the Diffie-Hellman parameters appended to the bottom of the certificate.

  sudo cat /root/ca/intermediate/VPN/certs/vpn.client.cert.pem

  
  

  

  
  

• You can now deploy the certificate to the client -- this process is unique to each client and application, but perhaps there will be future dabbles about this.  Ensure the following files are available to the client:
• vpn.client.key.pem
• vpn.client.cert.pem
• Congratulations!  Your server certificate is now issued and ready to go!  

• If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
• Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:

• First things first, in the previous dabble, we created the directories for the intermediate Certificate Authority (CA).  Now, we need to create a server key.  
• Note -- this is written from the perspective of a Certificate Authority.  Third parties can also issue their own certificate signing requests (CSR) using their own private keys for us to sign and issue a certificate, but that is a different process for a different dabble.  
• Note -- while the CAs used 4096 bit keys, most server and client certificates use no larger than 2048 bit (many use 1024 bit) keys in the interest of balancing security with the performance of the TLS "handshake".  As a result, this dabble will use 2048 bit keys for the server and client certificates.
• Note -- certificates can be issued with or without passwords.  Passwords do make the certificate much more secure, but they also introduce the need to enter the password before use.  As a result, often server certificates do not use passwords (you would need to re-enter the password each time you restart a webserver, for example), some client certificates focused on services such as LDAPS or authentication of an embedded device also do not use passwords, but passwords should be used for client certificates needed for authentication in services such as VPN to ensure the authorized user is presenting the certificate.  Inclusion of the -aes256 option determines if a password will be tied to the certificate.

• With the key created, we need to generate a Certificate Signing Request (CSR) in order to create the actual certificate.  
• Note -- based on the configuration we used earlier to create the intermediate CA, the CSR details don’t need to match the intermediate CA, but I like to keep everything matching as a best practice. 
• Note -- for server certificates, the Common Name must be a fully qualified domain name (FQDN) such as vpn.academicdabbling.com, whereas for client certificates it can be any unique identifier such as a device name or eMail address. 
• Note -- the Common Name can not be the same as either your root or intermediate certificate.

• Now, to convert our CSR to a certificate, we will use the intermediate CA to sign the CSR.  Since, the certificate is going to be used on a server, we will use the server_cert extension. 
• Note -- if the certificate were to be used for user authentication, we would use the usr_cert extension instead. 
• Note -- certificates are usually given a validity of one year.  This way, though they are publicly facing and at greater risk of compromise, the risk is limited to a one year period.  Consider -- the one year expiration requires the certificate to be reissued at the end of that period; thus may projects or small businesses will issue for a greater period of time despite the risk.

• Let's make sure the root CA registered the signature process.  To do this, we need to look in the index.txt file of the root CA using the cat command.  Review any entries to ensure our new intermediate CA is listed.

• Good -- we know the certificate was signed, now let's check that the details of the cert look correct using OpenSSL.  Validate the details to ensure they align with your inputs.  In particular, the Issuer should be the intermediate CA and the Subject should refer to the certificate itself.

• OK -- now that we know the details look good, let's validate the intermediate CA cert against the root cert to ensure the chain of trust is intact.  If we get a response of "OK" we know everything worked.

• If you are using this certificate with an application that requires Diffie-Hellman parameters, you need to add those to the certificate now.  This is optional as many services and applications do not require this.  You should have created a Diffie-Hellman parameter file when you created your intermediate Certificate Authority and it should follow the naming convention "dh<key size>.pem" (ex. dh2048.pem).  Issue the following command to add these parameters to your certificate.  Note, these commands were performed as root.

• OK, good.  Let's check our work -- if everything worked as planned, we'll see the Diffie-Hellman parameters appended to the bottom of the certificate.

• You can now deploy the certificate to a server -- this process is unique to each server and application, but perhaps there will be future dabbles about this.  Ensure the following files are available to the server:
• ca-chain.cert.pem
• vpn.academicdabbling.com.key.pem
• vpn.academicdabbling.com.cert.pem
• Congratulations!  Your server certificate is now issued and ready to go!  

• If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
• Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:

• First things first, in the previous dabble, we created the directories for the primary Certificate Authority (CA).  Now, we need to set up the directory structure, called intermediate, to support Intermediate Certificate Authorities.  Note -- if you have set up an Intermediate Certificate Authority previously using these Dabbles then skip on to the next step and do not attempt to recreate this directory.

• With the main directory structure for the intermediate CAs created, it is time to create the the intermediate CA that we specifically want to deploy.  In this example, let's call it VPN as we'll plan to use these certificate pairs to deploy a VPN in a later lesson.

• we need to create a directory structure to hold all of the files and configurations related to the Certificate Authority (CA).  We'll create subfolders for certs, crl, newcerts, and private.  Note, we need to apply fairly restrictive permissions to these directories given the sensitive nature of the CA when the generated certificates are used for Authentication and Authorization.  

• If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
• Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:

• First things first, we need to create a directory structure to hold all of the files and configurations related to the Certificate Authority (CA).  In this case, we'll start with /root/ca and create subfolders for certs, crl, newcerts, and private.  Note, we need to apply fairly restrictive permissions to these directories given the sensitive nature of the CA when the generated certificates are used for Authentication and Authorization.  

• If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
• Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:

• If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
• Once connected, log onto the Pi using the pi username and builtin account.  It is important to use the pi account for purposes of this lesson as HomeAssistant will run under the pi account.  If you have not updated the password, you should, but these are the default credentials:

• OK, good!  Now that we are connected, let's install let's in

• If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
• Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:

• If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
• Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:

• If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
• Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials: