Tag Archives: Linux

AI, GPU, Linux, LLMs, Tools

AI Image Generation on RX 580 Using Vulkan: A Cost-Effective Solution

This guide explores how to leverage the AMD Radeon RX 580 graphics card for AI image generation using Vulkan compute capabilities, without requiring the ROCm software stack. By utilizing stable-diffusion.cpp compiled with Vulkan support, users can take advantage of their existing hardware to run modern AI image generation models.

The approach focuses on maximizing the capabilities of older but still capable hardware, specifically targeting the 8GB VRAM of the RX 580 for efficient model execution. This method provides a cost-effective alternative to more expensive GPU options while maintaining reasonable performance for image generation tasks.

Prerequisites and Vulkan Setup

Before beginning the AI image generation setup, it is essential to have Vulkan properly installed and configured on the system. The installation process for Vulkan can be found in our related guide: Running Large Language Models on Cheap Old RX 580 GPUs with llama.cpp and Vulkan.

This prerequisite ensures that the system has the necessary graphics runtime and compute capabilities required for the Vulkan-based AI image generation framework. The Vulkan API provides a cross-platform solution for leveraging GPU compute resources, making it ideal for running AI workloads on AMD hardware.

Installing stable-diffusion.cpp with Vulkan Support

The core of this setup involves compiling and installing stable-diffusion.cpp with Vulkan support enabled. This specialized version of the stable diffusion framework is designed to utilize Vulkan compute capabilities for image generation tasks.

The installation begins by cloning the repository from GitHub, which includes all necessary submodules and dependencies:

git clone --recursive https://github.com/leejet/stable-diffusion.cpp

After cloning, navigate into the project directory and create a build directory to maintain clean separation between source and compiled files:

cd stable-diffusion.cpp
mkdir build && cd build

The compilation process requires enabling Vulkan support through CMake configuration. This step is crucial for ensuring that the application can utilize the GPU compute capabilities:

cmake .. -DSD_VULKAN=ON

Following the CMake configuration, build the project in Release mode to optimize performance:

cmake --build . --config Release

This compilation process generates the necessary executables and libraries required for running AI image generation tasks with Vulkan acceleration.

Model Preparation and Hardware Considerations

To run AI image generation on the RX 580, users must download appropriate model files in GGUF format. These models are specifically designed for efficient execution on hardware with limited VRAM. The process requires careful consideration of memory constraints, as each instance will operate on a single GPU with no ability to combine VRAM from multiple GPUs.

The 8GB VRAM of the RX 580 limits the size of models that can be fully loaded into memory. Some components of the generation process must be offloaded to the CPU, which affects overall performance but allows for operation within hardware constraints.

Model files typically include diffusion models, VAE components, CLIP encoders, and T5XXL text encoders in safetensors format. These files must be organized in a directory structure that the application can access during execution.

Sample Usage Commands

Once the system is properly configured with stable-diffusion.cpp compiled with Vulkan support, users can begin generating images using various command-line options. The following examples demonstrate different approaches to image generation with varying model configurations:

sd --diffusion-model  SD-Models/flux1-schnell-q4_0.gguf --vae SD-Models/ae.safetensors --clip_l SD-Models/clip_l.safetensors --t5xxl SD-Models/t5xxl_fp16.safetensors  -p "a lovely beagle holding a sign says 'hello'" --cfg-scale 1.0 --sampling-method euler -v --steps 4 --clip-on-cpu

This command demonstrates basic image generation with the flux1-schnell model, using CPU offloading for CLIP processing to accommodate memory limitations.

sd --diffusion-model  SD-Models/flux1-dev-q4_0.gguf --vae SD-Models/ae.safetensors --clip_l SD-Models/clip_l.safetensors --t5xxl SD-Models/t5xxl_fp16.safetensors  -p "a lovely beagle holding a sign says 'hello'" --cfg-scale 1.0 --sampling-method euler -v --steps 4 --clip-on-cpu

This example uses the flux1-dev model, which may offer different quality characteristics compared to the schnell variant.

For users interested in enhanced realism or artistic styles, LoRA (Low-Rank Adaptation) models can be incorporated:

sd --diffusion-model  SD-Models/flux1-dev-q4_0.gguf --vae SD-Models/ae.safetensors --clip_l SD-Models/clip_l.safetensors --t5xxl SD-Models/t5xxl_fp16.safetensors  -p "a lovely beagle holding a sign says 'flux.cpp'<lora:realism_lora_comfy_converted:1>" --cfg-scale 1.0 --sampling-method euler -v --lora-model-dir SD-Models --clip-on-cpu

This command demonstrates the integration of LoRA models for enhanced image generation quality and style control.

The final example combines both the flux1-schnell model with LoRA support:

sd --diffusion-model  SD-Models/flux1-schnell-q4_0.gguf --vae SD-Models/ae.safetensors --clip_l SD-Models/clip_l.safetensors --t5xxl SD-Models/t5xxl_fp16.safetensors  -p "a lovely beagle holding a sign says 'flux.cpp'<lora:realism_lora_comfy_converted:1>" --cfg-scale 1.0 --sampling-method euler -v --lora-model-dir SD-Models --clip-on-cpu

These commands illustrate the flexibility of the stable-diffusion.cpp framework in supporting various model configurations and enhancement techniques while working within the constraints of the RX 580’s hardware specifications.

Performance Considerations

The performance of AI image generation on the RX 580 with Vulkan support will vary based on several factors including model size, generation parameters, and system configuration. The 8GB VRAM limitation means that larger models may require additional CPU offloading or reduced resolution settings to function effectively.

You should expect longer generation times compared to systems with more powerful GPUs, but the approach provides a viable solution for those working with older hardware. The Vulkan implementation helps optimize compute operations and can provide better performance than traditional CPU-based approaches while utilizing the GPU’s parallel processing capabilities.

With these steps completed, you can successfully run AI image generation on their RX 580 graphics card using Vulkan compute capabilities. This setup provides an accessible pathway for leveraging existing hardware investments for modern AI applications without requiring expensive upgrades or specialized software stacks like ROCm.

How-tos, Linux, Tools

Running Supabase in a Proxmox Docker VM: A Step-by-Step Guide

Supabase and Proxmox

In today’s rapidly evolving tech landscape, developers often need flexible and scalable solutions for hosting applications — especially when looking to self-host services like Supabase. One powerful approach is to deploy Supabase using a Proxmox VE Docker VM. This setup not only offers flexibility and isolation but also allows for easy updates and maintenance.

Why Use Proxmox VE?

Proxmox VE stands out as a free and open-source virtualization platform that supports both KVM and LXC containers. What makes it particularly appealing for developers is its ability to manage virtual machines (VMs) with full OS support, unlike some containerized alternatives.

Furthermore, Proxmox allows for Docker in a VM, which means you get the best of both worlds: the isolation and management of a VM with the lightweight efficiency of Docker containers. Since Docker in LXC containers isn’t as straightforward to maintain, deploying Docker within a Proxmox VM is the recommended way to go.

Deploying a Docker VM in Proxmox

To simplify the process, the community-scripts project provides a convenient script to create a Docker-ready VM. You can find detailed documentation at https://community-scripts.github.io/ProxmoxVE/scripts?id=docker-vm.

Here’s how to get started:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/vm/docker-vm.sh)"

This script will set up a Docker-enabled VM in Proxmox, complete with the necessary tools and configurations. Once deployed, you can access the VM via SSH or console, using the default login:

  • Username: root
  • Password: docker

Of course, you should change the default password immediately to ensure security.

🔐 Security Tip: Always update default credentials right after deployment to prevent unauthorized access.

Installing Supabase in Your Docker VM

Now that you have your Docker VM running, it’s time to install Supabase — an open-source Firebase alternative that provides real-time databases, authentication, and more. For detailed installation instructions, refer to the official Supabase documentation: https://supabase.com/docs/guides/self-hosting/docker

Step-by-Step Installation

First, you need to clone the Supabase repository and set up your project directory:

git clone --depth 1 https://github.com/supabase/supabase
mkdir supabase-project

Your folder structure should now look like this:

.
├── supabase
└── supabase-project

Next, copy the necessary Docker Compose files and environment variables:

cp -rf supabase/docker/* supabase-project
cp supabase/docker/.env.example supabase-project/.env

Now, switch to your project directory and pull the latest images:

cd supabase-project
docker compose pull

Then, start all the services in detached mode:

docker compose up -d

You can verify that all services are running correctly with:

docker compose ps

If any service is not running, try starting it manually:

docker compose start <service-name>

Accessing Supabase Studio

Once everything is up and running, you can access Supabase Studio — the admin UI for managing your Supabase project — through the API gateway on port 8000.

For example, if your VM’s IP address is 192.168.1.100, you would visit:

http://192.168.1.100:8000

By default, the login credentials are:

  • Username: supabase
  • Password: this_password_is_insecure_and_should_be_updated

As mentioned earlier, it’s critical to update the default password immediately for security reasons.

Why Choose This Approach?

Using Proxmox VE to host Supabase offers several advantages:

  • Full OS support: Unlike containers, VMs allow for full control over the guest OS.
  • Easy updates: VMs can be upgraded independently, making them more manageable than LXC containers.
  • Isolation: Each VM functions as a separate unit, improving stability and security.
  • Scalability: You can easily scale resources or replicate your setup for development and production.

Conclusion

Deploying Supabase in a Proxmox VE Docker VM is an efficient and secure way to self-host your Supabase infrastructure. It leverages the strengths of both virtualization and containerization, offering scalability and maintenance benefits.

Whether you’re a developer looking to host a custom backend or a team managing multiple projects, this setup provides an excellent foundation.

How-tos, Linux

Automatically connect to Private Internet Access VPN using OpenVPN client on Raspbian Stretch

Introduction

A Virtual Private Network establishes a secure encrypted connection between your system and a server. It allows you to connect to an untrusted network and tunnel all your network traffic so that it emerges from the VPN server to its destination. In this howto, we will configure the OpenVPN client to connect to the VPN servers hosted by Private Internet Access.

I’ve chosen to use Private Internet Access only because I already have an account with them and they support the OpenVPN client to connect to their VPN servers. I’m sure other VPN service providers would work the same way.

Although I initially tested this on Raspbian Stretch on a Raspberry Pi, I have since used the same steps on Debian Stretch and achieved the same results.

Installing all the prerequisites

To accomplish this task we are going to need to install openvpn, unzip, wget, curl and openresolv. We can do this by using the following command:


apt -y install openvpn unzip wget curl openresolv

Setting up the directory structure

Just to keep things organized we will create a set of directories. This will help if we ever need to alter the configuration by only requiring the change of a couple of linked files. First we need to switch to “/etc/openvpn/client directory”.

cd /etc/openvpn/client

Once there we create several directories by issuing the following commands:

mkdir certs-available
mkdir confs-available
mkdir login-available
mkdir certs-enabled
mkdir login-enabled
mkdir vpn-bundles

Setting up all the configurations

Private Internet Access (as well as other VPN providers) provide configuration bundles for the OpenVPN default client. We are going to download those configurations, alter them a bit and use them to connect to the PIA VPN server as soon as our system finishes booting up.

Switch to the directory we created to store the configuration bundle by issuing the following command:

cd /etc/openvpn/client/vpn-bundles

Once in /etc/openvpn/client/vpn-bundles we can proceed to download the configuration bundle with wget by issuing the following:

wget https://www.privateinternetaccess.com/openvpn/openvpn.zip

Now that we have the zipped file with all the configurations we need to unzip it by using the following command: 

unzip openvpn.zip -d "$(date +"%d-%m-%Y")"-PIA-openvpn

This command will unzip the openvpn.zip file into a directory whose name starts with the date followed by “-PIA-openvpn”. We are doing this so that in the future if there is a need to download a new set of configurations we can easily tell which directory contains the newly downloaded ones.

Once the file is unzipped we can start moving the configurations to the directories we previously created.

cd "$(date +"%d-%m-%Y")"-PIA-openvpn
mkdir /etc/openvpn/client/certs-available/PIA
cp *.crt /etc/openvpn/client/certs-available/PIA/
cp *.pem /etc/openvpn/client/certs-available/PIA/
mkdir /etc/openvpn/client/confs-available/PIA
cp *.ovpn /etc/openvpn/client/confs-available/PIA/

Because we want the OpenVPN client to start without user interaction, we need to add a couple of settings to all VPN configuration files we just downloaded. Change to the directory where we stored them by issuing the following command:

cd /etc/openvpn/client/confs-available/PIA

We need to alter all the configuration files so that they can get the user name and password from a file named “login” located at “/etc/openvpn/client/login-enabled/”. This can be accomplished by issuing the following command:

sed -i 's/auth-user-pass/auth-user-pass \/etc\/openvpn\/client\/login-enabled\/login/g' *.ovpn

We also need to add the following settings to all the configuration files. These settings deal with changing the DNS servers in order to prevent DNS leaks when the VPN is up.

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
down-pre

Going into each file to add the aforementioned settings would be too tedious, it is better to use a small script that goes into each file and adds the settings. The script is simple, just create a file named add_vpn_settings.sh with the following content:

#/bin/bash
cd /etc/openvpn/client/confs-available/PIA
for file in *
 do 
     echo "script-security 2" >> "$file"
     echo "up /etc/openvpn/update-resolv-conf" >> "$file"
     echo "down /etc/openvpn/update-resolv-conf" >> "$file"
     echo "down-pre" >> "$file"
 done

Next step is to make executable by issuing the following:

chmod +x add_vpn_settings.sh

And finally we run the add_vpn_settings.sh script by issuing:

./add_vpn_settings.sh

Now we need to backup the original update-resolv-conf file, this is because we are going to use a replacement that is better able to update the DNS servers in /etc/resolv.conf when they are pushed in by the VPN server. We can do this be issuing the following commands:

cd /etc/openvpn
mv update-resolv-conf update-resolv-conf-ORIG

If we ever need to return to the default script we just rename “update-resolv-conf-ORIG” back to “update-resolv-conf “.

Next we need to download the replacement update-resolv-conf file from https://github.com/masterkorp/openvpn-update-resolv-conf. We can issue the following commands to accomplish this:

cd /etc/openvpn
wget https://github.com/masterkorp/openvpn-update-resolv-conf/raw/master/update-resolv-conf.sh

Now we rename it and make it executable:

mv update-resolv-conf.sh update-resolv-conf
chown root:root update-resolv-conf
chmod 555 update-resolv-conf

Next we need to create a the file that contains the actual username and password for the PIA VPN server. Issuing the following three commands should do the job:

cd /etc/openvpn/client/login-available
echo "YOUR_PIA_USERNAME" > PIA-Login
echo "YOUR_PIA_PASSWORD" >> PIA-Login

Now we create a link from /etc/openvpn/client/login-available to /etc/openvpn/client/login-enabled/login by issuing the following:

ln -s /etc/openvpn/client/login-available/PIA-Login /etc/openvpn/client/login-enabled/login

Finally we link one of the configurations available to be the default one (I’ve used the UK London configuration as an example below, you can use whichever configuration you desire).

ln -s /etc/openvpn/client/confs-available/PIA/UK\ London.ovpn /etc/openvpn/default.conf

After a reboot, the openvpn client should be up and everything should be flowing through the vpn tunnel.

How-tos, Linux

Setting up a mining system with xmr-stak built from source and Ubuntu 16.04

If using an Nvidia GPU, install the Nvidia CUDA toolkit:

Download installer type “deb(network)” from:

https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&target_distro=Ubuntu&target_version=1604

To install issue the following commands:

$ sudo dpkg -i cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
$ sudo apt-key adv --fetch-keys http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub
$ sudo apt-get update
$ sudo apt-get install cuda

Editing the enviroment to include the CUDA path:

$ sudo nano /etc/environment

Find the PATH variable and include the /usr/local/cuda-9.1/bin folder at the end of the string.

Save the file and reboot.

If using and AMG GPU, install AMD APP SDK 3.0:

Download and install the latest version from:

http://developer.amd.com/amd-accelerated-parallel-processing-app-sdk/

Untar the SDK to a location of your choice.

Decompress the file wit the following command:

$ tar -xvjf AMD-APP-SDKInstaller-v<3.0.x.y>-GA-linux64.tar.bz2

Run the installer:

$ sudo ./AMD-APP-SDKInstaller-v<3.0.x.y>-GA-linux64.sh

To fix libOpenCL issue:

$ cd $AMDAPPSDKROOT/lib/x86_64
$ sudo ln -sf sdk/libOpenCL.so.1 libOpenCL.so

then logout and login again.

Installing amdgpu-pro

Download the latest package from:
https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx

Decompress the file wit the following command:

$ tar -xJvf amdgpu-pro-17.40-492261.tar.xz
$ cd amdgpu-pro-17.40-492261
$ sudo ./amd-pro-install -y

Reference:
https://linuxconfig.org/install-amdgpu-pro-16-50-on-ubuntu-16-04-xenial-xerus-linux

Building xmr-stak from source

Install all dependencies:

$ sudo apt install git libmicrohttpd-dev libssl-dev cmake build-essential libhwloc-dev

Create a directory for the source files and clone the source:

$ mkdir GIT-sources
$ cd GIT-sources
$ git clone https://github.com/fireice-uk/xmr-stak.git

Create a build directory:

$ mkdir xmr-stak/build
$ cd xmr-stak/build

Configuring and building xmr-stak

If building xmr-stak for CPU only mining and without http server support, use the following cmake flags:

$ cmake .. -DCUDA_ENABLE=FALSE -DOpenCL_ENABLE=FALSE -DMICROHTTPD_ENABLE=FALSE

If building xmr-stak for AMD GPU mining and CPU mining, use the following cmake flags:

$ cmake .. -DCUDA_ENABLE=FALSE

If building xmr-stak for Nvidia GPU and CPU mining, use the following cmake flags:

$ cmake .. -DOpenCL_ENABLE=FALSE

If building for all (AMD GPU, Nvidia GPU and CPU mining)

$ cmake ..

After cmake finishes, execute the following to build:

$ make -j4 install

Final system configurations

If using GPU mining (Nvidia GPU or AMD GPU), ensure the user you will use to mine is part of the video group in /etc/group

$ sudo usermod -a -G video $LOGNAME

Enabling Large Page Support for AMDGPU-PRO

Edit /etc/default/grub and add GRUB_CMDLINE_LINUX=”amdgpu.vm_fragment_size=9″

After editing ggrub, do:
$ sudo update-grub
$ sudo reboot

Configuring Large Page Support for Operating system (applies to all GPUs and CPUs)

Create a file named 98-HugePages-miner.conf in /etc/sysctl.d with the following content:

############################
vm.nr_hugepages=128
############################

Add the following lines to /etc/security/limits.conf (where “miner” is the name of your mining account):

############################
miner soft memlock 262144
miner hard memlock 262144
############################

Then reboot with:

$ reboot

You will find the xmr-stak binary in ~/GIT-sources/xmr-stak/build/bin. Run xmr-stak and follow the prompts to begin mining.

How-tos, Linux

Building a Root CA and an Intermediate CA using OpenSSL and Debian Stretch

A bit of background

A Root Certificate Authority is used to issue digital certificates to servers, clients or users.  It generates digital certificates that certify the ownership of a public key, allowing others to trust the certificate.

An Intermediate Certificate is a subordinate certificate issued by a Root certificate authority for the purpose of issuing certificates.  This creates a certificate chain that begins in the Root CA, through the intermediate and ending in the issued certificate.  This establishes a chain of trust that can verify the validity of a certificate.

In this post, we will step through the process of creating a Root CA, then an Intermediate CA and finally sign digital certificates for a server. A bit of warning, this setup should be sufficient for a homelab or a small local setup; you should not use this as a production service.

Prepare to build

Install Debian Stretch, the minimum should suffice.  There is no need any GUI.  Install SSH for ease of administration and to transfer you certificates securely out.

Make sure that the Fully Qualified Domain Name of the computer is set  correctly.

Make sure your time zone is correctly set.

Make sure the time and date are correctly set.

If you wish you can install ntp to ensure time is always correct.

# apt install ntp

Download the following configuration files:

openssl_root.cnf

openssl_intermediate.cnf

openssl_csr_san.cnf

After download rename all of them by dropping the “.txt” extension.

Creating the Root CA

Create the directory structure for the Root CA:

# mkdir /root/ca
# cd /root/ca
# mkdir newcerts certs crl private requests

While at /root/ca we should also create “index.txt” file for OpenSSL to keep track of all signed certificates and the “serial” file to give the start point for each signed certificate’s serial number. This can be accomplished by doing the following:

# cd /root/ca
# touch index.txt
# touch index.txt.attr
# echo '1000' > serial

Copy openssl_root.cnf to /root/ca, edit it and look for the following entries:

# The root key and root certificate.
private_key = $dir/private/ca.DOMAINNAME.key.pem
certificate = $dir/certs/ca.DOMAINNAME.cert.pem

# For certificate revocation lists.
crlnumber = $dir/crlnumber
crl = $dir/crl/ca.DOMAINNAME.crl.pem
crl_extensions = crl_ext
default_crl_days = 30

Change DOMAINNAME to something that matches the domain of your network, this isn’t strictly necessary but it makes for a more customized naming convention.

Generate the Root private key

(change DOMAINNAME to match what you used in the openssl_root.cnf):

# cd /root/ca
# openssl genrsa -aes256 -out private/ca.DOMAINNAME.key.pem 4096

Signing the Root Certificate

Use the root private key to sign the root certificate.
(change DOMAINNAME to match what you used in the openssl_root.cnf):

# openssl req -config openssl_root.cnf -new -x509 -sha512 -extensions v3_ca -key /root/ca/private/ca.DOMAINNAME.key.pem -out /root/ca/certs/ca.DOMAINNAME.crt.pem -days 3650 -set_serial 0

Ensure that when filling out the “Common Name” variable that you use the CA server + Domain name of the network

Creating an Intermediate Certificate Authority

Create a directory to separate the intermediary files from our root configuration

# mkdir /root/ca/intermediate

Also all the directories and files needed to support (similar to the ones we created for the Root CA):

# cd /root/ca/intermediate
# mkdir certs newcerts crl csr private
# touch index.txt
# touch index.txt.attr
# echo 1000 > /root/ca/intermediate/crlnumber
# echo '1234' > serial

Copy  openssl_intermediate.cnf to /root/ca/intermediate, edit it and look for the following entries:

# The root key and root certificate.
private_key = $dir/private/int.DOMAINNAME.key.pem
certificate = $dir/certs/int.DOMAINNAME.crt.pem

# For certificate revocation lists.
crlnumber = $dir/crlnumber
crl = $dir/crl/int.DOMAINNAME.crl.pem
crl_extensions = crl_ext
default_crl_days = 30

Change DOMAINNAME to the same thing that you used in openssl_root.cnf

Creating the private key and certificate signing request for the Intermediate CA

(change DOMAINNAME to the value you’ve been using so far)

# cd /root/ca
# openssl req -config /root/ca/intermediate/openssl_intermediate.cnf -new -newkey rsa:4096 -keyout /root/ca/intermediate/private/int.DOMAINNAME.key.pem -out /root/ca/intermediate/csr/int.DOMAINNAME.csr

Creating the intermediate certificate

(change DOMAINNAME to the value you’ve been using so far)

# openssl ca -config /root/ca/openssl_root.cnf -extensions v3_intermediate_ca -days 3650 -notext -md sha512 -in /root/ca/intermediate/csr/int.DOMAINNAME.csr -out /root/ca/intermediate/certs/int.DOMAINNAME.crt.pem

** Notice that the root CA configurtion (openssl_root.cnf) is used.

Creating the certificate chain

# cd /root/ca
# cat intermediate/certs/int.DOMAINNAME.crt.pem certs/ca.DOMAINNAME.crt.pem > intermediate/certs/chain.DOMAINNAME.crt.pem

What are all these files for?

So now that you have created all these files, which ones are the ones you need?

In /root/ca/certs, ca.DOMAINNAME.crt.pem is the Root CA certificate.
In /root/ca/intermediate/certs, int.DOMAINNAME.crt.pem is the Intermediate CA certificate.
In /root/ca/intermediate/certs, chain.DOMAINNAME.crt.pem is the concatenation of the Root CA certificate and the Intermediate CA certificate.

Creating server certificates

Copy openssl_csr_san.cnf to /root/ca/intermediate,  edit it and change the entries under [alt_names] so that the DNS.* entries match the Fully Qualified Domain Name of the server you wish to create a certificate for.  This will create a certificate with embedded  Subject Alternative Name (SANs), so no more warnings  from Chrome about NET::ERR_CERT_AUTHORITY_INVALID.

Creating the key and certificate signing request

(change “www.example.com” to your server’s FQDN)

# cd /root/ca
# openssl req -out intermediate/csr/www.example.com.csr.pem -newkey rsa:2048 -nodes -keyout intermediate/private/www.example.com.key.pem -config intermediate/openssl_csr_san.cnf

Creating the certificate by signing the signing request with the intermediate CA

(change “www.example.com” to your server’s FQDN)

# cd /root/ca
# openssl ca -config intermediate/openssl_intermediate.cnf -extensions server_cert -days 3750 -notext -md sha512 -in intermediate/csr/www.example.com.csr.pem -out intermediate/certs/www.example.com.crt.pem

In /root/ca/intermediate/certs you should now have a certificate for use in the server (www.example.com in the case of the example).

Creating a combined certificate for use with Apache server

(change “www.example.com” to your server’s FQDN)

# openssl pkcs12 -inkey www.example.com.key.pem -in www.example.com.crt.pem -export -out www.example.com.combined.pfx
# openssl pkcs12 -in www.example.com.combined.pfx -nodes -out www.example.com.combined.crt