Essential Requirements for Setting Up HTTPS on Arch Linux

System Requirements

• An up-to-date Arch Linux distribution.
• An operational web server such as Apache or Nginx.
• Access to sudo privileges.

Commands that need administrative rights are marked with #. Those suitable for normal users are denoted with $. The best practice for executing root-level commands is to prepend them with sudo while logged in as a standard user.

Ensure a text editor is installed and you are comfortable using it. Options include vi, vim, nano, emacs, or another comparable editor.

Why HTTPS Matters for Secure Web Access

Using HTTPS to deliver web content allows for highly secure encryption. This ensures that data exchanges between the server and the end user remain private and unintelligible to third parties. HTTPS not only protects the data in transit but also conceals the specific URL paths being accessed. Without HTTPS, these URLs could inadvertently disclose sensitive details.

It’s also worth noting that search engines like Google take HTTPS into account when ranking pages. This is in alignment with the broader HTTPS Everywhere movement aimed at promoting secure web access.

Note: While DNS queries do reveal the domain name being contacted, the full URL path remains hidden during that process.

Acquiring an SSL/TLS Certificate for HTTPS

Although TLS officially replaced SSL for HTTPS encryption, the term “SSL Certificate” remains widely used. For simplicity, this guide uses the familiar term “SSL Certificate” throughout.

To enable HTTPS on your web server, you need a private key file (.key) to keep confidential, and a certificate file (.crt) to distribute publicly, which includes your public key. Certificates require signing. While self-signing is possible, most browsers will issue warnings about untrusted authorities. For instance, Chrome may alert users with messages like “Your connection is not private” or “NET::ERR_CERT_AUTHORITY_INVALID.” This might be fine for internal or private websites where users can still bypass the warning by selecting options like “Advanced” and then “Proceed to… (unsafe),” although the browser will still label the connection as insecure.

During the certificate creation process, you’ll be prompted to enter various personal and organizational details, such as your country, state or province, locality, organization, organizational unit, common name (usually the domain), and email. These details become visible to anyone connecting to your site via HTTPS.

If your server hosts multiple virtual sites, you’ll need unique filenames for each certificate and must reference them correctly in your virtual host configurations.

Changing to the Correct Configuration Directory

Navigate to your server’s configuration directory:

For Apache:

$ cd /etc/httpd/conf

For Nginx:

$ cd /etc/nginx

Creating a Self-Signed Certificate

To generate a private key and a self-signed certificate:

# openssl req -new -x509 -nodes -newkey rsa:4096 -keyout server.key -out server.crt -days 825

Set secure permissions to restrict access:

# chmod 400 server.key
# chmod 444 server.crt

Getting a Trusted Certificate

For broader trust and to avoid browser warnings, consider purchasing a certificate signed by a recognized Certificate Authority (CA). While some older browsers may not support newer CAs, reputable ones will usually cover the latest versions of major browsers.

Typically, you’ll need both a domain name and a public IP. Although some authorities can issue certificates to public IPs, this is uncommon.

Many CAs offer a free 30-day trial, which is a good starting point to ensure everything works as expected. Pricing varies, from low-cost basic certificates to expensive premium options for multi-domain or wildcard setups. Standard SSL certificates validate only the domain owner’s control. Extended Validation (EV) certificates include a verification process and often display a green bar in the browser’s address bar.

To prove domain ownership, CAs may require an email address like admin@your-domain.com. Alternatives include uploading a validation file to:

• /srv/http/.well-known/pki-validation/ for Apache
• /usr/share/nginx/html/.well-known/pki-validation/ for Nginx

or modifying your DNS records with a CNAME they provide.

Most CAs accept this general process:

Generating Key and CSR

First, create a private key:

# openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out server.key

Restrict access to the private key:

# chmod 400 server.key

Then generate the Certificate Signing Request (CSR). Use your domain as the Common Name. You can skip the challenge password:

# openssl req -new -sha256 -key server.key -out server.csr

Lock the CSR file permissions as well:

# chmod 400 server.csr

To inspect your CSR contents (which appear in base64 format):

# cat server.csr

Copy everything from -----BEGIN CERTIFICATE REQUEST----- to -----END CERTIFICATE REQUEST----- and paste it into the appropriate form provided by your certificate authority. Depending on the CA and certificate type, approval might be instant or take several days.

Once you receive your certificate, save it as server.crt in your server’s configuration directory and set its permissions:

# chmod 444 server.crt

Configure Your Web Server to Use the Private Key and Certificate

If your server uses a firewall, make sure to permit incoming TCP traffic on port 443, which is required for HTTPS.

Apache Configuration

Open /etc/httpd/conf/httpd.conf and remove the comment symbols from the following lines to enable SSL support:

LoadModule ssl_module modules/mod_ssl.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
Include conf/extra/httpd-ssl.conf

When using Apache virtual hosts, modifying the main config file like this will apply the same certificate to all domains, which can trigger browser errors if the certificate doesn’t match. To resolve this, individually configure each virtual host under /etc/httpd/conf/vhosts/ with its own key and certificate pair.

Replace:

<VirtualHost *:80>

with:

<VirtualHost *:80 *:443>

Inside each VirtualHost block, add:

  SSLEngine on
  SSLCertificateFile "/etc/httpd/conf/YOUR-DOMAIN-NAME.com.crt"
  SSLCertificateKeyFile "/etc/httpd/conf/YOUR-DOMAIN-NAME.com.key"

Then restart Apache:

# systemctl restart httpd

Nginx Configuration

Edit /etc/nginx/nginx.conf, scroll to the bottom, and uncomment the HTTPS server section. Then modify the following directives:

ssl_certificate      server.crt;
ssl_certificate_key  server.key;
root                 /usr/share/nginx/html;

Be aware: updating the main configuration like this means all domains will share the same certificate. To ensure each virtual host uses a unique certificate, go to /etc/nginx/sites-enabled/ and edit or create a separate server block like this:

server {
    listen 443 ssl;
    server_name YOUR-DOMAIN-NAME.com;

    ssl_certificate      YOUR-DOMAIN-NAME.com.crt;
    ssl_certificate_key  YOUR-DOMAIN-NAME.com.key;

    ssl_session_cache    shared:SSL:1m;
    ssl_session_timeout  5m;

    ssl_ciphers  HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers  on;

    location / {
        root /usr/share/nginx/YOUR-DOMAIN-NAME.com;
        index index.html index.htm;
    }
}

Restart Nginx to apply the changes:

# systemctl restart nginx

Conclusion

Setting up HTTPS on an Arch Linux server requires a combination of secure certificate management and careful web server configuration. By obtaining a trusted certificate, configuring your Apache or Nginx setup correctly, and ensuring that each virtual host has its appropriate SSL/TLS settings, you safeguard your visitors’ data and meet modern security expectations. Additionally, using HTTPS can improve your site’s credibility and search engine visibility. Once completed, your server will be equipped to serve encrypted, authenticated traffic over port 443 with confidence.