Mail

Setting up SSL/TLS for a website or internal application sounds simple—get a certificate, install it, done. But in real-world production, the situation is a bit more complex.

In this article, we'll walk through everything from private keys to certificate deployment, including self-signed vs CA certificates, Let's Encrypt, Linux deployment configs, internal vs public domain requirements, and common misconceptions.

By the end, you'll understand how SSL works under the hood and how to implement it securely in production environments.

What is a Private Key?

The private key is the heart of SSL security.

Technically, it is a cryptographic file (usually PEM/RSA/ECDSA) that proves ownership of a certificate. It should never be shared. The server uses it to terminate TLS connections, creating the secure channel.

Contents:

A mathematically linked key to the certificate's public key
Optional password protection

Analogy: "The private key is like a master key to your office. Anyone who has it can enter and pretend to be you."

Risks of leakage:

Impersonation of your server
Active MITM attacks in your network
Unauthorized access to sensitive internal services

Sample private key file content:

-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDGtJhKWqvI2RxB
L8F9v8F3hR7K9mN2pS6tVx8wQ4N3pA5xJ2mF7kP9vL4cR8yT6nM3dQ8wS1fV3gH
Yx4kF9qR2tA3wP8vF5cY9sG4nV2jK8rT6mU9wX7yP4vL2cY9wG3nF4sK8rU2mJ
... (truncated for security)
-----END PRIVATE KEY-----

What is a Certificate File?

Certificates (.crt or .pem) are the public counterpart of the private key.

Contents include:

Public key
Domain(s) covered (CN / SAN)
Validity period
Issuer info (CA)
Signature from CA to prove authenticity

The certificate matches the private key cryptographically. Only the paired private key can complete the TLS handshake. Browsers validate this using the certificate chain to a trusted root CA.

Intermediate certificates and chain files are used to connect your server certificate to a root CA, which browsers already trust.

Sample certificate file content:

-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvKQNxEMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMjUxMjIxMTAwMDAwWhcNMjYxMjIxMTAwMDAwWjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxrSYSlqryNkcQS/Bfb/Bd4UeyvZjdqUurVcfMEODd6QOcSdphe5D/by+
... (truncated)
-----END CERTIFICATE-----

Self-Signed Certificates

Self-signed certificates are generated without a CA.

Generation example (Linux/OpenSSL):

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

Pros: Free, fast, good for testing

Cons: Not trusted by browsers by default (warnings appear)

Use case: internal development, lab environments

Limitations:

Scaling to hundreds of clients requires manually trusting the certificate
Users may bypass warnings, creating a false sense of security

Analogy: "Self-signed certs are like making your own ID card. You are the authority, but nobody else knows you are legit."

CA-Authorized Certificates

Public CA certificates (e.g., GoDaddy, DigiCert) are trusted by browsers out-of-the-box.

Why SSL for domains costs money:

CA validation infrastructure
Identity verification (OV/EV certs)
Certificate issuance and revocation management

Average cost:

Single domain: $10–$ 100/year
Wildcard: $50–$ 200/year

Advantages:

Trusted by all major browsers (green lock)
Avoids manual client trust deployment
Automation of renewal in most cases

Deploying SSL in Linux Production

File Setup

Private key: /etc/ssl/private/mydomain.key
Certificate: /etc/ssl/certs/mydomain.crt
CA bundle (intermediate certs): /etc/ssl/certs/ca-bundle.crt

Permissions

Private key: chmod 600 root:root
Certificate files: chmod 644

Apache example:

<VirtualHost *:443>
    ServerName mydomain.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/mydomain.crt
    SSLCertificateKeyFile /etc/ssl/private/mydomain.key
    SSLCertificateChainFile /etc/ssl/certs/ca-bundle.crt
    <Directory /var/www/html>
        AllowOverride All
    </Directory>
</VirtualHost>

Nginx example:

server {
    listen 443 ssl;
    server_name mydomain.com;

    ssl_certificate /etc/ssl/certs/mydomain.crt;
    ssl_certificate_key /etc/ssl/private/mydomain.key;
    ssl_trusted_certificate /etc/ssl/certs/ca-bundle.crt;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Best practices:

Enable HSTS
Disable TLS 1.0/1.1, weak ciphers
Automate certificate renewal
Keep keys separate and restricted

Let's Encrypt Considerations

Let's Encrypt provides free, automated certificates.

Pros: free, automated renewal, browser-trusted

Cons in production:

90-day validity (requires automation)
DNS-01 challenge for wildcard/internal domains
Dependency on external CA for internal-only systems

Recommendation: works well for public websites, but not the best choice for important internal networks where reliability and control matter most.

Public Domain SSL vs Internal Network SSL

Public domains:

Must use CA-trusted certificate
Automation for renewal critical
Full browser trust required

Internal networks:

Can use self-signed or internal CA
Trust deployment via AD or client management
Security policy may require mTLS for APIs

Decision factors:

Scale of clients
Security requirements
Cost vs convenience

TLS Security in Production

Forward secrecy: makes sure session keys are temporary. Even if the private key is stolen, past communications cannot be read.

Attacks:

Passive sniffing: safe with modern TLS
Active MITM: attacker with private key can terminate TLS and see plaintext

Testing includes:

Checking certificate chain
Verifying ciphers and TLS versions
Monitoring certificate expiration

Analogy: "TLS handshake is like agreeing on a secret code that only you and the server understand, so no one else can read it."

Common Misconceptions

Private key leak does not decrypt past traffic (with forward secrecy)
Wildcard certs are convenient, but risk radius is bigger
Self-signed certificates are safe at small scale
Internal-only domains cannot always use public CA

Best Practices

Protect private keys (permissions, vault)
Use POST for sensitive data
Enable HSTS and enforce modern TLS
Use mTLS for internal APIs
Monitor certificates, automate renewal
Limit wildcard certs for high-risk systems
Keep ciphers and TLS versions updated

Conclusion

SSL/TLS is more than just installing a certificate. Knowing about private keys, certificates, self-signed vs CA certs, Let's Encrypt, Linux setup, and real-world deployment details is important for keeping web applications safe.