How To Generate Client Certificates for TLS Clients

When connecting TLS clients to a TLS-enabled server, like a HiveMQ Cloud Starter MQTT broker, client certificates can be used for secure authentication as long as the server is set up to support TLS client authentication. This article explains two methods for generating client certificates and using them with HiveMQ Cloud Starter.

Instructions

Method 1: Self-Signed Client Certificate

A self-signed certificate is created and signed by the client itself instead of by a trusted Certificate Authority (CA). This method is quick and easy, but it limits the server to trusting only the specific client certificate.

Steps:

  1. Generate a new client private key and self-signed certificate:

    openssl req -x509 -newkey rsa:2048 -keyout client0-key.pem -out client0-cert.pem -days 365 -passout pass:changeme -subj /CN=client0
  2. Upload the public client certificate to the HiveMQ Cloud Console:

    • Go to the console.hivemq.cloud (HiveMQ Cloud Console) → Your Starter Cluster → Access ManagementClient Certificate.

    • Upload the client-cert0.pem certificate.

    Important: Wait for the HiveMQ Cloud Cluster to apply the certificate before moving on.

  3. Test the connection:
    Use this command to verify the connection with the server using the client certificate and private key:

    openssl s_client -connect my-server.hivemq.cloud:8883 \ -cert client0-cert.pem \ -key client0-key.pem

Success: "Verification: OK" and "CONNECTED" in the output.

Failure: Error messages like "unable to get local issuer certificate" or "SSL alert unknown ca".


Method 2: Multiple Client Certificates Signed by a Trusted CA

This method involves getting a trusted Certificate Authority (CA) to sign the client certificates. It's ideal when multiple clients need to connect securely to the server, each with a different client certificate, as the server will trust all client certificates signed by the CA.

Steps:

  1. Generate the CA private key and certificate:

    openssl genrsa -out rootCA-key.pem 2048 openssl req -x509 -new -nodes -key rootCA-key.pem -sha256 -days 1024 -out rootCA-cert.pem -subj /CN=my-trusted
  2. Upload the CA certificate to the HiveMQ Cloud Console:

    • Go to the console.hivemq.cloud (HiveMQ Cloud Console) → Your Starter Cluster → Access ManagementClient Certificate.

    • Upload the rootCA-cert.pem certificate.

    Important: Wait for the HiveMQ Cloud Cluster to apply the CA certificate before proceeding.

  3. Generate the private key and CSR (Certificate Signing Request) for client1:

  4. Sign client1’s CSR with the CA certificate:

  5. Repeat the process for client2:

  6. Test the connection end to end:
    To verify the connection using client1’s certificate:

    For client2, use:

    Success: "Verification: OK" and "CONNECTED" in the output.

    Failure: Error messages like "unable to get local issuer certificate" or "SSL alert unknown ca".


Method 3: Multiple Client Certificates Signed by an Intermediate CA

This method introduces an Intermediate CA between the trusted root CA and client certificates. The Intermediate CA signs the client certificates, while the root CA signs the Intermediate CA certificate. This setup allows the separation of concerns.


Steps:

  1. Generate the Root CA Private Key and Certificate:

  2. Generate the Intermediate CA Private Key and CSR:

  3. Sign the Intermediate CA Certificate with the Root CA:

  4. Upload the Intermediate CA Certificate to HiveMQ Cloud:

    • Go to HiveMQ Cloud Console → Your Starter Cluster → Access ManagementClient Certificate.

    • Upload intermediateCA-cert.pem.

Important: Wait for the HiveMQ Cloud Cluster to process the uploaded certificate before proceeding.

  1. Generate Client Private Keys and CSRs:

    • For client3, generate a private key and CSR:

    • For client4, generate a private key and CSR:

  2. Sign Client Certificates with the Intermediate CA:

    • Sign client3's CSR:

    • Sign client4's CSR:

  3. Test Connections Using Client Certificates:

    • Test the connection for client3:

    • Test the connection for client4:

      Success: "Verification: OK" and "CONNECTED" in the output.

      Failure: Error messages like "unable to get local issuer certificate" or "SSL alert unknown ca".


Comparison of Methods

 

Method 1: Self-Signed Certificate

Method 2: Signed by Trusted CA

Method 3: Intermediate CA

 

Method 1: Self-Signed Certificate

Method 2: Signed by Trusted CA

Method 3: Intermediate CA

Use Case

The server trusts only one client certificate.

The server trusts multiple client certificates signed by one CA.

The server trusts multiple client certificates signed by one CA.

Trust Mechanism

Trust configuration for one client certificate.

Automatic trust for all client certificates signed by the same CA.

Automatic trust for all client certificates signed by the same Intermediate CA.

Scalability

Not suitable for multiple client certificates.

Suitable for multiple client certificates.

Suitable for multiple client certificates.

Certificate to Upload

Upload the client certificate (client-cert.pem).

Upload the CA certificate (rootCA-cert.pem).

Intermediate CA cert (intermediateCA-cert.pem).


Conclusion

  • Method 1 (Self-Signed Certificate): This method works well when only one client certificate is required. It's simple but not ideal for use case with multiple clients.

  • Method 2 (Signed by Trusted CA): This method is better for use case with multiple client certificates, as it allows the server to trust all certificates signed by the same CA.

  • Method 3 (Signed by Intermediate CA): This method is better for use case with multiple client certificates, as it allows the server to trust all certificates signed by the same Intermediate CA.