Private SSL 102 - The Ultimate Guide to Getting an SSL Certificate for an IP Address

1. The Challenge: Why Public CAs Won’t Issue Certs for Private IPs

Public Certificate Authorities (CAs) like DigiCert and Let's Encrypt are prohibited from issuing SSL certificates for private IP addresses (e.g., 192.168.x.x, 10.x.x.x, 127.0.0.1) due to CA/Browser Forum restrictions. These IPs are not publicly resolvable, making them ineligible for public validation.

This leaves IT administrators with a gap: how to secure internal servers and devices that operate solely on IP addresses?

2. Understanding Subject Alternative Names (SANs) for IP Addresses

To secure an IP address with SSL, it must be explicitly listed in the Subject Alternative Name (SAN) field of the certificate. This ensures that browsers and applications recognize the certificate as valid for that IP.

Example SAN entry:

[alt_names]
IP.1 = 192.168.1.100
DNS.1 = 192.168.1.100

Without this, even a valid certificate will trigger trust errors.

3. Solution: Using a Private Certificate Authority (CA)

How a Private CA Solves the IP Address Problem

A private CA like SecureNT allows you to:

• Issue certificates for internal IPs, localhost, and server names
• Avoid trust errors by distributing your own root certificate
• Maintain full control over certificate lifecycle
• Secure internal traffic without exposing endpoints to the internet

SecureNT is designed specifically for internal networks, making it ideal for this use case.

4. Step-by-Step Guide: Generating a CSR for an IP Address

Step 1: Create a config file (ip-ssl.cnf)

[req]
default_bits       = 2048
prompt             = no
default_md         = sha256
req_extensions     = req_ext
distinguished_name = dn

[dn]
CN = 192.168.1.100
O = YourCompany
OU = IT
L = Atlanta
ST = Georgia
C = US

[req_ext]
subjectAltName = @alt_names

[alt_names]
IP.1 = 192.168.1.100
DNS.1 = 192.168.1.100

Step 2: Generate the CSR and key

openssl req -new -nodes -out ip.csr -newkey rsa:2048 -keyout ip.key -config ip-ssl.cnf

5. Step-by-Step Guide: Issuing the Certificate from Your Private CA (SecureNT)

1. Visit intranetssl.net
2. Specify the IP address and submit CSR (or specify Auto-CSR generation)
3. SecureNT issues a certificate bundle including:
   • server.cer (SSL certificate)
   • SecureNT Intranet Root CA.cer
   • SecureNT Intranet Intermediate CA.cer
   • Certificate in .p7b format (or .pfx format for Auto-CSR)

6. Installation and Configuration Examples

Apache

SSLEngine on
SSLCertificateFile /etc/ssl/certs/ip.crt
SSLCertificateKeyFile /etc/ssl/private/ip.key
SSLCertificateChainFile /etc/ssl/certs/rootCA.crt

Nginx

server {
    listen 443 ssl;
    server_name 192.168.1.100;

    ssl_certificate /etc/nginx/ssl/ip.crt;
    ssl_certificate_key /etc/nginx/ssl/ip.key;
    ssl_trusted_certificate /etc/nginx/ssl/rootCA.crt;
}

Windows Server / IIS

• Import .pfx via IIS Manager
• Bind to IP in site bindings

7. Installing SecureNT CA Certificates on Client Devices

To avoid browser trust errors, SecureNT’s Root and Intermediate CA certificates must be installed on all client devices accessing the internal IP.

Windows

• Right-click .cer files → Install Certificate
• Choose “Local Machine” → “Trusted Root Certification Authorities” and “Intermediate Certification Authorities”

macOS

• Double-click .cer → Keychain Access
• Add to “System” keychain and set to “Always Trust”

Android

• Settings → Security → Encryption & Credentials → Install from storage → CA Certificate

Firefox (Windows 11)

• Settings → Privacy & Security → Certificates → View Certificates
• Import via “Authorities” tab or enable security.enterprise_roots.enabled

For bulk deployment, use Microsoft Group Policy or MDM tools.

8. Verifying Your IP Address SSL Installation

• Use openssl s_client -connect 192.168.1.100:443
• Test in browser (ensure CA is installed)
• Check for padlock and no warnings

🔒 Conclusion: Secure Every Endpoint, Not Just Domain Names

Internal IPs are critical to your infrastructure. With SecureNT, you can encrypt every endpoint—whether it’s a dev server, microservice, or legacy device—and ensure trust across your organization.