Securing IP Addresses with SSL/TLS Certificates

Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are protocols that provide a secure connection between a web server and a client. Traditionally, SSL/TLS certificates are associated with domain names (like www.example.com). However, it is possible to issue and use certificates directly bound to an IP address. This tutorial will explore the concept, the reasons you might want to do this, and the considerations involved.

Why Secure an IP Address?

The most common use case for SSL/TLS is securing web traffic accessed via domain names. However, there are specific scenarios where securing an IP address directly is beneficial:

Direct IP Access: If you are accessing a service directly via its IP address (e.g., https://192.0.2.2), a certificate allows for a secure, encrypted connection. This might be used for internal services, testing environments, or specific applications where a domain name isn’t desired or feasible.
Avoiding DNS Lookups: While the performance impact of DNS lookups is often minimal due to caching, in certain performance-critical applications, removing this step can be advantageous. Direct access via IP, secured with a certificate, eliminates the DNS resolution process.
Internal Infrastructure: Securing internal network services using IP addresses can enhance security and prevent man-in-the-middle attacks within a controlled environment.

How it Works: Certificates and IP Addresses

SSL/TLS certificates typically bind a public key to a domain name. However, the certificate’s Subject Alternative Name (SAN) field can include IP addresses in addition to (or instead of) domain names. This is the key to securing an IP address with a certificate.

When a client connects to an IP address secured with a certificate, the server presents the certificate. The client verifies the certificate’s validity and confirms that the IP address the client connected to matches an IP address listed in the certificate’s SAN field. If validation succeeds, a secure connection is established.

Obtaining a Certificate for an IP Address

Traditionally, Certificate Authorities (CAs) prioritized issuing certificates for domain names. However, most CAs now do support issuing certificates with IP addresses listed in the SAN field.

Here’s what you need to do:

Generate a Certificate Signing Request (CSR): When creating the CSR, specify the IP address as the Common Name (CN) and include it in the SAN field. The SAN field is crucial; simply putting the IP in the CN might not be sufficient for older systems or browsers.
Submit the CSR to a CA: Choose a CA that supports IP address certificates. You’ll need to provide validation information to prove you control the IP address (e.g., whois records, documentation, or access to the server).
Install the Certificate: Once the CA issues the certificate, install it on your server. You’ll also need to configure your web server (e.g., Apache, Nginx) to use the certificate and the corresponding private key.

Example: Generating a Self-Signed Certificate with IP Addresses (for testing)

For development and testing purposes, you can generate a self-signed certificate with IP addresses. Be aware that self-signed certificates are not trusted by default by browsers and require manual configuration or whitelisting.

Here’s a Bash script demonstrating how to do this using OpenSSL:

#!/bin/bash
#using: OpenSSL 1.1.1c FIPS  28 May 2019 / CentOS Linux release 8.2.2004

C=US ; ST=Confusion ; L=Anywhere ; O=Private\ Subnet ; [email protected]
BITS=2048
CN=RFC1918
DOM=company.com
SUBJ="/C=$C/ST=$ST/L=$L/O=$O/CN=$CN.$DOM"

openssl genrsa -out ip.key $BITS

SAN='\n[SAN]\nsubjectAltName=IP:192.168.1.0,IP:192.168.1.1,IP:192.168.1.2,IP:192.168.1.3,IP:192.168.1.4,IP:192.168.1.5,IP:192.168.1.6,IP:192.168.1.7,IP:192.168.1.8,IP:192.168.1.9,IP:192.168.1.10'

cp /etc/pki/tls/openssl.cnf /tmp/openssl.cnf
echo -e "$SAN" >> /tmp/openssl.cnf

openssl req -subj "$SUBJ" -new -x509 -days 10950 \
    -key ip.key -out ip.crt -batch \
    -set_serial 168933982 \
    -config /tmp/openssl.cnf \
    -extensions SAN

openssl x509 -in ip.crt -noout -text

This script generates a private key (ip.key) and a self-signed certificate (ip.crt) valid for 10950 days, including the specified IP addresses in the Subject Alternative Name.

Important Considerations

Compatibility: Older systems (especially those running older versions of Windows) might have compatibility issues with certificates using IP addresses, even if the SAN field is correctly populated. Thorough testing is crucial.
Reserved IP Addresses: Certificate Authorities will not issue certificates for reserved or private IP address ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). You must use a public, routable IP address.
Security Best Practices: Even when using certificates for IP addresses, follow general security best practices, such as keeping your private keys secure, using strong encryption algorithms, and regularly updating your software.
Use with Caution: Avoid using this technique for public-facing services that require high trust and security. Consider the implications of providing a certificate for an IP address when users expect a domain name.