Mutual authentication, also known as two-way authentication, is a security process in which entities authenticate each other before actual communication occurs. In a network environment, this requires that both the client and the server must provide digital certificates to prove their identities. In a mutual authentication process, a connection can occur only if the client and the server exchange, verify, and trust each other's certificates. The certificate exchange occurs by means of the Transport Layer Security (TLS) protocol. The core of this process is to make sure that clients communicate with legitimate servers, and servers cooperate only with clients who attempt access for legitimate purposes.
The mutual authentication process involves the following certificates:
-
Root CA certificate
Used to identify a certificate authority (CA) that signed a client's certificate. It is a self-signed certificate that meets the X.509 standard, defining the format of public key certificates. In IoT products, clients upload a root CA certificate or a certificate chain to verify that the certificates that client devices send to edge servers can be trusted. See Upload the Mutual Authentication root certificate. -
Server SSL certificate
Used to identify edge servers to client devices over TLS and to establish a secure connection during the TLS handshake. It is the enhanced TLS certificate that you provide in your property configuration. See Associate a property hostname to an edge hostname. -
Client SSL certificate
Used to identify client devices to edge servers over TLS. This certificate must meet the X.509 standard, defining the format of public key certificates.
The process of authenticating and establishing an encrypted channel using certificate-based mutual authentication involves the following steps:
-
During configuration, administrators provide a root CA certificate or a certificate chain used to sign certificates on client devices. They can do it in Certificate Provisioning System (CPS). See Upload the Mutual Authentication root certificate.
-
The OTA Updates application deploys the certificate chain to the Akamai Platform.
-
Once the signing CA certificates propagate across the Akamai Platform, client device can connect by using MQTT, HTTP, or WebSocket protocols and request access to a topic.
-
The edge server presents its certificate to the client device.
-
The client device checks its list of trusted CAs and verifies the server's certificate.
-
If successful, the client device sends its certificate to the edge server.
-
The edge server checks its list of CAs and verifies the client device's certificate.
-
If successful, a secure connection between the server and the client device is established.
How to verify a certificate chain
To pass certificate verification on edge servers, clients need to provide the root CA certificate or the root and intermediate certificates that signed the certificate that client devices use to identify themselves. The certificate authority and intermediate certificates, known as a certificate chain, is a list of certificates issued by successive certificate authorities (CAs) that enables edge servers to verify that the client and all CAs are trustworthy.
In the figure, you can see a certificate chain that leads from a certificate that identifies a client through two intermediary CA certificates to the CA certificate for the root CA. In the figure, you can see a certificate chain that leads from a certificate that identifies a client through two intermediary CA certificates to the CA certificate for the root CA.
A certificate chain follows a path of certificates in the hierarchy up to the root CA certificate. In a certificate chain, each certificate must meet the following conditions:
-
Each certificate is followed by the certificate of its issuer.
-
Each certificate contains the name (DN) of that certificate's issuer, which is the same as the subject name of the next certificate in the chain.
-
Each certificate is signed with the private key of its issuer. The signature can be verified with the public key in the issuer's certificate, which is the next certificate in the chain.
System requirements
To configure mutual authentication properly and follow the procedures in this section, see the requirements for operating system and OpenSSL versions.
Mutual authentication certificates in this guide have been created with the OpenSSL versions and on the operating systems indicated in the table. However, you can try their higher versions or other distributions.
Requirements for macOS, Linux, and Windows
Requirement | macOS | Linux | Windows |
---|---|---|---|
Operating system version | Mac OS X 10.15+ | Ubuntu 18.04.3 LTS+ | Windows 10+ |
OpenSSL version | LibreSSL 2.8.3+ | OpenSSL 1.1.1+ | OpenSSL v1.1.1g |
Create a Mutual Authentication root certificate
To properly configure Mutual Authentication, you need to create a root certificate that you want to use to create and validate client certificates.
Before you begin
-
Make sure your environment meets the minimum requirements to complete this procedure. See System requirements.
-
Prepare a CA root certificate configuration file.
An example of content in a root.conf file
[req] default_bits = 2048 prompt = no default_md = sha256 req_extensions = req_ext x509_extensions= v3_ca # subject distinguished name distinguished_name = dn [dn] # country C = US # state ST = Massachusetts # city L = Cambridge # organization O = Organization # organization unit OU = IoT # email emailAddress = test@email.com # common name CN = www.organization.test.com [req_ext] # subject alternative name subjectAltName = @alt_names # netscape comment nsComment = "This is netscape comment" [ v3_ca ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always basicConstraints = CA:true [alt_names] DNS.1 = test.example.com
All the files used in the task are in the same directory. The commands use these variables for the file names:
-
root.conf
is the configuration file for the CA root certificate. -
rootCA.crt
is the CA root certificate you previously created. -
rootCA.key
is the CA root private key that you previously created.
How to
-
Create a certificate key for your domain.
You can use the following command:
openssl genrsa -des3 -out rootCA.key 4096
.A
rootCA.key
appears in your current directory. -
Using your CA root certificate key and the CA root configuration file, generate the CA root certificate.
Make sure to set the
basicConstraints
value in theroot.conf
file toCA:true
. This value indicates whether a certificate is a CA certificate.You can use the following command:
openssl req -x509 -config root.conf -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt
.A
rootCA.crt
file appears in your current directory.
Upload the Mutual Authentication root certificate
In mutual authentication, the edge server asks the client device to present a valid certificate before a secure connection is established and the service of the server accessed. To verify the certificate that the device uses to identify itself, you need to provide edge servers with a root CA certificate or a certificate chain that signed the device's certificate.
To start verifying devices' certificates, you can upload a root CA
certificate or a certificate chain in the Certificate Provisioning
System (CPS). You can only upload one file that is a X.509 certificate in PEM
format. A PEM certificate is a base64 encoded DER
file that contains ----BEGIN CERTIFICATE-----
and -----END CERTIFICATE-----
statements. If your CA provides you with a certificate that is not in PEM
format, you can convert it to PEM
format using an SSL converter.
Before you begin, use Trust Chain Manager to create a certificate set. Follow Trust Chain Manager.
-
Go to ☰ > CDN > Certificates.
-
Select the certificate that you want to use for Mutual Authentication.
-
From the certificate's Actions menu, select View and Edit Deployment Settings.
-
In the Mutual Authentication section, click Edit.
-
From the Certificate set menu, select a certificate set.
-
Click Submit.
Your certificate redeploys to the Akamai network with the new settings.
Comments
Post a Comment
https://gengwg.blogspot.com/