Two-way SSL Authentication for REST

In this tutorial, we will set up two-way SSL authentication for REST in the PubSub+ event broker using self-signed certificates. As we guide you through the steps, we will show you how to generate self-signed certificates, configure the certificates in the event broker instance, and validate the SSL communication.

Overview

One-way SSL / Server Certificate Authentication

In one-way SSL authentication (Server Certificate Authentication), only the client validates the server; the server does not verify the client application. When implementing one-way SSL authentication, the server application shares its public certificate with the client.

Two-way SSL/ Client Authentication

In two-way SSL authentication, the client application verifies the identity of the server application, and then the server application verifies the identity of the client application. Both parties share their public certificates, and then validation is performed. Two-way SSL authentication works with a mutual handshake by exchanging the certificates. You can also authenticate through a username or Common Name injection.

Prerequisites

Install OpenSSL to generate self-signed certificates.
Install Postman to test client authentication.
Create FTP user through the Solace CLI to transfer files.
Create a client username in the event broker which will be assigned as a common name (CN) to the client key file

Assumptions

Admin access to configure certificates in the PubSub+ event broker
Possess working knowledge of the Solace CLI.

Configuring Two-Way SSL Authentication for REST

To configure a two-way SSL authentication, we will generate self-signed certificates using OpenSSL, configure the certificates in the event broker instance, and validate client authentication using Postman.

Step 1: Generate SSL server certificate

You can generate a self-signed certificate using the methods described below or get one from your organization's certificate authority.

To generate a self-signed SSL server certificate, perform the following steps:

Create TLS key for the event broker:
```
openssl genrsa -des3 -out root.key 4096
```
Enter the pass phrase in the prompt.

Create a server certificate and generate a signing request:

openssl req -new -x509 -days 1000 -key root.key -out server.pem -subj "/C=/ST=/L=/O=/OU=/CN=root"

Create a pem file by concatenating the private key and server certificate:
```
cat root.key > server_cert.pem
cat server.pem >> server_cert.pem
```
Place the certificate in the /usr/sw/jail/certsdirectory using the “SCP” service:
```
scp -P2222 /home/<username>/server_cert.pem <Solace FTP User>@<Host>:/certs/
```
Ensure to create the FTP user through the Solace CLI.

Step 2: Enable SSL on the event broker

To enable SSL for REST on the event broker, do the following:

Log into the Solace CLI.

Enable SSL for the Message VPN:

solace(configure)# message-vpn <vpn-name>
solace(configure/message-vpn)# service rest
solace(configure/message-vpn/service/rest)# incoming
solace(...ure/message-vpn/service/rest/incoming)# listen-port 9443 ssl
solace(...ure/message-vpn/service/rest/incoming)# no ssl shutdown

You can also enable SSL using PubSub+ Broker Manager.

Set the server certificate that you created in Step 1 for the event broker to use:
```
solace(configure)# ssl
solace(configure/ssl)# server-certificate <filename>
```
Where:
<filename> is the filename of the certificate. This file must be located in the /usr/sw/jail/certs directory on the event broker. In this case, server_cert.pem is the filename of the certificate.
For more information about using server certificates, see Setting Server Certificates To Use.

Step 3: Verify REST over SSL

Access the URL with https and SSL port:
```
https://<host>:<9443>/
```
Verify that the configured certificates are loaded in the browser.

Step 4: Generate client-specific certificates

In this step, we will generate client key and client pem files based on the root key and server certificates.

Create client key and csr file:

openssl req -nodes -new -newkey rsa:4096 -keyout client.key -out client.csr -subj "/C=/ST=/L=/O=/OU=/CN=Client_User"

In the above script, Client_User is a Solace client username.

Generate the client pem file and signing request for REST Client:
```
openssl x509 -req -in client.csr -CA server.pem -CAkey root.key -CAcreateserial -out client.pem -days 1825 -sha256
```
The root.key and server.pem files were generated in Step 1: Generate SSL server certificate.

Create the server certificate pem file:

cat root.key > server_cert.pem
cat server.pem >> server_cert.pem

Step 5: Configure the CAs in the event broker

We will now configure the CAs and enable client certificate authentication for the given Message VPN.

Create a certificate authority (CA) and assign the certificate created in the previous step:
```
solace> enable
solace# configure
solace(configure)# authentication
solace(configure/authentication)# create certificate-authority <ca-name>
solace(.../authentication/certificate-authority)# certificate file <ca-certificate>
```
Where:
<ca-name> is the name of the CA. You can use a maximum of 64 characters for a ca-name. Acceptable characters are alpha-numeric characters, period (.), hyphen (-), and under score (_).
<ca-certificate>is the filename of the CA certificate. This file must be located in the /usr/sw/jail/certs directory on the event broker. In this case, server.pem is the CA certificate.
Take a look at Configuring the Client Authentication Certificate Authorities List for additional configuration and event broker's version-specific information.

Assign a username source for the Message VPN:

solace(configure)# message-vpn <vpn-name>
solace(configure/message-vpn)# authentication
solace(configure/message-vpn/authentication)# client-certificate
solace(...vpn/authentication/client-certificate)# username-source common-name
solace(...vpn/authentication/client-certificate)# no shutdown

In this case, Client_User is the common name that we will use for authentication.

For more information on username source, see Client Client Username Sources.

Step 6: Validate client authentication

Finally, we will perform client authentication using Postman. (Version 7.14).

Open Postman, navigate to Preference and click on Certificate to add the client certificates
As shown in the example below, provide the host, port, client.pem and client.key file.
You can now validate client authentication on the browser (https://<host>:9443/TOPIC/test) with No Auth configuration. You should be able to post the message without credentials with 200 OK response.
Optionally, you can also perform negative validation by disabling the <Client_User> and posting the message. It should fail with the “Client Username Is Shutdown” error message in Postman.
Ensure the default user is disabled.

Provide feedback