Technical Tutorial
PEM Format SSL Certificate Implementation Guide
A general tutorial for implementing PEM format SSL certificates issued from
a Certificate Authority (CA) management console into Ubuntu 24 + Apache + WordPress environments.
Apache
WordPress
PEM SSL
Disclaimer #
This article is a technical tutorial that explains general procedures for implementing SSL certificates (PEM format) in Ubuntu 24 + Apache + WordPress environments.
The content is based on information current at the time of writing, but operational procedures and configuration methods may differ depending on specific environments, configurations, certificate types, CA specifications, middleware versions, and other factors.
Overview #
This article is a general tutorial for implementing PEM format SSL certificates
(the type displayed in a text box in the CA management console) into
Ubuntu 24 + Apache + WordPress sites.
Regardless of whether the certificate is EV / OV / DV, the basic procedures for server deployment are the same.
Prerequisites #
- OS: Ubuntu 24 (with root or sudo privileges)
- Web: Apache (
apache2) is running - CMS: WordPress is running under Apache
- Certificate: Server Certificate has been issued from CA
- Intermediate Certificate: Intermediate Certificate (CA Bundle) is available from CA
- Important: You possess the Private Key created when the CSR was generated (re-issuance is required if lost)
Certificate Format Displayed in CA Console (Sample Display) #
In the CA management console, the following block (PEM) may be displayed in a text box. Copy this block from beginning to end and save it to the server.
-----BEGIN CERTIFICATE-----
(long string of alphanumeric characters)
-----END CERTIFICATE-----Caution
- Include the
BEGIN/ENDlines when copying. - The configuration will work even if line breaks are corrupted, but it is safest to paste exactly as displayed.
- Do not paste the Private Key (BEGIN PRIVATE KEY).
Overall Implementation Flow #
- Save certificate files in the designated location
- Prepare the intermediate certificate (chain)
- Create fullchain (server certificate + intermediate)
- Verify that the private key and certificate match
- Configure Apache HTTPS VirtualHost (including 80 → 443 redirect)
- Reload Apache and prepare WordPress URL / mixed content
- Verify operation (chain, redirect, certificate information)
Step 1Certificate File Placement (Server Certificate) #
A typical Ubuntu placement example (modify according to your operational policy).
Save Location (Example) #
- Private Key (existing):
/etc/ssl/private/example.com.key - Server Certificate:
/etc/ssl/certs/example.com.crt - Intermediate Certificate:
/etc/ssl/certs/intermediate-ca.pem - Fullchain:
/etc/ssl/certs/example.com.fullchain.pem
Directory Creation and Permissions #
sudo mkdir -p /etc/ssl/private /etc/ssl/certs
sudo chmod 700 /etc/ssl/privateSave Certificate (PEM) from CA Console to File #
Copy the certificate block from the CA console text box and save it to /etc/ssl/certs/example.com.crt.
sudo nano /etc/ssl/certs/example.com.crt
sudo chmod 644 /etc/ssl/certs/example.com.crtExample for automated saving locally:
sudo tee /etc/ssl/certs/example.com.crt >/dev/null <<'EOF'
-----BEGIN CERTIFICATE-----
(paste certificate content here)
-----END CERTIFICATE-----
EOF
sudo chmod 644 /etc/ssl/certs/example.com.crtStep 2Prepare Intermediate Certificate (CA Bundle / Intermediate) #
Many CAs provide an Intermediate Certificate (or CA Bundle) separate from the server certificate. Without this, some devices may display “untrusted” messages.
Save Intermediate Certificate (Example) #
Save the intermediate certificate (one or multiple) obtained from the CA in PEM format to the following location:
sudo nano /etc/ssl/certs/intermediate-ca.pem
sudo chmod 644 /etc/ssl/certs/intermediate-ca.pemIf There Are Multiple Intermediates #
If the CA Bundle contains multiple intermediate certificates, combine them in a single file in the order specified by the CA (typically in the direction of the root).
Step 3Create Fullchain (Server Certificate + Intermediate) #
In Apache, it is standard practice to specify fullchain (server certificate + intermediate) as the certificate file.
sudo cat /etc/ssl/certs/example.com.crt \
/etc/ssl/certs/intermediate-ca.pem \
| sudo tee /etc/ssl/certs/example.com.fullchain.pem >/dev/null
sudo chmod 644 /etc/ssl/certs/example.com.fullchain.pemStep 4Verify Private Key and Certificate Match (Important) #
If the certificate and private key do not match, HTTPS will not work properly even after configuring Apache. Always verify.
Verification Method A: RSA Key Case (Modulus Comparison) #
openssl x509 -noout -modulus -in /etc/ssl/certs/example.com.crt | openssl md5
openssl rsa -noout -modulus -in /etc/ssl/private/example.com.key | openssl md5If both MD5 values are the same, they match.
Verification Method B: Key Type Independent (Public Key SHA256 Comparison) #
# Certificate → Public Key → SHA256
openssl x509 -in /etc/ssl/certs/example.com.crt -pubkey -noout \
| openssl pkey -pubin -outform DER \
| openssl sha256
# Private Key → Public Key → SHA256
openssl pkey -in /etc/ssl/private/example.com.key -pubout -outform DER \
| openssl sha256If both SHA256 values are the same, they match.
If They Do Not Match #
- It is likely that the CSR was created with a different private key.
- If the correct private key cannot be found, you must re-issue (Reissue) from the CA side and create the CSR again with the correct key.
Step 5Enable HTTPS in Apache #
Enable Required Modules #
sudo a2enmod ssl
sudo a2enmod headers
sudo a2enmod rewrite
sudo systemctl reload apache2Verify That Port 443 is Being Listened To #
Usually /etc/apache2/ports.conf contains Listen 443. Verify as needed.
Step 6Apache VirtualHost Configuration (443 + 80→443 Redirect) #
Here, we will create and implement a site configuration file for example.com as an example.
Create Site Configuration File (Example) #
sudo nano /etc/apache2/sites-available/example.com.confConfiguration Example (WordPress Assumed) #
※ Replace example.com and DocumentRoot in the code with your actual environment.
<VirtualHost *:80>
ServerName example.com
# HTTP → HTTPS permanent redirect
RewriteEngine On
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName example.com
DocumentRoot /var/www/example.com/public
# For WordPress (.htaccess operation case)
<Directory /var/www/example.com/public>
AllowOverride All
Require all granted
</Directory>
SSLEngine on
# Specify fullchain (server certificate + intermediate)
SSLCertificateFile /etc/ssl/certs/example.com.fullchain.pem
SSLCertificateKeyFile /etc/ssl/private/example.com.key
# Recommended: Enable as needed (prioritize operation verification first)
# Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
ErrorLog ${APACHE_LOG_DIR}/example.com-ssl-error.log
CustomLog ${APACHE_LOG_DIR}/example.com-ssl-access.log combined
</VirtualHost>
</IfModule>Enable the Site #
sudo a2ensite example.com.confConfiguration Test → Reload #
sudo apache2ctl configtest
sudo systemctl reload apache2To check which VirtualHost is enabled:
sudo apache2ctl -SStep 7Convert WordPress to HTTPS #
Unify Site URL to HTTPS #
- WordPress Admin Console → Settings → General
- Set both “WordPress Address (URL)” and “Site Address (URL)” to
https://example.com
Mixed Content Mitigation #
- If images and CSS / JS remain as
http://, it will cause the lock icon to disappear. - Unify to
https://via database replacement, theme settings, plugins, etc. (backup before operation is recommended).
Step 8Verify Operation #
HTTPS Connectivity (curl) #
curl -I https://example.com/
curl -I http://example.com/Expected results:
https://example.com/returns 200 / 301 or other normal responsehttp://example.com/redirects to https with 301
Certificate Chain Verification (openssl) #
echo | openssl s_client -connect example.com:443 -servername example.com -showcertsBrowser Verification #
- No certificate errors appear
- Certificate details show expected issuer / expiration / SAN and other information
Common Troubleshooting #
Certificate Shows as “Untrusted” Despite Being Correct #
- The intermediate certificate (CA Bundle) may not be provided or not included in the fullchain.
- Verify that
SSLCertificateFilepoints to the fullchain.
Apache Startup / Reload Fails with SSL Error #
- The private key path may be incorrect, permissions inappropriate, or the key and certificate may not match.
- Re-run the match verification in “Step 4”.
Redirect Loop Occurs #
- WordPress side (siteurl / home) and Apache side (80 → 443) may be contradicting each other.
- If using a CDN / reverse proxy such as Cloudflare, SSL mode settings may also have an impact.
Rollback #
- Backup of Apache site configuration files and certificate-related files before implementation is recommended.
- If problems occur, disable the relevant site and reload.
sudo a2dissite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2Operations Notes (Renewal / Re-issuance) #
- Basic for renewal / re-issuance: New CSR → Re-issue / Renewal at CA → Replace fullchain → Apache reload
- Suspected private key compromise: Revoke → Create CSR with new key → Re-issue
- Do not modify certificate files; save issued materials (PEM) accurately