SSL Certificate Generation: Self-Signed and CA

March 31, 2026 · 12 min read

Understanding SSL Certificates

SSL certificates (now technically TLS certificates, though the SSL term persists) are digital documents that authenticate a website's identity and enable encrypted connections between clients and servers. When you see that padlock icon in your browser's address bar, an SSL certificate is working behind the scenes to protect your data.

These certificates serve two critical functions: they verify that you're connecting to the legitimate server you intended to reach, and they establish an encrypted tunnel through which your data travels safely. Without SSL certificates, sensitive information like passwords, credit card numbers, and personal data would be transmitted in plain text, vulnerable to interception by malicious actors.

The choice of SSL certificate depends on several factors:

• Validation level – How thoroughly the certificate authority verifies your identity
• Domain coverage – Single domain, multiple subdomains, or multiple domains
• Trust requirements – Whether you need public browser trust or internal-only use
• Budget constraints – Free options versus paid certificates with additional features
• Warranty and support – Insurance coverage and technical assistance levels

Understanding these factors helps you select the right certificate type for your specific use case, whether you're securing a personal blog, an e-commerce platform, or an internal corporate application.

Self-Signed Certificates: When and How to Use Them

Self-signed certificates are SSL certificates that you generate and sign yourself, without involving a third-party Certificate Authority. The server essentially vouches for its own identity, which is why browsers don't trust them by default.

These certificates are perfectly functional for encryption purposes—they establish the same secure connection as CA-signed certificates. The difference lies in trust: browsers have no way to verify that your self-signed certificate is legitimate, so they display security warnings to users.

Ideal Use Cases for Self-Signed Certificates

Self-signed certificates excel in specific scenarios where public trust isn't required:

• Development environments – Testing HTTPS functionality locally before deployment
• Internal networks – Securing communication between servers that never face the public internet
• IoT devices – Embedded systems communicating within a controlled network
• Testing and staging servers – Pre-production environments where security warnings are acceptable
• Personal projects – Home labs and learning environments

Generating a Self-Signed Certificate

The most common tool for generating self-signed certificates is OpenSSL, a robust cryptographic library available on most systems. Here's a basic command to create a self-signed certificate:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365 -nodes -subj "/CN=localhost"

Let's break down what each parameter does:

• req -x509 – Creates a self-signed certificate instead of a certificate signing request
• -newkey rsa:4096 – Generates a new 4096-bit RSA private key (stronger than the default 2048-bit)
• -keyout key.pem – Saves the private key to this file
• -out cert.pem – Saves the certificate to this file
• -sha256 – Uses SHA-256 hashing algorithm (secure and widely supported)
• -days 365 – Certificate valid for one year
• -nodes – No password protection on the private key (useful for automated systems)
• -subj "/CN=localhost" – Sets the Common Name without interactive prompts

Advanced Self-Signed Certificate with Subject Alternative Names

Modern browsers require Subject Alternative Names (SANs) for proper certificate validation. Here's how to create a certificate with multiple domain names:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365 -nodes \
  -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,DNS:*.localhost,IP:127.0.0.1"

This certificate works for localhost, any subdomain of localhost, and the IP address 127.0.0.1, making it versatile for local development scenarios.

Advantages and Limitations

Certificate Authorities: The Trust Foundation

Certificate Authorities (CAs) are trusted third-party organizations that verify identities and issue SSL certificates. They form the backbone of the internet's trust infrastructure, acting as digital notaries that vouch for website authenticity.

When a CA issues a certificate, they're essentially saying "we've verified that this organization controls this domain, and we're willing to stake our reputation on it." Browsers and operating systems come pre-loaded with a list of trusted root CAs, which is why CA-signed certificates work seamlessly without security warnings.

How Certificate Authorities Work

The CA system operates on a hierarchical trust model:

1. Root CAs – The ultimate trust anchors, their certificates are embedded in browsers and operating systems
2. Intermediate CAs – Authorized by root CAs to issue certificates on their behalf
3. End-entity certificates – The SSL certificates installed on web servers

This hierarchy provides security through compartmentalization. Root CA private keys are kept in highly secure, often offline environments, while intermediate CAs handle day-to-day certificate issuance. If an intermediate CA is compromised, the root CA can revoke its authority without affecting the entire trust chain.

Major Certificate Authorities

The CA landscape includes both commercial providers and non-profit organizations:

• DigiCert – One of the largest commercial CAs, known for enterprise solutions
• Sectigo (formerly Comodo) – Offers a wide range of certificate types at competitive prices
• GlobalSign – Specializes in enterprise PKI and IoT security
• Let's Encrypt – Non-profit providing free, automated certificates
• GoDaddy – Popular among small businesses and individual website owners
• Entrust – Focuses on high-assurance certificates for financial institutions

Let's Encrypt: Free and Trusted SSL

Let's Encrypt revolutionized SSL certificate accessibility when it launched in 2016. This non-profit Certificate Authority, sponsored by major tech companies and organizations, provides free SSL certificates with full browser trust.

The project's mission is to create a more secure and privacy-respecting web by removing cost and complexity barriers to HTTPS adoption. Today, Let's Encrypt issues more certificates than all other CAs combined, securing hundreds of millions of websites.

Key Features of Let's Encrypt

• Completely free – No hidden costs or premium tiers
• Automated issuance – Certificates can be obtained and renewed without human intervention
• Domain Validation only – Focuses on verifying domain control, not organizational identity
• 90-day validity – Shorter lifespan encourages automation and reduces risk from compromised certificates
• Wildcard support – Can secure unlimited subdomains with a single certificate
• Full browser trust – Recognized by all major browsers and operating systems

Getting Started with Let's Encrypt

The recommended way to use Let's Encrypt is through Certbot, an automated client that handles certificate issuance and renewal. Here's a basic workflow for a web server:

# Install Certbot (Ubuntu/Debian example)
sudo apt-get update
sudo apt-get install certbot python3-certbot-nginx

# Obtain and install certificate for Nginx
sudo certbot --nginx -d example.com -d www.example.com

# Test automatic renewal
sudo certbot renew --dry-run

Certbot automatically configures your web server, obtains the certificate, and sets up automatic renewal. The entire process takes just a few minutes.

Alternative ACME Clients

While Certbot is the official client, several alternatives offer different features and approaches:

• acme.sh – Lightweight shell script with minimal dependencies
• Caddy – Web server with built-in automatic HTTPS using Let's Encrypt
• Traefik – Reverse proxy with native Let's Encrypt integration
• win-acme – Windows-focused client with GUI and scheduled tasks

When Let's Encrypt Might Not Be Ideal

Despite its advantages, Let's Encrypt isn't perfect for every scenario:

• Organization Validation needs – Let's Encrypt only offers Domain Validation
• Extended Validation requirements – Not available from Let's Encrypt
• Warranty requirements – No financial warranty or liability coverage
• Longer validity periods – Some organizations prefer annual certificates for administrative simplicity
• Offline or air-gapped systems – Require internet connectivity for validation

Commercial SSL Certificates: Added Assurances

Commercial SSL certificates from paid Certificate Authorities offer features and assurances beyond what free options provide. While encryption strength is identical to Let's Encrypt, commercial certificates include additional benefits that matter for certain use cases.

Why Choose Commercial Certificates

Organizations opt for paid certificates for several compelling reasons:

• Extended validation – Display company name in browser address bar (though this feature is being phased out)
• Financial warranties – Coverage ranging from $10,000 to $2,000,000 for certificate-related breaches
• Dedicated support – Phone and email assistance for installation and troubleshooting
• Longer validity – Up to 397 days (maximum allowed by browser standards)
• Organizational validation – Verified company information in certificate details
• Trust seals – Displayable badges that may increase customer confidence
• Multi-year purchases – Buy multiple years upfront (though certificates must be reissued annually)

Commercial Certificate Pricing

Prices vary significantly based on validation level and features:

Evaluating Commercial Certificate Value

Before purchasing a commercial certificate, consider whether the additional features justify the cost:

• Do you need Organization or Extended Validation for compliance or customer trust?
• Is the financial warranty meaningful for your risk profile?
• Would dedicated support save time and reduce deployment risks?
• Do you require features not available from Let's Encrypt?
• Are there regulatory requirements mandating specific certificate types?

For many websites, Let's Encrypt provides everything needed. Commercial certificates make sense when specific features, validation levels, or support requirements justify the investment.

Exploring SSL Validation Levels

SSL certificates come in three validation levels, each offering different degrees of identity verification. Understanding these levels helps you choose the appropriate certificate for your security and trust requirements.

Domain Validation (DV)

Domain Validation certificates verify only that you control the domain name. The CA confirms you can receive email at the domain or modify DNS records, but doesn't verify your organizational identity.

Validation process:

• Respond to an email sent to [email protected] or similar addresses
• Add a specific DNS TXT record to your domain
• Upload a verification file to your web server

Issuance time: Minutes to hours

Best for: Blogs, personal websites, internal applications, development environments, and any site where organizational identity verification isn't critical.

Organization Validation (OV)

Organization Validation certificates include verification of your organization's legal existence and identity. The CA checks business registration databases and may call your organization to confirm details.

Validation process:

• Domain control verification (same as DV)
• Business registration verification through government databases
• Phone verification to confirm organizational details
• Verification of authorized representative

Issuance time: 1-3 business days

Best for: Corporate websites, business applications, organizations wanting to display verified company information in certificate details.

Extended Validation (EV)

Extended Validation certificates require the most rigorous verification process. The CA conducts extensive checks on your organization's legal, physical, and operational existence.

Validation process:

• All OV requirements plus additional verification
• Verification of physical business address
• Confirmation of operational existence (active business operations)
• Verification against government watchlists
• Attorney opinion letters or accountant letters in some cases

Issuance time: 3-7 business days

Best for: E-commerce sites, financial institutions, healthcare providers, and organizations where maximum trust indicators are valuable.

Validation Level Comparison

Advanced Features: Wildcard Certificates and Automation

Wildcard Certificates

Wildcard certificates secure a domain and all its first-level subdomains with a single certificate. Instead of obtaining separate certificates for www.example.com, blog.example.com, and shop.example.com, a wildcard certificate for *.example.com covers them all.

Advantages:

• Simplified certificate management with fewer certificates to track
• Cost-effective for organizations with many subdomains
• Easier deployment in dynamic environments where subdomains are created frequently
• Reduced administrative overhead for renewals and installations

Limitations:

• Only covers one level of subdomains (*.example.com doesn't cover api.v2.example.com)
• If compromised, all subdomains are affected
• Cannot be used with Extended Validation
• Requires DNS-01 challenge for Let's Encrypt wildcard certificates

Multi-Domain (SAN) Certificates

Subject Alternative Name (SAN) certificates secure multiple distinct domains with a single certificate. You might secure example.com, example.net, and example.org all with one certificate.

These certificates are ideal for organizations managing multiple brands or domains that should be served from the same infrastructure. Most SAN certificates allow 3-100 domains, with the ability to add or remove domains during reissuance.

Certificate Automation

Modern certificate management emphasizes automation to reduce errors and ensure timely renewals. Manual certificate management is error-prone and doesn't scale well.

Automation strategies:

• ACME protocol – Standardized protocol for automated certificate issuance and renewal
• Certificate management platforms – Centralized tools for tracking and renewing certificates across infrastructure
• Infrastructure as Code – Define certificate requirements in configuration files
• Monitoring and alerting – Automated notifications before certificate expiration
• CI/CD integration – Automatic certificate deployment as part of release pipelines

Certificate Transparency

Certificate Transparency (CT) is a security mechanism that logs all issued certificates in public, append-only logs. This allows domain owners to monitor for unauthorized certificates issued for their domains.

All major CAs submit certificates to CT logs, and browsers require CT compliance for certificates to be trusted. You can monitor CT logs using services like crt.sh or Facebook's Certificate Transparency Monitoring tool to detect suspicious certificate issuance.

Step-by-Step Implementation Guide

Implementing SSL on Apache

Apache is one of the most popular web servers, and SSL configuration is straightforward once you understand the basics.

Step 1: Enable SSL module

sudo a2enmod ssl
sudo systemctl restart apache2

Step 2: Configure virtual host

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    
    DocumentRoot /var/www/html
    
    SSLEngine on
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/key.pem
    SSLCertificateChainFile /path/to/chain.pem
    
    # Modern SSL configuration
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite HIGH:!aNULL:!MD5
    SSLHonorCipherOrder on
</VirtualHost>

Step 3: Redirect HTTP to HTTPS

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Implementing SSL on Nginx

Nginx offers excellent SSL performance and straightforward configuration.

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;
    
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    
    # Modern SSL configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    
    # HSTS header
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    
    root /var/www/html;
    index index.html;
}

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

Testing Your SSL Configuration

After implementing SSL, thorough testing ensures everything works correctly:

• SSL Labs Server Test – Comprehensive analysis at ssllabs.com/ssltest
• OpenSSL command-line testing – openssl s_client -connect example.com:443
• Browser testing – Check for padlock icon and certificate details
• Mixed content checking – Ensure all resources load over HTTPS
• Certificate chain validation – Verify intermediate certificates are properly configured

Use our SSL Checker tool to quickly verify your certificate installation and identify potential issues.

Common Issues and Troubleshooting

Certificate Chain Issues

One of the most common SSL problems is an incomplete certificate chain. Browsers need to verify the entire chain from your certificate up to a trusted root CA.

Symptoms:

• Certificate errors in some browsers but not others
• Mobile devices showing errors while desktop browsers work
• SSL Labs test showing "Chain issues"

Solution: Ensure you've installed the intermediate certificate(s) provided by your CA. Most CAs provide a bundle file containing all necessary intermediate certificates.

Name Mismatch Errors

These occur when the domain name in the certificate doesn't match the domain you're accessing.

Common causes:

• Accessing www.example.com with a certificate for example.com (or vice versa)
• Certificate issued for one domain but used on another
• Wildcard certificate used incorrectly for multi-level subdomains

Solution: Obtain a certificate that includes all domain variations you need, or use a wildcard certificate for subdomain flexibility.

Expired Certificates

Certificate expiration is a leading cause of website outages, often due to failed automation or missed renewal notifications.

Prevention strategies:

• Set up automated renewal with Let's Encrypt or similar services
• Configure monitoring alerts 30+ days before expiration
• Maintain a certificate inventory with expiration dates
• Test renewal processes regularly in non-production environments

Mixed Content Warnings

After implementing HTTPS, you might see warnings about mixed content—secure pages loading insecure resources.

Finding mixed content:

• Check browser developer console for warnings
• Use online tools like Why No Padlock
• Search your codebase for http:// URLs

Fixing mixed content:

• Update all resource URLs to use HTTPS
• Use protocol-relative URLs (//example.com/resource.js)
• Implement Content Security Policy to block insecure resources

Security Best