A self-signed SSL certificate is a simple way to enable HTTPS on Apache without purchasing a certificate from a Certificate Authority (CA).
Many older tutorials still use a basic openssl req -x509 command to create a certificate. While that works, it often creates a certificate without a Subject Alternative Name (SAN) that modern web browsers such as Chrome and Firefox have required SAN support for years. Without it, visitors will see errors like ERR_CERT_COMMON_NAME_INVALID, even if the certificate’s Common Name appears correct.
In this guide, you’ll create a proper self-signed certificate using a san.cnf configuration file that includes SAN entries. You’ll then configure a complete Apache SSL VirtualHost for store.linuxapp.com and apply a few recommended TLS security settings. The same procedure also works on RHEL 10 and AlmaLinux 10.
Before starting, make sure you have:
Rocky Linux 10 already includes OpenSSL in the base operating system, so you don’t need to install it separately. What you do need is Apache (httpd) and the mod_ssl package, which adds SSL/TLS support to the web server.
When mod_ssl is installed, it automatically creates a default SSL configuration file at:
Next, start Apache and configure it to launch automatically whenever the server boots:
Now verify that Apache is running correctly:
Rocky Linux uses firewalld to control incoming network traffic. By default, only approved services and ports are allowed through the firewall.
Since Apache serves regular web traffic on port 80 (HTTP) and encrypted traffic on port 443 (HTTPS), both ports must be opened. Otherwise, visitors won’t be able to reach your website even if Apache is running correctly.
Run the following commands:
To verify that both services are allowed through the firewall, run:
You can also confirm that Apache is listening on both web ports with:
With the firewall ready, the next step is to create a proper self-signed SSL certificate with Subject Alternative Name (SAN) support.
A Subject Alternative Name (SAN) specifies the hostnames and IP addresses that a certificate is valid for and modern browsers no longer rely on the Common Name (CN) alone when verifying certificates.
If a certificate doesn’t contain a SAN entry, browsers such as Chrome, Firefox, and Edge will reject it with an error like:
First, create a directory to store the certificate, private key, and configuration file:
Next, create the OpenSSL configuration file:
Add the following contents:
Here’s what the important sections do:
In this example:
If your server uses a different domain name, replace every occurrence of store.linuxapp.com with your own hostname.
You can also add additional domains or subdomains by creating more entries:
For internal applications accessed by IP address, you can include IP-based SAN entries as well:
Once you’ve finished editing the file, save it and exit the editor.
Now that the san.cnf file is in place, you can generate both the private key and the self-signed certificate in a single command.
During the process, OpenSSL displays progress indicators while generating the RSA key.
After the command finishes, you’ll have two new files:
Next, you need to secure the private key, which is the most sensitive file in the entire setup, because if anyone can obtains it can impersonate your website.
Verify both files exist with the right permissions.
Output:
Now verify that the SAN entries were actually embedded into the certificate.
If you see your hostnames listed under Subject Alternative Name, the certificate was generated correctly.
If the SAN section is missing or empty, browsers such as Chrome and Firefox will reject the certificate with hostname validation errors, even if the Common Name (CN) matches the site name.
Although mod_ssl installs a default SSL configuration file (ssl.conf), it’s better to create a separate VirtualHost file for each website, which keeps your configuration organized and makes it easier to manage multiple sites on the same server.
Before configuring Apache, create a simple test website under your DocumentRoot directory so you have something to serve over HTTPS.
Now create a dedicated Apache configuration file:
Add the following configuration:
Save the file and exit the editor.
At this point, Apache knows where your website files are located and which SSL certificate to use.
At this point, Apache is configured to serve HTTPS traffic on port 443. However, users may still access your site using an http:// URL or by simply typing the domain name into their browser.
To ensure all traffic is encrypted, create a second VirtualHost that listens on port 80 and automatically redirects visitors to HTTPS.
Create a new configuration file:
Add the following configuration:
Before reloading Apache, always verify that the configuration is free of syntax errors.
If Apache finds a problem, it displays the configuration file and line number where the error occurred.
Correct any reported errors and run configtest again until you see Syntax OK.
Once the configuration passes validation, reload Apache to apply the changes without interrupting existing connections:
You can confirm that Apache is listening for both HTTP and HTTPS connections with:
Example output:
If you see entries for both 80 and 443, Apache is ready to serve HTTP requests and redirect them to HTTPS.
With Apache reloaded and the SSL VirtualHost active, it’s time to verify that HTTPS is working correctly.
If your domain isn’t pointing to the server yet, add a temporary entry to the local machine you’re testing from.
Replace 192.168.1.10 with your server’s actual IP address, which allows your system to resolve the hostname locally without requiring a DNS record:
You can verify the hostname resolves correctly:
Example output:
Since the certificate is self-signed, curl will not trust it by default, so use the -k option to bypass certificate validation during testing.
Example output:
Next, confirm that all HTTP traffic is being redirected to HTTPS.
Example output:
This confirms that visitors using an unencrypted URL are automatically redirected to the secure HTTPS version of the site.
Open https://store.linuxapp.com in a browser, and you’ll see a certificate warning, which is expected since no recognized CA signed this cert, so click Advanced and proceed to confirm the page loads and the connection is encrypted.
One of the biggest advantages of Rocky Linux 10 is that you don’t have to spend much time tuning SSL/TLS settings manually. The distribution inherits RHEL 10’s system-wide cryptographic policy framework, which provides secure defaults for TLS-enabled applications such as Apache, Nginx, OpenSSH, and others.
The default policy, appropriately named DEFAULT, already disables outdated protocols and enforces modern cryptographic standards across the operating system.
You can check the currently active policy with:
With the DEFAULT policy active, Rocky Linux 10 enforces a minimum of TLS 1.2 and uses strong cipher suites by default. That means you don’t need to manually maintain long SSLCipherSuite strings in your Apache configuration just to achieve a secure baseline.
This is why the VirtualHost configuration in this guide only specifies:
The operating system handles the lower-level cryptographic details, making SSL/TLS configuration simpler and more consistent.
In this guide, you installed Apache with SSL support, opened the required firewall ports, generated a self-signed certificate with proper Subject Alternative Name (SAN) entries, configured a dedicated HTTPS VirtualHost, and redirected all HTTP traffic to HTTPS.
The SAN verification step is particularly important because it’s what ensures modern browsers can validate the certificate correctly. Many older tutorials skip this step and end up producing certificates that browsers reject immediately.
For internal services, development environments, and lab systems, a self-signed certificate provides an easy way to enable encrypted HTTPS connections without relying on an external Certificate Authority.
When you’re ready to publish a site to the internet, you can swap in a trusted certificate from Let’s Encrypt while keeping the same Apache VirtualHost structure you’ve already built.
How to Install Icinga 2 Monitoring Server on Rocky Linux 10
Cockpit on Rocky Linux 10: Full Server Management Without SSH
Install Rocky Linux 10 Remotely via RDP on a Headless Server
Upgrade Rocky Linux 9 to Rocky Linux 10.1
Rocky Linux 10 Minimal Server Installation Guide
How to Install Apache, MySQL/MariaDB and PHP in Linux
WOW just what I was looking for. Came here by searching for create ssl certificates
remove the previous message my mistake I forgot the chmod for the file.
Hi I did try the ‘apache_ssl’ script but nothing happens.
Question: is there a option for error logging in the script?
httpstat – A Curl Statistics Tool to Check Website Performance
Swatchdog – Simple Log File Watcher in Real-Time in Linux
How to Install LibreNMS Monitoring Tool on Debian 11/10
Suricata – A Intrusion Detection, Prevention, and Security Tool
All You Need To Know About Processes in Linux [Comprehensive Guide]
How to Limit Time and Memory Usage of Processes in Linux
3 Ways to List All Installed Packages in RHEL, CentOS and Fedora
How to Run Multiple Commands on Multiple Linux Servers
Newsroom – A Modern CLI to Get Your Favorite News in Linux
How to Restore Deleted /tmp Directory in Linux
How to Find All Clients Connected to HTTP or HTTPS Ports
10 Must-Know sFTP Commands for Linux File Transfers
3 Essential Linux Disk Scanning Tools (GUI and Terminal Based)
5 Top Open-Source Microsoft 365 Alternatives for Linux
6 Best Linux Apps for Downloading Movie Subtitles
16 Best Tools to Access Remote Linux Desktop
6 Best Whiteboard Applications for Your Linux Systems
8 Best PowerPoint Alternatives for Linux
About The Author
