17

Is it possible to create a SSL (self-signed) certificate by specifying IP range in the SAN section of OpenSSL conf like this?

IP.1=192.168.0.0/24

3 Answers 3

15

No

(EDIT: This was a much longer post. I was speculating about wildcards. Turns out: It's much simpler.)

You can't do it.

RFC 5280 says:

When the subjectAltName extension contains an iPAddress, the address
MUST be stored in the octet string in "network byte order", as
specified in [RFC791].  The least significant bit (LSB) of each octet
is the LSB of the corresponding byte in the network address.  For IP
version 4, as specified in [RFC791], the octet string MUST contain
exactly four octets.  For IP version 6, as specified in
[RFC2460], the octet string MUST contain exactly sixteen octets.

So there is just no room for any wildcards.

Note:
Now in the past there was a way to put an IP address in a SAN field of type DNS (!). This was always dodgy. But there at least, you might have had the additional room for wildcarding tricks.

7
  • @StackOfZtuff Thanks for the answer. Looks like wildcards are not supported. I got this error when I tried using wildcards: Error Loading extension section x509_ext 2115:error:22075076:X509 V3 routines:v2i_GENERAL_NAME_ex:bad ip address:/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/x509v3/v3_alt.c:484:value=192.168.0.* Using a range like IP.1=192.168.0.0/24 doesn't throw an error but the IP is taken as just 192.168.0.0. Jun 11, 2015 at 6:27
  • Okay, I understand that you can't use wildcards. But coming back to my original question, I was expecting more of specifying the ip range like 192.168.0.0/24. Can someone throw light on this? Jun 11, 2015 at 8:26
  • No. There is no way to store that /24 information in the cert in a ipAddress typed SAN field. You just get the 4 bytes. There is no extra room to hold /24. Jun 11, 2015 at 8:48
  • Thanks. Looks like the only way to support IP range is to specify it in CN and validate it at the client yourself. Jun 11, 2015 at 8:59
  • That's one way. Another way might be to put it in an otherName typed SAN field. There you get to decide on your own semantics. Jun 11, 2015 at 9:20
3

Firstly, it is possible to hold 192.168.0.0/24 in the SubjectAltName Field. However, this kind of certificate is not being trusted by any browser.

I will give you an example:
Here's a certificate issued from my own PKI.

RSA-2048 Certificate

-----BEGIN CERTIFICATE-----
MIIFcDCCBFigAwIBAgIQHrEy1YnIzRfZZ/QkuWlcYDANBgkqhkiG9w0BAQsFADCB
gTELMAkGA1UEBhMCQ04xIzAhBgNVBAoMGkplbW15TG92ZUplbm55IFBLSSBTZXJ2
aWNlMR4wHAYDVQQLDBVwa2kuamVtbXlsb3ZlamVubnkudGsxLTArBgNVBAMMJEpl
bW15TG92ZUplbm55IFNIQTIgU2VjdXJlIFNlcnZlciBDQTAeFw0xODAxMDEwMDAw
MDBaFw0xOTEyMzEyMzU5NTlaMF4xGTAXBgNVBAsMEFRlc3QgQ2VydGlmaWNhdGUx
GzAZBgNVBAoMEkxvY2FsIEFyZWEgTmV0d29yazEkMCIGA1UEAwwbSVAgUmFuZ2Ug
aW4gU3ViamVjdEFsdE5hbWVzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAtMfwk/HrSvX9TmqLlXLDVAdrLPkcAxIvvYPH1rgFXzRc3Hst2ekFLUs8CNF/
WhTk+/agE6lJ9uiRtROiWPvOdDY/X7buqEr7HOknPpoViLv+qs9Fv8MVljS/Y0m8
lwbrPNTkUxp6lMEwAFiaZJDx/LxzODAC2vI3CocNGDK+FnsrWcw6ndl/nfjd0Yea
pIcyP7aMXw4mQCqJL2E0cBodNMcfDt9N10mMTkyR1HMGeq345R/R4V5uW1YG5heK
uM0dguujK506w/Y659/copLTBVGj7y4GppOB/nEs5BpeSSrrwa+0tPJZOulCO31D
WnkckimSQItD6x0J3dt9B/JprwIDAQABo4ICBDCCAgAwHwYDVR0jBBgwFoAU4BPp
j9H7K19wMi69RQ9t6BLyNOcwHQYDVR0OBBYEFB7paxWN91FXk0Ydj4Oq1Sopdy8Y
MBMGA1UdEQQMMAqHCMCoAAD///8AMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwSQYDVR0fBEIwQDA+oDygOoY4aHR0cDovL2Ny
bHMucGtpLmplbW15bG92ZWplbm55LnRrL1NIQTJTZWN1cmVTZXJ2ZXJDQS5jcmww
gYIGA1UdIAR7MHkwbQYJYIZIAaSiJwECMGAwLQYIKwYBBQUHAgEWIWh0dHBzOi8v
cGtpLmplbW15bG92ZWplbm55LnRrL2NwczAvBggrBgEFBQcCAjAjGiFodHRwczov
L3BraS5qZW1teWxvdmVqZW5ueS50ay9ycGEwCAYGZ4EMAQIBMIGbBggrBgEFBQcB
AQSBjjCBizBABggrBgEFBQcwAYY0aHR0cDovL29jc3AucGtpLmplbW15bG92ZWpl
bm55LnRrL1NIQTJTZWN1cmVTZXJ2ZXJDQTBHBggrBgEFBQcwAoY7aHR0cDovL2Nh
Y2VydHMucGtpLmplbW15bG92ZWplbm55LnRrL1NIQTJTZWN1cmVTZXJ2ZXJDQS5j
cnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAGYh4L1aVt+0qHWqB
NsW7CrC4GzfvA/+sEbWT+K9QjSc3lXwG2KA4YHfpOUaB8Qh8sv34Zubu1jYvDmRz
EiWFuieQGfC+FKUTbAEjfT5tGKKaYm9P3URAi80wXAl7ysQcEJuEaJMCeayaaW1x
PvARJovPoxKlmU8o7wBWCo5ji3R/5UFa4o4XtP1WFBliP3zDxJ1kBKPsQV3g2/98
9ar8REbX6Cw1XcXYXrJtUIQVl/9p0UmATIaCDS6Bk/Fesg9Lt6ngbiuDYNuvvPwu
jw8dH+ycOvG2QvbDrzqZnx7ZpVZtuTQ4cBf5hMPnDqCq/yHEFr/CO+zf4awAnjho
cjwzhQ==
-----END CERTIFICATE-----

RSA-2048 Key

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAtMfwk/HrSvX9TmqLlXLDVAdrLPkcAxIvvYPH1rgFXzRc3Hst
2ekFLUs8CNF/WhTk+/agE6lJ9uiRtROiWPvOdDY/X7buqEr7HOknPpoViLv+qs9F
v8MVljS/Y0m8lwbrPNTkUxp6lMEwAFiaZJDx/LxzODAC2vI3CocNGDK+FnsrWcw6
ndl/nfjd0YeapIcyP7aMXw4mQCqJL2E0cBodNMcfDt9N10mMTkyR1HMGeq345R/R
4V5uW1YG5heKuM0dguujK506w/Y659/copLTBVGj7y4GppOB/nEs5BpeSSrrwa+0
tPJZOulCO31DWnkckimSQItD6x0J3dt9B/JprwIDAQABAoIBAQCnuakXWig3kCrI
CkofCi73Uzq4qxa2MrVgW1eZe3pgbjCJzy8nMe6/q0Gz3MsPRLt+mb7C/xnEntow
6lqBvH47i+kYYJzkP0zj8d2bU1IPXnxU9aF83P62MZIwCEWUybKO6eY8xCBeyy5B
4/K6w1AAcMdlpgXAJWGzvsEDZnC+YVAlqu8ARiGi5cvYS6sflsw5JezR6Ur+Rbd8
GIIj6+pDBR6ksiOiVLHgs5a7T1KH0rriYmB64nNw7o+4oGub2/E223qVwWfyM8Wq
KRIGV0lgDexqP2v1ayqMvSQRJQ28QqmtMChVje/OXGnYWqbGHVvUV3kWoqonT9e9
AAFSHmYBAoGBAOZKRMXgbqEzFa/4qqqVwnQ1aunu/3cpuLp4fiYhoSTIPfR/+Gzf
2uJove2518h1oNS/wJ7I0RUfLdYzv8MRB6vkSLRitMrdxhyY3RRhP0GST+hDhsBa
BSL1vG3mA6uILGWIf0bUrFa+7+LEZW5AuDR6XCYCqQ0n+ntox8onJq7vAoGBAMj2
sUlG0YG0GP3Ke521VbGPrxbTmHkhhd/idGJf/tA+7thd0uu51+b0zxgKwBl2JnEa
yljH3xXBdj7YtMIQHrajnlQ/Ib1nMPG0njCwTZc+zXk3GPnJb5G1fvgoeQVNjCpw
yll5cxqqrFuwiSAfv5W3bKGvqZdWSIDUVKlan/FBAoGAGaMrBNx3dHq7b1u/pD4H
5+gKfwCccCe06Q2A/b3AsteYDiAxB+3j8FC41D5cR3TQ8t5mE0dH/5H5CF+6eXzr
3bcMYQicF/mYlJZwBlTNNf+T5ceeuMtMxxeUYqe4wN/oEWWgxcHnbcDT8+rpX9zU
pQL6P0EMkOpieFqx4094fwECgYAYw62dJgjzPspFnAoXqRziQJ6G5ZRIeQUSTcmh
xcqUxuyP5R/0xHYCk/BhOhHqEVEzZuXAgwDOoYR8wh+kOnBOeWMtZoo12N2DK4rC
3TbyiF6xrUR6o4QIJKF82x/us1uuby/ATuMMSjPrKJn9R2xIes38LrVrXMqadY/p
Pq2vAQKBgQCSd5d/UD9Bt3AoD7+hASy4ZHnayVMG0jukY/bOnzAzX1jkzxuUFy27
fmYWqxp+5G9OxBVj3NK3HGZAGPd8JgnVyAdAJb6FufFf0FvASqOqIhno306BenvX
KX9iEqzmLmj86wyLKUgqBOsHf8kPECscD5SNRwaX6Px6p+UZ8QA+sg==
-----END RSA PRIVATE KEY-----

Viewing this certificate in Windows 10, you can find

IP Address=192.168.0.0
Mask=255.255.255.0

In the Subject Alternative Name Field, which proved that SubjectAltName can be a range of IPs.

This kind of not trusted at all!
You can try it by yourself:
Deploy this certificate on a machine whose IP is in the range from 192.168.0.1~192.168.0.254. And trust my root certificate in your computer (My root certificate can be found in the cert path, whose name is JemmyLoveJenny EV Root CA)

I've tried many times, no matter I use IE, Edge, Chrome or FireFox, none of them trust this certificate. The error code returned is "NET::ERR_CERT_COMMON_NAME_INVALID", which means neither the CommonName nor the SubjectAltName matches the IP 192.168.0.1.

In conclusion, it is possible to embed range of IPs in the SubjectAltNames Field. But none of the modern browsers would trust this kind of certificate.

2
  • 1
    No, that proves both you and Microsoft are pants at standards; the latter everyone has known for 30 years. The format you use is correct for NameConstraints, but not SubjectAltName (and NameConstraints isn't valid in an EE cert). Dec 17, 2018 at 8:17
  • 1
    Thank you very much for taking time to write a detailed answer. Maybe what you suggested can be used in a non-browser environment where application components exchange certs. Jan 11, 2019 at 3:58
2

To add to what StackzOfZtuff said, you can't have a range of IP addresses in a cert. But you can have multiple IP addresses there. So put the entire range of addresses in the cert. I'm unsure of what the upper limit is, but it's something greater than 254 IPv4 addresses. It's not technically a network range (there is no wildcard) but you get the same benefit, one cert for multiple IPs. I did some testing with this OpenSSL configuration file to generate a CSR and I had it signed by an internal CA:

req_extensions = v3_req
distinguished_name = req_distinguished_name
default_bits = 4096
default_md = sha256
prompt = no
[req_distinguished_name]
C = ...
ST = ...
L = ...
OU = ...
O = ...
CN = 192.168.0.0

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName = @alt_names
[alt_names]
IP.1 = 192.168.0.1
IP.2 = 192.168.0.2
IP.3 = 192.168.0.3
...
IP.254 = 192.168.0.254

Firefox and Chrome were both happy with the generated certificate. The CA admin also added DNS.1 = 192.168.0.0 while signing it. I'm not positive if that was strictly required or not.

1
  • 5280 doesn't require it. CABforum does require the CN value be present in SAN -- BR 7.1.4.2.2 a -- but it prohibits both CN and all SAN from being a 'reserved' IP address (which includes RFC1918) or 'internal' name (not under a real, public TLD) -- 7.1.4.2.1 a. Feb 5, 2020 at 3:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .