Public Key Infrastructure

Introduction

About this Document

The AXS Guard PKI How To serves as a reference and practical source for technical personnel and / or system administrators. In this guide, we explain the concept of the Public Key Infrastructure (PKI), the purpose and use of Digital Certificates and how to configure them on the AXS Guard for its various services, such as Virtual Private Networking and secure e-mail relaying.

Examples used in this Guide

All setups and configuration examples in this guide are executed as an advanced administrator. Some options are not available if you log in as a full administrator or a user with lower access privileges.

As software development and documentation are ongoing processes, the screenshots shown in this guide may slightly deviate from the current user interface.

PKI Concepts

Overview

In this section, we explain the concepts underpinning the Public Key Infrastructure (PKI). PKI is defined as the set of hardware, software, individuals, policies and procedures needed to safely create, manage, store, distribute, and revoke Public Key Certificates based on Public-Key cryptography . PKI provides user identity inspection and assurance .

Topics covered in this section include:

A definition of PKI and the elements of PKI, which together ensure the secure transmission and distribution of Digital Certificates, containing Public Keys .
Digital Certificates: Special files, containing Public Keys, used to authenticate users or hosts.
Digital Certificate types, such as X.509, which are used to authenticate IPsec Road Warriors with the AXS Guard.
Certificate Revocation Lists, which are used to revoke compromised Digital Certificates.

What is a Public Key Infrastructure?

The Public Key Infrastructure or PKI (illustrated below) is the set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke Digital Certificates (containing Public Keys) based on Public Key cryptography.

Trusted Parties

A Trusted Third Party is an agency providing security-related services and activities to one or more entities in a given security structure. PKI involves several types of Trusted Parties, such as Certificate Authorities (CA), Registration Authorities (RA) and Verification Authorities (VA).

Nowadays, CAs, RAs and VAs usually are a same entity.

Purpose of PKI

The purpose of a public-key infrastructure is to manage keys and certificates. By managing keys and certificates through a PKI, an organization establishes and maintains a trustworthy networking environment. A PKI enables the use of encryption and digital signature services across a wide variety of applications, e.g.

VPN applications, such as IPsec, OpenVPN and L2TP clients
Secure e-mail relaying
Secure web servers

Registration Authorities

A Registration Authority (RA) is the entity that enters into an agreement with a Certification Authority (CA) to collect and verify each Subscriber’s (requester) identity and information to be entered into his or her Public Key Certificate.

Areas and activities overseen by the RA include, but are not limited to:

In person proofing
Verification and validation of submitted identity documents
Enrollment and registration
Credential issuance
Credential usage
Credential revocation
Post issuance updates and additions

Nowadays, a CA performs the duties of an RA.

Certificate Authorities

A Certificate Authority or CA is an authority which issues Digital Certificates, comparable to a personal ID or passport . The aim is to establish trust through authentication. A CA has its own Public/Private key pair to perform this task.

As part of a Public Key Infrastructure (PKI), a CA checks with a Registration Authority (RA) to verify information provided by the requester of a Digital Certificate. After the RA verifies the information provided by the requester, the CA can issue a Digital Certificate.

A CA uses its Private Key to sign the Digital Certificate that it issues to protect the certificate’s origin. Other parties can use the CA certificate to verify the authenticity of the issued Digital Certificate.

There are two types of CAs, namely commercial and non-commercial CAs.

Commercial CAs

A CA can be a public commercial entity, such as VeriSign or GlobalSign. Several businesses provide commercial Certificate Authority services for Internet users. Digital Certificates issued by Commercial CAs can be easily verified.

Non-Commercial CAs

A CA can also be a private entity that an organization operates internally, e.g. the built-in AXS Guard CA. It serves the same purpose as a commercial CA. However, the main difference with a commercial CA is that the identity of the issuing authority cannot be verified automatically. Caution is advised when accepting digital certificates of a non-commercial CA. Only accept the certificate if you are absolutely sure about its origin. When connecting to a server which uses a certificate issued by a private CA, such as the AXS Guard appliance, a warning will be shown in your browser:

Verification Authorities

Either a Verification Authority (VA) or the Certificate Authority which issued the Digital Certificate can verify user identities. Certificates are stored by the browser. During a secure online transaction, you may be requested to provide a certificate to the server your are connecting to. The provided certificate is securely transmitted to the VA server which authenticates the issuing authority (CA). As such, the integrity of the provided certificate can be established.

Digital Certificates

Digital Certificates identify the individual or business named in the certificate, and bind that person or business to a particular Public / Private Key pair, hereby providing data integrity, user identification and authentication, user non-repudiation, data confidentiality, encryption and Digital Signature services for programs and applications. They have the same properties as a regular passport required for travel, namely:

They have limited validity.
They have a serial number.
They contain the Public Key of the owner (subject).
They can only be issued by certain authorities (CA).
They are signed with the Private Key of the CA.
They can be revoked if necessary, e.g. when compromised or if the holder is no longer authorized to access a service.

AXS Guard Certificate Types

Client Certificate

Used to authenticate VPN clients, such as OpenVPN, L2TP and IPsec clients with the AXS Guard VPN server, i.e. X.509 certificates.

Server Certificate

Server certificates (Root certificates) identify servers that participate in secure communications with other computers using communication protocols such as SSL. These certificates allow a server to prove its identity to clients. Server certificates follow the X.509 certificate format that is defined by the Public-Key Cryptography Standards. These certificates can be used to identify servers that are shielded by the AXS Guard Reverse Proxy, to identify the AXS Guard MTA (if TLS is used) or to identify the several AXS Guard VPN servers.

Root certificates are self-signed, which means that the subject of the certificate is also its signer. Root Certification Authorities have the ability to assign certificates for Intermediate Certification Authorities.

Personal AXS Guard Certificate

This type is required to successfully connect a Personal AXS Guard to the AXS Guard VPN server. For details about the Personal AXS Guard, see the Personal AXS Guard How To, which is accessible via the Documentation button in the Administrator Tool.

Important

A self-signed certificate is an identity certificate that is signed by its own creator. Such certificates should only be accepted and used for transactions if you are absolutely sure about their origin.

Supported Formats

The following certificate file types are supported:

PEM Certificate Files (with or without a separate key file)
PKCS12 Certificate Files

About X.509

X.509 is a standardized format for Digital Certificates. Since certificate servers are basically databases, it made sense that all certificates contain the same fields for information; making it easier for the certificate servers to manage the storage and distribution of certificates.

A certificate that complies with the X.509v3 standard will contain the following information: version, serial number, signature algorithm ID, issuer name, validity period, subject (user) name, subject Public Key information, issuer unique identifier, subject unique identifier, extensions, signature on all the fields. The image below shows an example of a X.509v3 certificate.

Certificate Revocation and CRLs

CAs periodically issue a Certificate Revocation List (CRL). A CRL shows detailed information about revoked certificates, i.e. certificates which should not be trusted. CRLs are made available by CAs for downloading or online viewing by client programs. Possible reasons for revocation include, but are not limited to:

Key Compromise: A person who is not the key subject is suspected to have discovered the private key value.
Change in Affiliation: The certificate subject is no longer employed the organization that issued the certificate.
Superseded: A new certificate has been issued to replace an existing certificate.

To verify a certificate, you need the public key of the CA and must check it against the CRL published by that CA (shown below).

Summary

A Public Key Infrastructure (PKI) consists of:

Users or businesses (Requesters), who need to prove their identity via a Digital Certificate (including their Public Key) to ensure the safety, integrity and authenticity of online transactions. Before a Digital Certificate can be issued to the requester, an application needs to be filed with a Registration Authority (RA).
Registration Authorities (RAs), which verify, approve (or reject) the requesters' submitted proof of identity, before submitting it to a Certificate Authority (CA).
Certificate Authorities (CAs), which process, sign (with their Private Key) and provide the actual Digital Certificate to the requester. Certificate Authorities can be commercial (e.g. VeriSign) or non-commercial entities (e.g. the aXsGUARD Gatekeeper). CAs also revoke Digital Certificates, by publishing them in a Certificate Revocation List (CRL).
Verification Authorities (VAs), which verify the authenticity of submitted Digital Certificates. The authenticity can also be verified directly by the issuing CA, which is mostly the case.

PKI Configuration & Use

Overview

In this section we explain how to use the AXS Guard PKI infrastructure. Topics covered in this section include:

How to initialize the AXS Guard CA.
How to issue and sign certificates.
How to import, export and revoke certificates.
How to view certificate information.
How to configure automated PKI notifications.
How to manage trusted CAs for SSL inspection.
PKI logging.

Initializing the Built-in Certificate Authority

Log on to the AXS Guard appliance.
Navigate to PKI > Built-in CA.
Enter the settings as requested on-screen.
Click on Initialize.

Important

Repeat the steps above if you wish to reinitialize the CA.
Reinitializing the CA voids all the current client certificates!

Exporting the Built-in CA Certificate

To establish a secure connection with a server, that server needs to have a valid SSL certificate and the authority which issued the certificate needs to be trusted by the clients. Usually, certificates used in large production environments are issued by known public root Certificate Authorities, which are trusted by all major operating systems.

However, small environments often use certificates signed by a private CA to reduce costs. To connect to servers that use certificates signed by a private CA, such as the AXS Guard CA, the root CA certificate needs to be exported and manually installed on the clients.

Export CA Button

Issuing Certificates

There are two methods to issue new certificates on the AXS Guard:

Via an AXS Guard service, e.g. the system administration tool or the reverse proxy
Via the Certificate Management tool

Info

Certificates that are issued via a service and the certificate management tool are always self-signed. To add certificates signed by an external CA, proceed to the next section.

To issue a certificate:

Log on to the AXS Guard appliance.
Navigate to PKI > Certificates.
Click on Issue new certificate.
Enter a name and description (optional) for the new certificate.
Select the appropriate certificate use and enter the other parameters.
Enter the duration of the certificate’s validity.
Click on Sign when finished.

Client

Select this certificate type to generate a client certificate for a VPN Client, e.g. an IPsec Road Warrior or OpenVPN client. This option requires you to specify the appropriate username. Go to Users & Groups > Users for an overview of users on your system.

Personal AXS GUARD

Select this option to generate a client certificate for a PAX unit. This option requires you to select the appropriate unit as registered under VPN & RAS > Personal AXS GUARD > Client. See the Personal AXS GUARD How To for additional information.

Server

Select this certificate type to generate a server certificate to be used by any of the services listed below. This type of certificate requires you to specify a hostname.

VPN services: IPsec, L2TP, OpenVPN, PAX.
The MTA (if TLS is used).
The e-mail server (POPS and IMAPS).
The reverse proxy (HTTPS).
The RADIUS server (if EAP is used).
This web-based administration tool (HTTPS).

Importing Certificates and Certificate Chains

Log on to the AXS Guard appliance.
Navigate to PKI > Certificates.
Click on Add new.
Enter the appropriate information.
Save your settings.

PEM certificate files with a chain file
PEM certificate files with a chain file and a separate key file
PKCS12 certificates

Extensions used for PEM certificates are cer, crt, and pem. They are Base64-encoded ASCII files. The DER format is the binary form of the certificate and must be converted with an SSL certificate converter before it can be uploaded.

Important

The certificate chain file is a list of certificates used to verify the authenticity of an entity. The chain, or path, begins with the certificate of that entity, and each certificate in the chain is signed by the entity identified by the next certificate in the chain. The chain terminates with a root CA certificate. The root CA certificate is always signed by the CA itself.

Exporting Certificates

Log in to the AXS Guard appliance.
Navigate to PKI > Certificates.
Click on the appropriate export icon.
Select the appropriate export format and click on the Export button.

Format	Description
PKCS12	Used by PAX units, IPsec Road Warriors and L2TP clients.
OpenVPN Configuration Pack	Used by OpenVPN clients (with private key protection).
OpenVPN Configuration File	Used by OpenVPN clients (without private key protection).
Export Password	A password to protect the certificate. You will need this password to install the certificate on the client.

Revoking Certificates

Log on to the AXS Guard appliance.
Navigate to PKI > Certificates.
Click on the name of the certificate you want to revoke.
Select "Revoke Certificate".
Select the appropriate Revocation reason.
Click on "update".

Action

Select the appropriate action from the drop-down list:

Keep current certificate
Revoke certificate: a reason must be specified.

Revocation Reason

Select the reason for revoking the certificate.

Viewing Certificate Information

Log in to the AXS Guard appliance.
Navigate to PKI > Certificates.
Click on a certificate name to view its details.

Automated Notification Settings

You can configure the AXS Guard PKI to automatically notify the system administrator or any other user when a certificate has expired.

Log on to the AXS Guard appliance.
Navigate to PKI > Notifications.
Select the appropriate option(s).
Update your configuration.

Option	Description
Notify administrator of certificate expiration?	If enabled, the appliance automatically notifies the system administrator(s) by e-mail when a certificate expires. The e-mail addresses of system administrators are listed under System > General.
Specify other e-mail address to send notification?	Also send notifications to the specified e-mail address(es).

Managing Trusted CAs

This feature was implemented to support SSL inspection. See the web access guide for additional information.

Websites that use HTTPS have a certificate that is signed by a certificate authority or CA. Via this page, system administrators can view and manage trusted CA certificates. The CA certificate list is automatically updated, but administrators also have the possibility to import trusted CA certificates which don’t appear in the automated list.

Important

The AXS Guard appliance will only connect to sites which have a certificate issued by a trusted CA. CAs which don’t appear in the list or which are disabled are untrusted by default. To trust a CA certificate, the enabled flag must be checked.

Overview of Trusted CAs

Importing a Trusted CA Certificate

Go to PKI > Trusted CAs.
Click on "Add new".
Upload the CA certificate file.

In the following example, we upload the DigiCert root CA certificate. DigiCert Inc issues certificates for Facebook servers.

Importing a Trusted CA Certificate

The CA certificate now appears in the Trusted CA overview and is enabled (trusted) by default:

Trusted CA Overview

AXS Guard is now able to connect to Facebook:

# wget https://facebook.com
--2019-12-03 11:27:08--  https://facebook.com/
Resolving facebook.com (facebook.com)... 179.60.195.36, 2a03:2880:f121:83:face:b00c:0:25de
Connecting to facebook.com (facebook.com)|179.60.195.36|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.facebook.com/ [following]
--2019-12-03 11:27:08--  https://www.facebook.com/
Resolving www.facebook.com (www.facebook.com)... 179.60.195.36, 2a03:2880:f121:83:face:b00c:0:25de
Connecting to www.facebook.com (www.facebook.com)|179.60.195.36|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://www.facebook.com/unsupportedbrowser [following]
--2019-12-03 11:27:08--  https://www.facebook.com/unsupportedbrowser
Reusing existing connection to www.facebook.com:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]

If we disable the DigiCert CA certificate, AXS Guard will no longer be able to connect to Facebook:

# wget https://facebook.com
--2019-12-03 11:27:22--  https://facebook.com/
Resolving facebook.com (facebook.com)... 179.60.195.36, 2a03:2880:f121:83:face:b00c:0:25de
Connecting to facebook.com (facebook.com)|179.60.195.36|:443... connected.
ERROR: cannot verify facebook.com's certificate, issued by 'CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US':
  Unable to locally verify the issuer's authority.
To connect to facebook.com insecurely, use `--no-check-certificate'.

Deleting a Trusted CA Certificate

Go to PKI > Trusted CAs.
Select the CA certificate to be deleted.
Click on the trash icon.

Important

The AXS Guard appliance will not be able to connect to sites of which the CA certificate has been deleted.

PKI Logs

CAs must be treated as high value systems and be monitored closely for suspicious activity. Some example areas of interest to monitor in the PKI logs are:

Initialization and reinitialization of the AXS Guard CA
Certificate issuance, revocation and removal
The importing and exporting of certificates
Failed certificate renewals

Go to PKI > Logs and click on the desired log file to view PKI events.

PKI Logs

Tip

Use the search function to quickly find specific content in the logs.

Support

If you encounter a problem

If you encounter a problem with AXS Guard, follow the steps below:

Check the troubleshooting section of the feature-specific manual.
Check the knowledge base on this site for information about special configurations.
If no solution is available in any of the above sources, contact your AXS Guard vendor.

Contact Information

(+32) 15-504-400
support@axsguard.com