Coder Legion - Recent posts tagged ssl

Bash Script to Automatically Renew and Reload SSL Certificates

Fri, 20 Mar 2026 10:34:54 +0000

Keeping your website secure isn’t optional anymore. Users expect it, browsers enforce it, and search engines reward it. SSL certificates are a core part of that security, but managing them manually can quickly become a headache, especially when they expire every 90 days.

If you’ve ever had a site go down or show a "Not Secure" warning because of an expired certificate, you know how frustrating it can be.

The good news is that you can automate the entire process. In this post, you’ll learn how to use a simple Bash script to automatically renew your SSL certificates and reload your web server without any downtime.

Why Automating SSL Renewal Matters

Let’s start with the obvious. SSL certificates expire. If you’re using Let’s Encrypt, they typically last 90 days. That’s great for security, but it means you need a reliable renewal process.

Manual renewal comes with risks:

You forget to renew on time
You renew but forget to reload your server
Your site goes offline unexpectedly

Automation solves all of this. Once set up, your system quietly handles renewals in the background.

You get:

Continuous HTTPS protection
Zero manual effort
No surprise outages

What This Script Does

The Bash script we’re working with handles three main tasks:

Renews SSL certificates using Certbot
Checks if renewal was successful
Reloads your web server (like Nginx or Apache) to apply changes

It’s simple, efficient, and reliable.

The Bash Script

Here’s a clean version of the script:

#!/bin/bash

LOG_FILE="/var/log/ssl_renewal.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

echo "[$DATE] Starting SSL renewal process..." >> $LOG_FILE

# Renew certificates
certbot renew --quiet

# Check if renewal was successful
if [ $? -eq 0 ]; then
    echo "[$DATE] SSL certificates renewed successfully." >> $LOG_FILE
    
    # Reload web server
    systemctl reload nginx
    
    if [ $? -eq 0 ]; then
        echo "[$DATE] Nginx reloaded successfully." >> $LOG_FILE
    else
        echo "[$DATE] Failed to reload Nginx." >> $LOG_FILE
    fi
else
    echo "[$DATE] SSL renewal failed." >> $LOG_FILE
fi

Breaking It Down

If you’re not deeply familiar with Bash, here’s what’s happening in plain terms.

Logging Activity

The script logs everything to a file:

LOG_FILE="/var/log/ssl_renewal.log"

This is useful for troubleshooting. If something goes wrong, you can check the log.

Running Certbot

certbot renew --quiet

This command attempts to renew any certificates that are close to expiration. The --quiet flag keeps things clean unless there’s an error.

Checking Success

if [ $? -eq 0 ];

This checks whether the previous command worked. A return value of 0 means success.

Reloading the Server

systemctl reload nginx

This applies the new certificates without restarting the server, which means no downtime.

If you’re using Apache instead, you’d replace that with:

systemctl reload apache2

Automating with Cron

The script is only useful if it runs automatically. That’s where cron jobs come in.

Open your crontab:

crontab -e

Add this line to run the script daily at 2:30 AM:

30 2 * * * /path/to/your/script.sh

Make sure your script is executable:

chmod +x /path/to/your/script.sh

That’s it. Your server now handles SSL renewal on its own.

Best Practices for SSL Automation

To keep things running smoothly, follow a few simple guidelines:

1. Test your setup
Run the script manually before relying on automation:

./script.sh

2. Use staging mode first
If you’re testing renewal logic:

certbot renew --dry-run

3. Monitor logs
Check your log file occasionally:

cat /var/log/ssl_renewal.log

4. Set up alerts (optional)
For production systems, consider email alerts if renewal fails.

Common Issues to Watch For

Even with automation, things can go wrong. Here are a few common problems:

Port 80/443 blocked: Certbot needs access for validation
Incorrect domain configuration
Server reload failures due to config errors

If renewal fails, the logs will usually point you in the right direction.

SEO Benefits of SSL (Yes, It Matters)

Beyond security, SSL certificates also impact your search rankings from the eyes of a developer.

Google uses HTTPS as a ranking signal. Sites without SSL may:

Rank lower in search results
Show "Not Secure" warnings in browsers
Lose user trust

Automating SSL renewal helps maintain both your security and your SEO performance.

Final Thoughts

Automating SSL certificate renewal with a Bash script is one of those small improvements that pays off constantly. It saves time, prevents downtime, and keeps your site secure without ongoing effort.

Once you set it up, you can forget about expiration dates and focus on what actually matters, like building and growing your site.

If you manage multiple servers or websites, this approach becomes even more valuable.

If you found this helpful, consider sharing it with someone who manages servers or websites. It might save them from their next "certificate expired" panic.

The SSL Handshake Failed: Debugging the "Invisible Wall" in Monoliths and Microservices

Thu, 22 Jan 2026 21:48:04 +0000

We’ve all been there. The logs say Connection Refused or the dreaded javax.net.ssl.SSLHandshakeException.

The network team swears the firewall is open. The platform team says the certificates are valid. The application team says "it works on my machine." And yet, your traffic is hitting an invisible wall.

I used to treat SSL/TLS errors as a "black box" mystery—restart the server and pray. But after years of debugging secure connections in enterprise integration (webMethods, Java, and now microservices), I’ve realized that the handshake isn't random. It’s a precise, step-by-step negotiation that fails for predictable reasons.

In this deep dive, I break down:

The Anatomy of the Fail: Where exactly the "Client Hello" or "Server Hello" dies.

The Certificate Chain of Trust: Why your root CA might be the silent killer.

Debug Tools: How to use openssl and JVM flags to see what’s actually happening on the wire.

Stop guessing. Here is how you actually debug the invisible wall.

The SSL Handshake Failed. Now What?

How to update SSL certificates through file upload in SafeLine WAF

Wed, 03 Dec 2025 03:49:25 +0000

Some users find it cumbersome to manually upload certificates through the interface when using Safeline WAF's SSL Cert feature.

They want to store certificate files in a fixed directory and have Safeline automatically detect and update them after overwriting, allowing the entire process to be completed through automation tools. Related issues include:

To solve or optimize the above issues, Safeline Community Edition launched the automatic certificate reading and updating feature in version 7.2.0. Below is an introduction to how to use this feature.

Prerequisites

WAF version >= 7.2.0

Upload Certificate Once

To let the WAF know that there are certificates that need periodic updates, you need to upload the certificate once in the WAF.

Get Certificate Path

By default, certificates are saved in /data/safeline/resources/nginx/certs

ls /data/safeline/resources/nginx/certs/ -lh
total 8.0K
-rw-r--r-- 1 root root 1.4K Nov 22 18:15 cert_1.crt
-rw-r--r-- 1 root root 1.7K Nov 22 18:15 cert_1.key

Update Certificates Using Files

You can use tools like certbot to apply for free certificates

After obtaining the certificates, simply overwrite the above files

WAF Automatic Updates

WAF refreshes certificate content every hour by default.

SafeLine Resources:
SafeLine Website: https://ly.safepoint.cloud/ShZAy9x
Live Demo: https://demo.waf.chaitin.com:9443/statistics
Discord: https://discord.gg/dy3JT7dkmY
Doc: https://docs.waf.chaitin.com/en/home
Github: https://github.com/chaitin/SafeLine

PostgreSQL Client Certificate Authentication: Complete Setup Guide

Fri, 01 Aug 2025 12:50:19 +0000

Client certificate authentication in PostgreSQL provides a secure, passwordless way to authenticate users. Instead of relying on passwords, clients present valid X.509 certificates to prove their identity.

What to Configure

Server-Side Requirements

SSL certificates: Server certificate + client certificates
PostgreSQL SSL settings: Enable SSL and configure certificate paths
Authentication rules: Configure pg_hba.conf for certificate-based auth
User mapping: Link certificate Common Names to database users

Client-Side Requirements

Client certificate: Valid X.509 certificate for the user
Private key: Matching private key for the certificate
Root certificate: Server's certificate for verification
Connection parameters: Proper SSL mode and certificate paths

How to Configure

1. Generate SSL Certificates

# Create SSL directory
mkdir -p /var/lib/postgresql/17/main/ssl
cd /var/lib/postgresql/17/main/ssl

# Generate server certificate
openssl genrsa -out server.key 4096
openssl req -new -key server.key -out server.csr \
  -subj "/C=US/ST=State/L=City/O=Org/OU=OrgUnit/CN=localhost"
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

# Generate client certificate for user 'appuser'
openssl genrsa -out appuser.key 4096
openssl req -new -key appuser.key -out appuser.csr \
  -subj "/C=US/ST=State/L=City/O=Org/OU=OrgUnit/CN=appuser"
openssl x509 -req -days 365 -in appuser.csr \
  -CA server.crt -CAkey server.key -CAcreateserial -out appuser.crt

# Set permissions
chown postgres:postgres *.crt *.key
chmod 600 *.key
chmod 644 *.crt

2. Configure PostgreSQL SSL Settings

Add to postgresql.conf:

# SSL Configuration
ssl = on
ssl_cert_file = '/var/lib/postgresql/17/main/ssl/server.crt'
ssl_key_file = '/var/lib/postgresql/17/main/ssl/server.key'
ssl_ca_file = '/var/lib/postgresql/17/main/ssl/server.crt'
ssl_prefer_server_ciphers = on
ssl_min_protocol_version = 'TLSv1.2'

3. Configure Authentication Rules

Update pg_hba.conf:

# SSL connections require client certificate authentication
hostssl all             all             0.0.0.0/0               cert clientcert=verify-full
hostssl all             all             ::/0                    cert clientcert=verify-full

# Non-SSL connections require password authentication
hostnossl all           all             0.0.0.0/0               scram-sha-256
hostnossl all           all             ::/0                    scram-sha-256

4. Create Database User

The database user must match the certificate's Common Name(CN):

CREATE USER appuser WITH LOGIN;
GRANT CONNECT ON DATABASE mydb TO appuser;
-- Grant additional permissions as needed

How to Connect from Client

Critical Connection Parameters

Parameter	Self-Managed Value	RDS Value	Purpose
`sslmode`	`require` or `verify-full`	`require` or `verify-full`	Force SSL connection
`sslcert`	`/path/to/client.crt`	N/A (not supported)	Client certificate file
`sslkey`	`/path/to/client.key`	N/A (not supported)	Client private key file
`sslrootcert`	`/path/to/server.crt`	`./global-bundle.pem`	Server certificate for verification
`host`	`localhost` or custom	`instance.region.rds.amazonaws.com`	Database server endpoint
`password`	Not required with client cert	Required (or IAM token)	Authentication credential

Connection Examples

Self-Managed PostgreSQL with Client Certificates

# psql - No password required
psql "host=localhost port=5432 dbname=mydb user=appuser \
      sslmode=require \
      sslcert=./certs/appuser.crt \
      sslkey=./certs/appuser.key \
      sslrootcert=./certs/server.crt"

// .NET - Client certificate authentication
var connectionString = "Host=localhost;Port=5432;Database=mydb;Username=appuser;" +
                      "SSL Mode=Require;" +
                      "Client Certificate=./certs/appuser.crt;" +
                      "Client Key=./certs/appuser.key;" +
                      "Root Certificate=./certs/server.crt;";

# Python - Client certificate authentication
import psycopg2
conn = psycopg2.connect(
    host="localhost",
    port=5432,
    database="mydb",
    user="appuser",
    sslmode="require",
    sslcert="./certs/appuser.crt",
    sslkey="./certs/appuser.key",
    sslrootcert="./certs/server.crt"
)

// Java JDBC - Client certificate authentication
String url = "jdbc:postgresql://localhost:5432/mydb" +
            "?ssl=true" +
            "&sslmode=require" +
            "&sslcert=./certs/appuser.crt" +
            "&sslkey=./certs/appuser.key" +
            "&sslrootcert=./certs/server.crt" +
            "&user=appuser";

Connection conn = DriverManager.getConnection(url);

AWS RDS PostgreSQL with SSL (Password Required)

# psql - Password required, verify server certificate
psql "host=mydb.cluster-xyz.us-east-1.rds.amazonaws.com \
      port=5432 dbname=postgres user=myuser password=mypassword \
      sslmode=verify-full sslrootcert=./global-bundle.pem"

// .NET - RDS with SSL verification
var connectionString = "Host=mydb.cluster-xyz.us-east-1.rds.amazonaws.com;" +
                      "Port=5432;Database=postgres;Username=myuser;Password=mypassword;" +
                      "SSL Mode=Require;Root Certificate=./global-bundle.pem;";

# Python - RDS with SSL verification  
import psycopg2
conn = psycopg2.connect(
    host="mydb.cluster-xyz.us-east-1.rds.amazonaws.com",
    port=5432,
    database="postgres",
    user="myuser",
    password="mypassword",
    sslmode="verify-full",
    sslrootcert="./global-bundle.pem"
)

// Java JDBC - RDS with SSL verification
String url = "jdbc:postgresql://mydb.cluster-xyz.us-east-1.rds.amazonaws.com:5432/postgres" +
            "?ssl=true" +
            "&sslmode=verify-full" +
            "&sslrootcert=./global-bundle.pem" +
            "&user=myuser" +
            "&password=mypassword";

Connection conn = DriverManager.getConnection(url);

Server Configuration vs Client Parameters

Server Side (`pg_hba.conf`)

# Authentication method MUST be 'cert'
hostssl all all 0.0.0.0/0 cert clientcert=verify-full

Client Side (Connection String)

# SSL mode MUST be 'require' or 'verify-full'
sslmode=require
# All three certificate files MUST be provided
sslcert=./client.crt
sslkey=./client.key  
sslrootcert=./server.crt

Common Pitfalls

Certificate CN mismatch: Client certificate CN must match database username
Missing clientcert=verify-full: Server won't require client certificates
Wrong SSL mode: sslmode=disable or prefer may skip certificate auth
File permissions: Private keys must be readable only by the client process
Certificate expiration: Monitor and rotate certificates before expiry

Security Benefits

No password transmission: Eliminates password-based attacks
Strong authentication: Based on cryptographic proof of identity
Non-repudiation: Certificate-based audit trails
Mutual authentication: Both client and server verify each other

AWS RDS PostgreSQL Configuration

RDS Limitations for Client Certificates

AWS RDS PostgreSQL has limited support for client certificate authentication compared to self-managed PostgreSQL:

What's NOT Available in RDS

Custom client certificate generation: You cannot upload custom client certificates
Full cert authentication method: RDS doesn't support the cert method in pg_hba.conf
Direct certificate file access: No access to /var/lib/postgresql/ directory

What IS Available in RDS

1. RDS SSL Server Certificates & Configuration

# Download RDS CA certificate bundle
wget https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

# Enable SSL in RDS parameter group
aws rds modify-db-parameter-group \
    --db-parameter-group-name mygroup \
    --parameters "ParameterName=ssl,ParameterValue=1,ApplyMethod=immediate"

2. Alternative: IAM Database Authentication

For passwordless authentication in RDS, use IAM database authentication:

-- Create IAM-enabled database user
CREATE USER iamuser;
GRANT rds_iam TO iamuser;
GRANT CONNECT ON DATABASE postgres TO iamuser;

# Connect using IAM token (Python example)
import boto3
import psycopg2

rds_client = boto3.client('rds', region_name='us-east-1')
token = rds_client.generate_db_auth_token(
    DBHostname='mydb.xyz.us-east-1.rds.amazonaws.com',
    Port=5432,
    DBUsername='iamuser'
)

conn = psycopg2.connect(
    host="mydb.xyz.us-east-1.rds.amazonaws.com",
    port=5432,
    database="postgres",
    user="iamuser",
    password=token,  # IAM token as password
    sslmode="require",
    sslrootcert="./global-bundle.pem"
)

3. Hybrid Approach: ALB + Client Certificates + RDS

For applications requiring client certificate authentication with RDS:

[Client with Client Cert] → [ALB with SSL termination] → [App Server] → [RDS with IAM Auth]

ALB handles client certificate verification
Application validates certificates in code
RDS connection uses IAM authentication

Summary & Verification

Self-Managed vs AWS RDS Comparison

Feature	Self-Managed	AWS RDS
Client Certificate Auth	✅ Full support	❌ Not supported
Server SSL Certificates	✅ Custom certificates	✅ AWS-managed certificates
Passwordless Authentication	✅ Client certificates	✅ IAM authentication
Certificate Management	❌ Manual rotation	✅ Automatic rotation
SSL Configuration Control	✅ Full control	❌ Limited parameters

Verification Commands

-- Verify SSL is enabled
SHOW ssl;

-- Check active SSL connections with certificate details
SELECT datname, usename, client_addr, ssl, ssl_version, ssl_cipher,
       client_dn, issuer_dn
FROM pg_stat_ssl 
JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid 
WHERE ssl = true;
-- Example output
pid|ssl |version|cipher                |bits|client_dn                                                      |client_serial                                   |issuer_dn                                                   |datid|datname       |pid|leader_pid|usesysid|usename       |application_name|client_addr|client_hostname|client_port|backend_start                |xact_start|query_start                  |state_change                 |wait_event_type|wait_event|state|backend_xid|backend_xmin|query_id           |query                                                                                                                        |backend_type  |
---+----+-------+----------------------+----+---------------------------------------------------------------+------------------------------------------------+------------------------------------------------------------+-----+--------------+---+----------+--------+--------------+----------------+-----------+---------------+-----------+-----------------------------+----------+-----------------------------+-----------------------------+---------------+----------+-----+-----------+------------+-------------------+-----------------------------------------------------------------------------------------------------------------------------+--------------+
754|true|TLSv1.3|TLS_AES_256_GCM_SHA384| 256|/C=US/ST=State/L=City/O=Organization/OU=OrgUnit/CN=redgatemonit|608692775915102986323080169170088721995325147053|/C=US/ST=State/L=City/O=Organization/OU=OrgUnit/CN=localhost|16384|redgatemonitor|754|          |   16385|redgatemonitor|psql            |10.88.0.1  |               |      59168|2025-07-30 09:43:20.240 +0100|          |2025-07-30 09:43:58.869 +0100|2025-07-30 09:43:58.870 +0100|Client         |ClientRead|idle |           |            |8885888923103386772|SELECT datname, usename, client_addr, ssl,* FROM pg_stat_ssl JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid;|client backend|

Key Takeaways

Self-managed PostgreSQL: Use client certificates for true passwordless authentication
AWS RDS: Combine IAM authentication with SSL encryption for secure connections
Hybrid approach: Use ALB for client certificate verification with RDS backend
Security: Both approaches provide enterprise-grade security with different trade-offs

Client certificate authentication in PostgreSQL provides enterprise-grade security without the overhead of password management, making it ideal for automated systems and high-security environments.

References

https://www.postgresql.org/docs/current/ssl-tcp.html