Certificate Management for OpenVPN with Easy-RSA

Introduction

This article provides a detailed overview of digital certificate management, essential for security in virtual private networks (VPNs) using OpenVPN. We will explore fundamental concepts such as Public Key Infrastructure (PKI) and Certificate Authority (CA), as well as the practical aspects of issuing, signing, renewing, revoking, and managing certificates with Easy-RSA.

This is one of two articles explaining how to set up an OpenVPN connection between a server and multiple clients and how to manage the certificates necessary to ensure secure connections.

For specific details on OpenVPN configuration, refer to:

Recommended reading: How to setup openVPN server with Easy-RSA on Linux.

Terminology

To understand certificate management, it is essential to know some terms that frequently appear in their abbreviated forms.

What is PKI?

PKI, an acronym for Public Key Infrastructure, is a set of technologies, policies, and procedures aimed at creating, managing, distributing, storing, and revoking digital certificates and public keys.

It serves as the foundation for the security of digital communications, ensuring the authenticity, integrity, and confidentiality of data in systems such as emails, online transactions, and VPNs.

What is CA?

CA, an acronym for Certificate Authority, is the entity responsible for issuing, signing, and managing digital certificates within a PKI. Its role is to verify the identity of individuals, servers, organizations, and other entities in the digital environment.

Some of the most commonly used CAs include DigiCert, GoDaddy, and Let's Encrypt, which issue globally recognized certificates.

It is possible to use online services to issue certificates and configure them in applications such as website hosting or VPN connections. However, most of these certificates are paid, which can make them unfeasible in many cases.

Fortunately, it is possible to create your own CA and manage certificates within a controlled structure.

What is a request?

It is a request sent to a CA for signing and conversion into a certificate. The term CSR (Certificate Signing Request) is also used to refer to this request, which includes the public key.

What is cert?

Cert is short for digital certificate, a file that links a public key to an identity, serving as a credential in the authentication process between devices on the network. The certificate is generated when a request (CSR) is signed by a CA, ensuring that its information is valid and trustworthy.

What is a keypair?

Keypair is a set consisting of a public key and a private key, used for authentication, encryption, and integrity verification in security systems. This key pair is the basis for generating digital certificates.

Public Key: shared openly with other systems, it is used to encrypt data or verify digital signatures.

Private Key: must be kept secret and stored securely. It is used to decrypt received data or digitally sign documents and transactions, ensuring the authenticity of the owning entity.

How does the keypair work?

If someone wants to send you an encrypted message, they will use your public key to encrypt it. Only you, with your private key, can decrypt and read the message.

When signing a document or certificate, you use your private key. Anyone with your public key can verify the authenticity of the signature, ensuring that it was indeed you who signed it.

PEM Format

Keys, certificates, and requests are stored in files in the PEM (Privacy-Enhanced Mail) format. This format uses Base64 encoding to represent encrypted data.

The .pem extension may not always be present, as files with extensions like .key, .crt, and .csr also use the PEM format.

Certificate Authority - CA

The CA is the central part of a PKI and also the most critical element in terms of security. Its private key is responsible for signing all issued certificates. If access to the CA is compromised, an attacker can sign and revoke certificates, putting the entire system at risk.

For this reason, it is recommended to configure the CA's PKI securely. It is not advisable to administer it alongside VPN clients or servers. Depending on security needs, the CA can be maintained in a highly restricted account, on a dedicated system (virtualized but isolated from the VPN), on an offline system, or even on removable media such as a USB drive, external hard drive, or smart card.

When creating a new CA, a key pair (public and private) is generated, along with the necessary file structure to support certificate signing.

How everything fits together

To create a PKI, start by configuring a CA, which will be responsible for the certificates. During this configuration, a key pair is generated: the private key is stored in a file with the .key extension, while the public key is included in the certificate, a file with the .crt extension.

The next step is to generate the key pair for the server. As with the CA, the private key is stored in a .key file, while the public key is embedded in a .req request file. This request must be signed by the CA to become a valid .crt certificate, which will contain the public key information.

The same process is performed for the client: a key pair is generated, and the CA signs the request to generate the certificate.

The key pair, both for the client and the server, can be generated directly by the CA or locally on the server/client, sending only the request to the CA for signing. The second method is preferable, as the private key never leaves the location where it will be used.

Certificate requests (.req) do not contain sensitive information and can be transferred by any convenient means. Signed certificates (.crt) do not need to be protected with the same rigor as private keys, but they may include specific identifiers exploitable by attackers. To avoid risks, it is recommended to transfer them using secure methods.

If the key pair is generated at the CA, the private key (.key) will need to be securely transmitted to the server or client. This process is critical and, whenever possible, should be done via physical media (external hard drive, USB drive) to avoid interception. Alternatively, the transfer can be done via SSH (scp, sftp) or HTTPS, which are considered secure methods.

Connecting server and client

Two systems that have certificates signed by the same CA, in addition to the CA's own certificate, can communicate without ever having directly exchanged security information.

During the TLS handshake, each system presents its certificate, and the other side verifies its validity by comparing it with its copy of the CA certificate. Since both trust the same CA, the certificates are validated, and the connection is authenticated.

Each system proves the validity of its certificate by signing a set of data with its private key. Since only the holder of the private key can perform this signature, its security must be guaranteed. This process confirms the authenticity of the certificates and allows the secure establishment of the connection.

Easy-RSA - Introduction

Now it's time to move on to practice, setting up your PKI, your CA, and generating the necessary certificates. For this, we will use Easy-RSA.

Easy-RSA is a script used to manage digital certificates within a Public Key Infrastructure (PKI). It is widely used in conjunction with OpenVPN to create and manage SSL/TLS certificates essential for configuring a secure VPN.

Designed to be intuitive, Easy-RSA simplifies certificate administration, even for those without advanced knowledge of cryptography. It automates much of the processes involved in managing a PKI, making it a valuable tool for network administrators.

Download Easy-RSA

The CA needs to be kept secure. Among the methods mentioned earlier, a USB drive will be used to create the CA's PKI. Thus, after configuration, simply remove the device and store it in a protected location to ensure the security of the private keys.

In this example, we will assume that the USB drive is mounted at /mnt/usb. Easy-RSA should be configured with a regular user, without administrator permissions.

Important: The USB drive must be formatted with a Linux-compatible file system (ext3, ext4, xfs, etc.), otherwise, it will not be possible to execute the easyrsa script.

Installing Easy-RSA is simple and identical on any Linux system. To download it, access the USB drive directory and execute:

$ bash

cd /mnt/usb
git clone https://github.com/OpenVPN/easy-rsa

The command above will download the latest version available in the official Easy-RSA repository on GitHub, which, at the time of this article, is 3.3.0.

If you prefer to download a specific version, use:

git clone --branch v3.2.2 https://github.com/OpenVPN/easy-rsa

The command above will download version 3.2.2 of Easy-RSA.

Recommended reading: Using Git to share and collaborate on a project

Configuring EasyRSA

The base directory of EasyRSA is located at easy-rsa/easyrsa3/.

Before starting, it is recommended to adjust some variables used in the scripts to ensure data consistency during certificate generation. To do this, copy the example file vars.example to vars:

$ bash

cd /mnt/usb/easy-rsa/easyrsa3/
cp vars.example vars
vi vars

Now, edit the vars file with your preferred text editor. Remove the comments from the lines below and customize them with your information:

/mnt/usb/easy-rsa/easyrsa3/vars

# Organizational fields
set_var EASYRSA_REQ_COUNTRY  "US" # Country
set_var EASYRSA_REQ_PROVINCE "California" # State
set_var EASYRSA_REQ_CITY     "Los Angeles" # City
set_var EASYRSA_REQ_ORG      "My company" # Organization name
set_var EASYRSA_REQ_EMAIL    "contact@mycompany.com" # Email
set_var EASYRSA_REQ_OU       "IT Department" # Organizational Unit

# Expiration (in days)
set_var EASYRSA_CA_EXPIRE   7300 # CA validity
set_var EASYRSA_CERT_EXPIRE 3650 # Validity of issued certificates

The first parameters configured in the vars file are the organizational fields, which will be incorporated into all generated certificates. This information identifies the entity using the certificate and provides contact details.

The value of EASYRSA_REQ_COUNTRY must follow the two-character convention defined by ISO 3166-1 alpha-2.

The second set of variables defines the expiration time of the CA certificate and the certificates issued for VPN clients and servers. The time is specified in days. For the CA, a long period is recommended, possibly longer than the default 10 years (3,650 days), such as 20 years (7,300 days). This is because, when the CA certificate expires, all certificates it has signed become invalid, and its renewal requires distributing the new CA certificate to all VPN clients and servers.

For client and server certificates, a slightly shorter period can be adopted. However, a long period, such as 10 years, may be suitable. If necessary, any certificate can be manually revoked at any time, this process will be covered later.

Maintaining a well-structured revocation mechanism can be more efficient than dealing with automatic expirations.

The remaining variables in the vars file should only be modified by those who understand their purpose and will not be covered in this article.

Creating the PKI

To configure a new Public Key Infrastructure (PKI) with Easy-RSA, use the ./easyrsa init-pki command. If you need help with the available parameters, execute ./easyrsa help [command].

Attention! The init-pki command removes any previous configuration, including already created certificates. Use it only when starting a new configuration or reconfiguring the entire infrastructure.

$ bash

# Access the EasyRSA directory
cd /mnt/usb/easy-rsa/easyrsa3/

# Initialize the PKI
./easyrsa init-pki

Using Easy-RSA 'vars' configuration:
* /mnt/usb/easy-rsa/easyrsa3/vars

Notice
------
'init-pki' complete; you may now create a CA or requests.

Your newly created PKI dir is:
* /mnt/usb/easy-rsa/easyrsa3/pki

Using Easy-RSA configuration:
* /mnt/usb/easy-rsa/easyrsa3/vars

This command creates a directory called pki/, which contains the necessary structure to store and manage requests, private keys, and certificates.

The next step is to create the Certificate Authority (CA).

Creating your own CA

During the creation of the CA's private key, some information will be requested:

Password for key creation

A password will be used to encrypt the private key file. This ensures that even if someone gains access to the file, they cannot use it without the correct password. Keep this password secure, as it will be needed every time a request is signed.

Common Name (CN)

Identifies the Certificate Authority and is used only for display. In this example, we will use the site name Telazul, adjust it according to your application.

Creating the CA with Easy-RSA

To create your own CA, execute the following command:

$ bash

# Access the EasyRSA directory
cd /mnt/usb/easy-rsa/easyrsa3/

# Create the CA
./easyrsa build-ca

Using Easy-RSA 'vars' configuration:
* /mnt/usb/easy-rsa/easyrsa3/vars

Enter New CA Key Passphrase: # Enter the password

Confirm New CA Key Passphrase: # Confirm the password
...............................................................................................................................+++++
...............................................................+++++
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]: Telazul # CA name

Notice
------
CA creation complete. Your new CA certificate is at:
* /mnt/usb/easy-rsa/easyrsa3/pki/ca.crt

Create an OpenVPN TLS-AUTH|TLS-CRYPT-V1 key now: See 'help gen-tls'

Build-ca completed successfully.

Your Certificate Authority has been successfully generated.

Next steps

The next step will be to generate the TLS key and the Diffie-Hellman (DH) parameters. Both protect the VPN connection negotiation, but in different ways:

• TLS-AUTH/TLS-CRYPT: Protects the integrity and confidentiality of communication.
• DH (Diffie-Hellman): Protects the exchange of cryptographic keys.

Generating the TLS key

The TLS-Crypt key is used to protect OpenVPN communication, preventing forged packets from being accepted, making DoS attacks more difficult, and obfuscating the TLS handshake, making VPN detection by third parties more difficult. To generate the key, execute:

$ bash

./easyrsa gen-tls-crypt-key

Using Easy-RSA 'vars' configuration:
* /mnt/usb/easy-rsa/easyrsa3/vars

Notice
------
TLS-CRYPT Key generated at:
* /mnt/usb/easy-rsa/easyrsa3/pki/private/easyrsa-tls.key

If this file is changed then it MUST be redistributed to ALL servers
AND clients, to be in effect. Do NOT change this existing file.

This key prevents third parties from interfering with communication or detecting that the VPN is in operation.

Generating Diffie-Hellman (DH) parameters

The Diffie-Hellman (DH) protocol allows two participants to establish a shared secret over an insecure channel without directly transmitting the secret key, ensuring greater security in key exchange. To generate the DH parameters, execute:

$ bash

./easyrsa gen-dh

Using Easy-RSA 'vars' configuration:
* /mnt/usb/easy-rsa/easyrsa3/vars
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
..............+.....................
........................++*++*++*++*
DH parameters appear to be ok.

Notice
------

DH parameters of size 2048 created at:
* /mnt/usb/easy-rsa/easyrsa3/pki/dh.pem

The use of Diffie-Hellman allows OpenVPN to establish a shared secret without directly exposing the key, protecting the confidentiality of communication.

Exploring the PKI

The previous commands created the basic structure of the PKI. Let's examine it:

$ bash

tree pki/

pki/
├── ca.crt
├── certs_by_serial
├── dh.pem
├── index.txt
├── issued
├── private
│   ├── ca.key
│   └── easyrsa-tls.key
├── reqs
├── revoked
│   ├── certs_by_serial
│   └── private_by_serial
├── serial

• ca.crt ➔ CA certificate.
• certs_by_serial ➔ Directory containing certificates signed by the CA, organized by serial number.
• dh.pem ➔ Diffie-Hellman (DH) parameters.
• index.txt ➔ Database with the record of issued certificates.
• issued ➔ Directory containing certificates signed by the CA, organized by common name (CN).
• private ➔ Directory where private keys are stored. 
• private/ca.key ➔ CA private key.
• private/easyrsa-tls.key ➔ TLS private key.
• reqs ➔ Location for storing certificate requests.
• revoked ➔ Directory containing revoked certificates and keys.
• serial ➔ File that stores the serial number of the next certificate to be issued.

With this structure, the CA is ready to generate requests, create keys, and sign certificates. The next step will be to create the necessary files for the OpenVPN server and clients.

Fictional scenario

To illustrate the following examples, let's consider a fictional scenario where employees of an office work remotely and need to connect to the company's network to perform their duties.

In this context, the OpenVPN server will be installed in the office, while the VPN clients will be configured on the employees' devices at their homes.

Generating the server key pair

To generate the server keys, use the ./easyrsa gen-req [server-name] command. In this example, we will add the nopass parameter, which disables the use of a password when creating the private key.

Using a password is recommended, but it can be inconvenient on remote servers or systems without easy access to a keyboard, as it will require typing it every time the service starts. Since the key without a password is not encrypted, it is essential to restrict its access with appropriate permissions, a topic covered in the article on OpenVPN server configuration mentioned in the introduction.

$ bash

./easyrsa gen-req office nopass

Using Easy-RSA 'vars' configuration:
* /mnt/usb/easy-rsa/easyrsa3/vars
Generating a RSA private key
...........................+++++
.....................................................+++++
writing new private key to '/mnt/usb/easy-rsa/easyrsa3/pki/3c601300/temp.2.1'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [office]: Enter ↲ # Confirm

Notice
------
Private-Key and Public-Certificate-Request files created.
Your files are:
* req: /mnt/usb/easy-rsa/easyrsa3/pki/reqs/office.req
* key: /mnt/usb/easy-rsa/easyrsa3/pki/private/office.key

Now, the server key pair is ready. The next step is to sign the generated certificate request (CSR).

Signing the server request

To sign the server request, use the ./easyrsa sign-req server [server-name] command. During the process, confirm the details by typing yes when prompted, then, enter the CA private key password, generated in the build-ca command.

$ bash

./easyrsa sign-req server office

Using Easy-RSA 'vars' configuration:
* /mnt/usb/easy-rsa/easyrsa3/vars
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.
You are about to sign the following certificate:

  Requested CN:     'office'
  Requested type:   'server'
  Valid for:        '3650' days


subject=
    commonName                = office

Type the word 'yes' to continue, or any other input to abort.
  Confirm requested details: yes # Confirm

Using configuration from /mnt/usb/easy-rsa/easyrsa3/pki/80bec09b/temp.1.1

Enter pass phrase for /mnt/usb/easy-rsa/easyrsa3/pki/private/ca.key: # CA password
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'office'
Certificate is to be certified until Feb 23 18:09:06 2035 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated

Notice
------
Inline file created:
* /mnt/usb/easy-rsa/easyrsa3/pki/inline/private/office.inline

Notice
------
Certificate created at:
* /mnt/usb/easy-rsa/easyrsa3/pki/issued/office.crt

The server certificate has been generated and stored in pki/issued/office.crt. This file will be needed in the OpenVPN configuration.

Copying files to the server

Connect the USB drive containing the CA to the server and copy the files to the OpenVPN configuration directory. Since administrative permissions are required, execute the commands as root or with sudo.

# bash

cp /mnt/usb/easy-rsa/easyrsa3/pki/ca.crt /etc/openvpn/certs/
cp /mnt/usb/easy-rsa/easyrsa3/pki/issued/office.crt /etc/openvpn/certs/
cp /mnt/usb/easy-rsa/easyrsa3/pki/dh.pem /etc/openvpn/certs/
cp /mnt/usb/easy-rsa/easyrsa3/pki/private/office.key /etc/openvpn/keys/
cp /mnt/usb/easy-rsa/easyrsa3/pki/private/easyrsa-tls.key /etc/openvpn/keys/

Generating the client key pair

The key pair can be generated at the CA and then transferred to the client, but the recommended practice is to generate it directly on the client and send only the request to the CA for signing. This way, the private key never leaves the client, increasing security.

Next, this process will be demonstrated, with the key generation on the client and the import of the request to the CA for signing. Since the previous examples have already been detailed, here the commands will be presented more objectively.

Generating the request on the client

With a regular user, download Easy-RSA, initialize the PKI, and generate the key pair. In this example, the client will be identified as home.

$ bash

Download Easy-RSA on the client
git clone https://github.com/OpenVPN/easy-rsa

Access the easyrsa script directory
cd easy-rsa/easyrsa3

Initialize the PKI
./easyrsa init-pki

Generate the keys without a password
./easyrsa gen-req home nopass

Copy the generated request pki/reqs/home.req from the client to the server. Connect the USB drive with the CA structure to the server and import the request. Do not copy the request to the USB drive as it may cause conflicts. Leave it on the computer, the import-req command will automatically copy it to pki/reqs/.

$ bash

cd /mnt/usb/easy-rsa/easyrsa3/
./easyrsa import-req /path/to/home.req home

Using Easy-RSA 'vars' configuration:
* /mnt/usb/easy-rsa/easyrsa3/vars

Notice
------
Request successfully imported with short-name: home
This request is now ready to be signed.

Sign the request with the CA. During the process, you will be asked to confirm the request details, type yes and press Enter ↲, then enter the CA password.

$ bash

./easyrsa sign-req client home

Note that the sign-req parameter changes from server to client when signing certificates for clients. This distinction is essential, as a certificate incorrectly signed as a server will not work for the client connection.

After signing, the certificate will be available at pki/issued/home.crt.

Copying files to the client

To facilitate the explanation, it will be considered that the USB drive containing the CA and certificates was taken to the employee's home to copy the files. If transferring them over the internet, use a secure method such as SSH (scp, sftp) or HTTPS.

Plug the USB drive containing the CA into the client and copy the files to the OpenVPN configuration directory. Administrative permissions will be required, execute the commands as root or use the sudo command.

Connect the USB drive to the client and copy the files to the OpenVPN configuration directory:

# bash

cp /mnt/usb/easy-rsa/easyrsa3/pki/ca.crt /etc/openvpn/certs/
cp /mnt/usb/easy-rsa/easyrsa3/pki/issued/home.crt /etc/openvpn/certs/
cp /mnt/usb/easy-rsa/easyrsa3/pki/private/easyrsa-tls.key /etc/openvpn/keys/

# Key generated on the client itself
cp /path/to/easy-rsa/easyrsa3/pki/private/home.key /etc/openvpn/keys/

The VPN configuration on the client is detailed in the article on OpenVPN configuration, mentioned in the introduction.

Revoking a certificate

Revoking certificates is an essential measure to maintain VPN security. Whenever a device is deactivated, compromised, or an employee leaves the company, it is crucial to revoke their certificate to prevent unauthorized access.

To revoke a certificate and invalidate its use, use the command: ./easyrsa revoke requestName.

This process is irreversible. You will be asked to confirm the revocation by typing yes. Then, enter the CA key password when prompted to complete the revocation.

$ bash

./easyrsa revoke home

The revoked certificate will be moved to the revoked/ folder within the CA's PKI environment.

However, revocation alone does not automatically block the client. The server needs to be configured to consult the Certificate Revocation List (CRL). If this list is not updated on the server, revoked clients may still be able to connect.

Execute the command below and enter the CA password when prompted:

$ bash

./easyrsa gen-crl

This will create a file called crl.pem. Copy it to the OpenVPN configuration directory on the server:

$ shell

cp /mnt/usb/easy-rsa/easyrsa3/pki/crl.pem /etc/openvpn/

In the OpenVPN server configuration file (office.conf, in this example), add the following line so that the server consults the CRL:

office.conf

crl-verify  /etc/openvpn/crl.pem

Restart the OpenVPN server to apply the change. After this, when a client attempts to connect with a revoked certificate, the server log will display the following message:

/var/log/openvpn.log

VERIFY ERROR: depth=0, error=certificate revoked: CN=home

The CRL will be checked every time a client attempts to connect. Since the OpenVPN server is configured to reduce privileges after initialization and operate as the nobody user, it is necessary to ensure that the crl.pem file can be read correctly. Adjust the permissions with the following commands:

# bash

chown root:nobody /etc/openvpn/crl.pem
chmod 440 /etc/openvpn/crl.pem

Attention: Whenever a certificate is revoked, a new CRL must be generated and copied to the server. If the CRL expires, no client will be able to connect until it is updated.

Renewing a certificate

Certificates have an expiration date and will eventually need to be renewed. This process can be done either before or after expiration. Essentially, renewal involves creating a new certificate and revoking the old one. However, the procedure uses specific commands that allow reusing the same name as the original certificate.

If you want to test this functionality, you can increase the expiration period of the certificates in the vars file, as we will do here, and renew the certificate. To check the current validity of a certificate, use the command:

$ shell

openssl x509 -in pki/issued/home.crt -noout -dates

notBefore=Feb 27 18:04:32 2025 GMT
notAfter=Feb 25 18:04:32 2035 GMT

For testing purposes, change the expiration to 20 years in the vars file by modifying the line set_var EASYRSA_CERT_EXPIRE 7300. If the certificate has already expired or is close to expiration, simply execute the following commands to renew it for another 10 years, without the need to modify the expiration configuration.

$ shell

./easyrsa renew home

The process will display a warning informing that the current certificate will be deleted. Confirm with yes. Then, you will be asked to confirm the creation of the new certificate, yes again. Finally, enter the CA key password to sign the new certificate.

Revoke the old certificate with the command:

$ bash

./easyrsa revoke-renewed home

Yes to confirm and enter the CA key password to complete the revocation. Think it's over? Not yet! The next step is to update the CRL, which is done with the command:

$ bash

./easyrsa gen-crl

For more information, refer to the topic Revoking a certificate in this article.

On the client

Copy the new certificate and the new key to the client:

# bash

cp /mnt/usb/easy-rsa/easyrsa3/pki/issued/home.crt /etc/openvpn/certs/
cp /mnt/usb/easy-rsa/easyrsa3/pki/private/home.key /etc/openvpn/keys/

On the server

Copy the new CRL to the server:

# bash

cp /mnt/usb/easy-rsa/easyrsa3/pki/crl.pem /etc/openvpn/

Restart the OpenVPN service on the client and the server:

# bash

/etc/rc.d/rc.openvpn restart

Checking the new expiration of the certificate:

$ shell

openssl x509 -in pki/issued/home.crt -noout -dates

notBefore=Feb 27 18:12:09 2025 GMT
notAfter=Feb 22 18:12:09 2045 GMT

Notice that the new expiration will be in 2045 instead of 2035. Although the renewal process is simple, it can be laborious, which is why it was previously suggested to work with longer expiration dates.

Configuring the server and client in OpenVPN

To configure OpenVPN and integrate the generated certificates, check out the article How to setup openVPN server with Easy-RSA on Linux. In it, you will find detailed instructions for adjusting the service and establishing secure connections between clients and servers.

Conclusion

This article presented the use of Easy-RSA to manage keys and certificates on Linux, covering from the creation of the CA to the revocation and renewal of certificates. With these procedures, it is possible to establish a secure authentication infrastructure for OpenVPN, ensuring control over the devices that can connect to the network.

References

• https://easy-rsa.readthedocs.io/en/latest/

Site Notes

This is not my original language and I don't speak it very well. I used my little knowledge and translators tools to compose the text of this article. Sorry for possible spelling or grammatical errors, suggestions for corrections are appreciated and can be sent to the contact email in the footer of the site. My intention is to share some knowledge and I hope this translation is good enough.

Some of the content on this website, including text, images, graphics and other materials, may be generated or enhanced by artificial intelligence (AI) tools. For more details on the use of AI, please see our Term of Use.