How to Fix SEC_ERROR_CERT_ALTNAME_INVALID in Mozilla Firefox: Complete Diagnostic Guide

When Mozilla Firefox aborts an HTTPS connection with the security alert SEC_ERROR_CERT_ALTNAME_INVALID, the browser’s NSS (Network Security Services) cryptographic engine has determined that the requested domain name is completely absent from the Subject Alternative Name (SAN) extension embedded in the server’s X.509 certificate.

While visually similar to generic domain mismatches, SEC_ERROR_CERT_ALTNAME_INVALID is specifically triggered by RFC 5280 / RFC 6125 compliance failures:

1. The web server presented a certificate that lacks modern X509v3 Subject Alternative Name DNS entries entirely.
2. The domain is an Internationalized Domain Name (IDN, such as Urdu script .pk domains) where the certificate was issued to the Unicode representation rather than the standardized Punycode (ACE) format (xn--...).
3. An improper wildcard scope was applied (e.g., trying to use *.example.com.pk to match nested multi-level subdomains like app.portal.example.com.pk).

Operating enterprise web applications on properly configured Dedicated Servers in Pakistan and Dedicated Servers ensures that automated ACME certificate clients package all apex, wildcard, and internationalized domain SANs correctly.

---

Understanding the Mechanics of SAN Validation in Firefox

Under RFC 6125, modern browsers ignore the legacy certificate Common Name (CN) attribute if the Subject Alternative Name extension is present. Furthermore, if a certificate lacks the SAN extension entirely, modern Firefox builds reject it immediately with SEC_ERROR_CERT_ALTNAME_INVALID.

[ Client: Firefox Address Bar ]
Requested FQDN: https://admin.store.example.com.pk
                     |
                     v
[ TLS Handshake: Server Presents Certificate ]
SAN Entries in Certificate:
- DNS: example.com.pk
- DNS: *.example.com.pk (Single-level wildcard only matches: store.example.com.pk!)
                     |
                     v
[ NSS RFC 6125 Wildcard Matching Engine ]
Wildcard '*' CANNOT match multi-level dot: "admin.store"
                     |
                     v
[ ERROR: SEC_ERROR_CERT_ALTNAME_INVALID ]

For webmasters diagnosing related browser certificate exceptions, explore our diagnostic tutorials on How to Fix SSL_ERROR_BAD_CERT_DOMAIN in Mozilla Firefox, How to Fix SEC_ERROR_UNTRUSTED_CERT in Mozilla Firefox, and How to Fix SEC_ERROR_INVALID_KEY in Mozilla Firefox.

---

Step 1: Command-Line SAN Diagnosis with OpenSSL

Do not rely on browser alerts. Run an active OpenSSL handshake inspection from your terminal to inspect the exact SAN array:

# Extract Subject Alternative Name extension records
openssl s_client -connect yourdomain.pk:443 -servername yourdomain.pk </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Examine the output:

X509v3 Subject Alternative Name: 
    DNS:yourdomain.pk, DNS:www.yourdomain.pk

If you attempted to access portal.yourdomain.pk, but portal.yourdomain.pk is not explicitly listed in the SAN block, Firefox triggers SEC_ERROR_CERT_ALTNAME_INVALID.

---

Root Cause 1: Multi-Level Wildcard Mismatch

A standard wildcard certificate issued for *.yourdomain.pk matches only one level of subdomains:

• store.yourdomain.pk $\to$ Valid Match
• mail.yourdomain.pk $\to$ Valid Match
• api.staging.yourdomain.pk $\to$ INVALID! (Two levels of dots cannot be matched by a single wildcard according to RFC 6125 §6.4.3).

Solution:

Issue a certificate specifically containing the nested subdomain level:

# Certbot command to include nested subdomain SANs
certbot certonly --nginx -d "yourdomain.pk" -d "*.yourdomain.pk" -d "*.staging.yourdomain.pk"

---

Root Cause 2: Internationalized Domain Names (IDN) and Punycode

In Pakistan, organizations increasingly register localized Urdu or Arabic script .pk domains. If you issue an SSL certificate using raw UTF-8 Unicode characters (e.g., پاکستان.pk), TLS clients fail because certificates require the ASCII-Compatible Encoding (Punycode) format.

Punycode Transformation:

• Unicode: پاکستان.pk
• Punycode ACE: xn--mgbpl2fh.pk

When requesting a certificate via Certbot or OpenSSL, always specify the Punycode domain name in the SAN parameter:

# Issue certificate using standardized Punycode SAN
certbot certonly --nginx -d "xn--mgbpl2fh.pk" -d "www.xn--mgbpl2fh.pk"

In your Nginx virtual host configuration:

server {
    listen 443 ssl http2;
    server_name xn--mgbpl2fh.pk www.xn--mgbpl2fh.pk;

    ssl_certificate /etc/letsencrypt/live/xn--mgbpl2fh.pk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/xn--mgbpl2fh.pk/privkey.pem;

    root /var/www/pakistan_pk;
}

---

Root Cause 3: IP Address Accessed Directly via HTTPS

When users or API clients connect directly via IP address (e.g., https://103.151.46.22), standard SSL certificates issued only to domain names fail because the SAN list contains only DNS: entries, not IP: entries.

To issue a valid IP-based SSL certificate using OpenSSL:

Create an OpenSSL configuration file san_ip.cnf:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
CN = 103.151.46.22

[v3_req]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
IP.1 = 103.151.46.22

Generate the certificate:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/ssl/private/server_ip.key \
  -out /etc/ssl/certs/server_ip.crt \
  -config san_ip.cnf

---

Step 2: Verifying Server Name Indication (SNI) Fallbacks

If your SAN attributes are correct in the certificate file, but Firefox still receives SEC_ERROR_CERT_ALTNAME_INVALID, Nginx or Apache is routing the connection to the default virtual host due to an unmatched server_name.

Verify that your Nginx virtual host explicitly enumerates all aliases:

server {
    listen 443 ssl http2;
    server_name yourdomain.pk www.yourdomain.pk admin.yourdomain.pk;

    ssl_certificate /etc/letsencrypt/live/yourdomain.pk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.pk/privkey.pem;
}

Reload Nginx:

nginx -t && systemctl reload nginx

Test with verbose cURL specifying the exact SNI hostname:

curl -Iv https://yourdomain.pk

Confirm that the output reports SSL certificate verify ok, ensuring seamless access across Mozilla Firefox with zero security alerts.

---