0

How do we remove the incorrect banner about the duplicate question?

This question is not a duplicate of Why does requestjs reject a self-signed SSL certificate that works with Firefox?. While the answer to that question may result in a similar config file, that question was not using DNS: in the subjectAltName. This is a key point because all of the examples we can easily find with Google are using DNS:, which doesn't work for IP addresses.

This question is not a duplicate of Exception on using IP address in certificate name. While the answer to that question may result in a similar config file, that question was missing subjectAltName altogether.

This question is also not a duplicate of Using ip address for common name in server certificate does not work in Android? for the same reason.

Back to the actual question

I want to write an SSL server that responds to both localhost and 127.0.0.1. Various websites say that this can be achieved using subjectAltName. So I created a server certificate using the following openssl configuration file:

distinguished_name = dn
x509_extensions = v3_ca
[req]
prompt = no
[dn]
0.CN = localhost
1.CN = 127.0.0.1
[v3_ca]
subjectAltName = DNS:localhost,DNS:127.0.0.1

The subjectAltName is being sent by the server. For example, as verified by s_client:

% echo | openssl s_client -showcerts -CAfile keys/cert.pem -connect localhost:8443 | grep -i -A 2 certificate
depth=0 CN = localhost, CN = 127.0.0.1
verify return:1
DONE
Certificate chain
 0 s:/CN=localhost/CN=127.0.0.1
   i:/CN=localhost/CN=127.0.0.1
-----BEGIN CERTIFICATE-----
MIIC9jCCAd6gAwIBAgIJANlipKdvxVlUMA0GCSqGSIb3DQEBCwUAMCgxEjAQBgNV
BAMMCWxvY2FsaG9zdDESMBAGA1UEAwwJMTI3LjAuMC4xMB4XDTE5MDcyMzAxMjcw
--
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=localhost/CN=127.0.0.1
issuer=/CN=localhost/CN=127.0.0.1
--
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: X25519, 253 bits

We can also verify it with a simple Python client, which reports:

Cipher is ECDHE-RSA-AES256-GCM-SHA384, SSL protocol is TLSv1.2, bits=256
Peer cert is {'subjectAltName': (('DNS', 'localhost'), ('DNS', '127.0.0.1')), 'notBefore': u'Jul 23 01:27:02 2019 GMT', 'serialNumber': u'D962A4A76FC55954', 'notAfter': 'Jul 22 01:27:02 2020 GMT', 'version': 3L, 'subject': ((('commonName', u'localhost'),), (('commonName', u'127.0.0.1'),)), 'issuer': ((('commonName', u'localhost'),), (('commonName', u'127.0.0.1'),))}
Hello from SSL server!

Unfortunately, curl recognizes only the first name:

% curl --cacert keys/cert.pem https://localhost:8443
Hello from SSL server!
% curl --cacert keys/cert.pem https://127.0.0.1:8443
curl: (51) SSL: no alternative certificate subject name matches target host name '127.0.0.1'
%

How do we get curl (and other programs) to heed the subjectAltName, the whole subjectAltName, and nothing but the subjectAltName?

Update

Maybe it works with this:

distinguished_name = dn
x509_extensions = v3_ca
[req]
prompt = no
[dn]
CN = IGNORED
[v3_ca]
subjectAltName = DNS:localhost,IP:127.0.0.1

Is this stuff, like, documented anywhere?

personal_cloud
  • 3,943
  • 3
  • 28
  • 38
  • See a related discussion on security.stackexchange [over here](https://security.stackexchange.com/questions/160787/ip-address-in-subjectaltname). – Toby Jul 23 '19 at 03:01
  • *"Is this stuff, like, documented anywhere?"* - RFC 5280. Apart from that: `127.0.0.1` is obviously not a DNS name but an IP address. Still, you might need it as `DNS:..` too since some broken implementations expect it this way. – Steffen Ullrich Jul 23 '19 at 04:32
  • @Steffen: plus 2818 for https, or see 6125 for others. Aside: your 'verified by s_client' is wrong; s_client shows _only_ the v1/unextended Subject, _not_ SAN. FWIW in 1.0.2 up s_client _can_ check SAN-or-CN iff you specify `-verify_host[name]` or `-verify_ip`; see the man page. (Though it treats an error here, like other verify errors, as nonfatal by default.) – dave_thompson_085 Jul 23 '19 at 05:22
  • @Steffen. No, RFC 5280 says nothing about the `IP:` syntax. Yes, there is an `ipAddress` expression, but no, it's not defined in a way that actually works with the `openssl` tool. In fact, RFC 5280 specifically says that ipAddress is an OCTET_STRING which is presumably ASN.1 which does NOT have the `IP:` prefix which is one choice I expected to work but does not. Also, no the question is not duplicate. I have added an explanation at the top. – personal_cloud Jul 24 '19 at 00:02
  • @dave_thompson You're right, `s_client` doesn't show the subjectAltName. I agree, CN is ignored. Hence the `CN = IGNORED` in my updated example. – personal_cloud Jul 24 '19 at 00:06
  • Have you read [this](https://www.openssl.org/docs/manmaster/man5/x509v3_config.html)? It's a bit obscure but it describes the IP syntax. – President James K. Polk Jul 24 '19 at 01:01
  • @personal_cloud: *"Is this stuff, like, documented anywhere?"* provides no infomation what "stuff" you even mean. But the problem you had here was not the `DNS:` vs. `IP:` syntax in openssl but the basic understanding that there are different types of subjectAltNames in the first place and when each of these types should be used. This has nothing to do with openssl but requires an understanding of the underlying concepts first. – Steffen Ullrich Jul 24 '19 at 04:22
  • @Steffen. Yes, it requires an understanding of the concepts first -- thanks for the insight. And please clarify what you mean by "*Different types of subjectAltnames*". How could my problem not be about the `DNS:` vs. `IP:` syntax? When I corrected the syntax, it worked. Obviously it was just a simple issue about the `DNS:` syntax not working in some cases, despite its popularity. – personal_cloud Jul 24 '19 at 19:13
  • @JamesKPolk Thank you, that is exactly what I was looking for -- something in the `openssl` documents that would explain the actual `subjectAltName` syntax. This is a great example of how "Google It" fails to find the page... I will definitely accept your answer linking to the x509v3_config page that you dug up. Thank you! – personal_cloud Jul 24 '19 at 19:35
  • @personal_cloud: I try to clarify my comment a bit more. It was not clear from your question what exactly your problem was: was it the concept of different types of subjectAltNames you were missing, was it that you did not know that IP addresses had to be defined as type `IPAdress` in the SAN section, or was the specific syntax in the openssl.conf a problem. Given that you did not specifically ask for the syntax but seemed to miss the concept of different types in the first place I've pointed you to the documentation for this. – Steffen Ullrich Jul 24 '19 at 19:42

1 Answers1

0

As James Polk pointed out in the comments, the

subjectAltName = DNS:localhost,IP:127.0.0.1

syntax is documented here.

personal_cloud
  • 3,943
  • 3
  • 28
  • 38