Scenario

A minimal HTTPS webserver script (webserver.sh) listening on port 8443 fails to establish secure connections. The bundled SSL certificate (old_server.crt) lacks a Subject Alternative Name (SAN) for the local IP 127.0.0.1, causing hostname verification failures.

Task

Run the broken server and inspect the certificate to confirm the missing SAN. Generate a new self-signed certificate with SAN set to IP:127.0.0.1 and save it as server.crt and server.key. Update webserver.sh to use the new certificate files, launch the fixed server, and verify connectivity.

Example

# Before (Missing SAN)
subject=CN = wrong.example.com
curl: (60) SSL: no alternative certificate subject name matches target host name '1.1.1.1'

# After (SAN Present)
subject=CN = example
X509v3 Subject Alternative Name: IP Address:1.1.1.1
Hello World

Step 1: Launch the broken server

chmod +x webserver.sh
./webserver.sh &
sleep 2

Make the script executable and start it in the background.

Step 2: Capture the invalid certificate subject

echo "Q" | openssl s_client -connect 127.0.0.1:8443 2>/dev/null | grep "subject="

Identify the Subject line from the running server to verify it lacks proper SAN.

Step 3: Stop the broken server

pkill -f webserver.sh
pkill -f openssl

Kill the script and openssl process to free port 8443.

Step 4: Generate the new certificate with SAN

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout server.key -out server.crt \
  -subj "/CN=localhost" \
  -addext "subjectAltName=IP:127.0.0.1" \
  -days 365

Create a self-signed certificate with SAN explicitly set to IP:127.0.0.1. Modern browsers and tools require SAN instead of CN for hostname verification.

Step 5: Update the script

sed -i 's/old_server.crt/server.crt/g' webserver.sh
sed -i 's/old_server.key/server.key/g' webserver.sh

Replace old certificate references with new ones.

Step 6: Launch the fixed server

./webserver.sh &
sleep 2

Start the updated server with the new certificate.