Thank you everyone for your really good answers. I'll see what I can do with the IXWebSocket library. I have enough information that maybe that will help the author to fix some issue with his library.
Le lun. 13 févr. 2023, à 16 h 40, <openssl-users-request@xxxxxxxxxxx> a écrit :
Send openssl-users mailing list submissions to
openssl-users@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
openssl-users-request@xxxxxxxxxxx
You can reach the person managing the list at
openssl-users-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."
Today's Topics:
1. Re: IXWebSocket wss c++ client cannot connect to Node.js wss
server using an ip address (Viktor Dukhovni)
2. RE: IXWebSocket wss c++ client cannot connect to Node.js wss
server using an ip address (Michael Wojcik)
3. Re: IXWebSocket wss c++ client cannot connect to Node.js wss
server using an ip address (Pierre-Luc Boily)
---------- Forwarded message ----------
From: Viktor Dukhovni <openssl-users@xxxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Cc:
Bcc:
Date: Mon, 13 Feb 2023 15:29:49 -0500
Subject: Re: IXWebSocket wss c++ client cannot connect to Node.js wss server using an ip address
On Mon, Feb 13, 2023 at 03:07:51PM -0500, Pierre-Luc Boily wrote:
> Indeed, server cert shows "localhost", but it also shows the ip address :
>
> X509v3 Subject Alternative Name:
> DNS:localhost, IP Address:192.168.230.138, IP Address:127.0.0.1
But the client application/library then has to support IP address SANs,
and some don't.
> By the way, the author of the IXWebSocket c++ library told me :
>
> > This might be a high level SSL stuff, where you actually need a real
> > hostname and can't use an IP.
A disturbingly hand-wavy response. If the author does not know how the
library works, perhaps the library is not a good choice. That said, it
does vaguely seem to suggest that IP address SANs are not supported (and
perhaps not even understood by the author).
> But on the other hand, I have a _javascript_ websocket client that can
> connect to my wss server using the same certificate as the c++ client.
That client supports IP address SANs, or simply does not check the SAN
when using IP addresses.
> All of this is for test purposes, eventually, I will use a domain
> name. But as a workaround, I thought to use a fake domain name that
> points to the server IP address. Maybe this will work?
This is not an OpenSSL issue. Take it up the library authors. OpenSSL
supports validating IP address SANs, when the caller supplies an IP
address to check. OpenSSL validates hostnames when the calling
application or library supplies a hostname to check. If the application
supplies a dotted-quad string as a hostname (e.g. "192.0.2.1"), rather than
an IP address, the validation will fail.
https://www.openssl.org/docs/man3.0/man3/SSL_set1_host.html
https://www.openssl.org/docs/man1.1.1/man3/SSL_get0_param.html
https://www.openssl.org/docs/man1.1.1/man3/X509_VERIFY_PARAM_set1_ip.html
In particular here:
param = SSL_get0_param(ssl);
if (X509_VERIFY_PARAM_set1_ip_asc(param, "192.0.2.1") <= 0) {
/* error */
}
...
--
Viktor.
---------- Forwarded message ----------
From: Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx>
To: "openssl-users@xxxxxxxxxxx" <openssl-users@xxxxxxxxxxx>
Cc:
Bcc:
Date: Mon, 13 Feb 2023 20:35:29 +0000
Subject: RE: IXWebSocket wss c++ client cannot connect to Node.js wss server using an ip address
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Pierre-Luc Boily
Sent: Monday, 13 February, 2023 13:08
[Mark Hack wrote]
>> Looking at the IX code (and it was a very quick look), I suspect that only the CN is validated.
> Indeed, server cert shows "localhost", but it also shows the ip address :
>
> X509v3 Subject Alternative Name:
> DNS:localhost, IP Address:192.168.230.138, IP Address:127.0.0.1
Yes, but those are SANs. If Mark is correct and the library only uses the Subject CN when performing the name-checking step of verification, then the SANs won't help.
> By the way, the author of the IXWebSocket c++ library told me :
>
> This might be a high level SSL stuff, where you actually need a real hostname and can't use an IP.
Supporting SANs is hardly "high level" -- more like "bare minimum for correct functioning in the modern TLS environment".
You can most certainly use IPADR SANs when verifying peer certificates (we do that routinely in testing, since some customers have uses for them). That's why they exist.
> But on the other hand, I have a _javascript_ websocket client that can connect to my wss server
> using the same certificate as the c++ client.
Yes, this too suggests that the IXWebSocket implementation does not do certificate verification properly.
> But as a workaround, I thought to use a fake domain name that points to the server IP address.
> Maybe this will work?
Since you're apparently up against a deficiency in your client library, it's hard for us to guess what will work. That said, yes, you can create a certificate with any names (where, in the case of normal TLS server-certificate verification, "name" could be a FQDN, a bare hostname, or an IP address) as SANs; and you can, if you wish, use one of those names as the CN component of the Subject DN, to cater to clients which don't to verification correctly. (The CA/BF Basic Requirements mandate ignoring the Subject DN if SANs are present, for purposes of verifying the certificate identity.)
For verification, the rules for matching the name(s) present in the server's certificate with the name intended by the client are complicated, thanks to SANs, wildcarding, and so on. There are also API issues: prior to OpenSSL 1.1.0, OpenSSL didn't do it for you (so name matching had to be done by the application); with 1.1.0 and later, you have to tell OpenSSL to do the name matching and what name you want it to match. A great many clients still get this wrong. (This is very common with mobile applications, for example.)
Generally speaking, if the client does it correctly, then the server's certificate should contain a SAN that matches (case-insensitively, and possibly using wildcards, though not a wildcard followed by a forbidden domain) the exact name intended by the client. Of course the client has to tell OpenSSL what name it intends to find in the server's certificate. Then all the other verification checks have to pass (certificate signatures are good, OpenSSL can chain back to a trusted root, nothing's expired, Basic Constraints and EKUs are correct, maybe you're a masochist and you enabled CRLs and/or OSPF, blah blah blah).
As usual, a good rule of thumb is that TLS is hard, PKIX (Public Key Infrastructure - X.509) is worse, and most developers get them wrong in some number of ways, regardless of what library they're using. I've been working with them for a quarter of a century; I've read books and I've read the specs; I've dealt with hundreds of real-world use case; and I still keep running into things I hadn't seen before, or having to dig through references to make sure I'm remembering something correctly.
--
Michael Wojcik
---------- Forwarded message ----------
From: Pierre-Luc Boily <pierreluc.boily@xxxxxxxxx>
To: Mark Hack <markhack@xxxxxxxxxxxx>
Cc: openssl-users@xxxxxxxxxxx
Bcc:
Date: Mon, 13 Feb 2023 16:40:08 -0500
Subject: Re: IXWebSocket wss c++ client cannot connect to Node.js wss server using an ip addressSo, I updated my hosts file. I added a fake url pointing to the server. Then, I created a new certificate with a SAN pointing to the fake URL et voilà, my c++ wss client can connect to my wss server.So, your assumption is correct, the IXWebSocket implementation of openssl cannot use an ip address.Thank you._______________________________________________Le lun. 13 févr. 2023, à 15 h 07, Pierre-Luc Boily <pierreluc.boily@xxxxxxxxx> a écrit :You can see the server cert here : https://pastebin.com/Eb8b9tUfIndeed, server cert shows "localhost", but it also shows the ip address :X509v3 Subject Alternative Name:
DNS:localhost, IP Address:192.168.230.138, IP Address:127.0.0.1By the way, the author of the IXWebSocket c++ library told me :This might be a high level SSL stuff, where you actually need a real hostname and can't use an IP.But on the other hand, I have a _javascript_ websocket client that can connect to my wss server using the same certificate as the c++ client.All of this is for test purposes, eventually, I will use a domain name. But as a workaround, I thought to use a fake domain name that points to the server IP address. Maybe this will work?Thank you.Le lun. 13 févr. 2023, à 10 h 03, Mark Hack <markhack@xxxxxxxxxxxx> a écrit :I have a few ideas what the issue is. Can you start by either attaching the server cert or showing it in text form using the command "openssl x509 ..."Looking at the IX code (and it was a very quick look), I suspect that only the CN is validated. If the server cert shows "localhost" then that is probably the issue.RegardsMark HackOn Fri, 2023-02-10 at 16:13 -0500, Pierre-Luc Boily wrote:Hello,
I have a IXWebSocket c++ wss client connecting to a Node.js wss server(websocket npm package). Everything is fine as long as the client connects to `wss://localhost:8080`. Soon as I use the ip address of the Node.js wss server, I have the error "OpenSSL failed - error:0A000086:SSL routines::certificate verify failed"
## Certificate chain creation ##
I created my own private root ca. I used those commands to generate root ca key/certificate and server key/certificate:
$ openssl genpkey -aes256 -out root-ca/private/ca.private.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048
$ openssl req -config root-ca/root-ca.conf -key root-ca\private\ca.private.key -x509 -days 7500 -sha256 -extensions v3_ca -out root-ca\certs\ca.crt
$ openssl genpkey -out server/private/server.private.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048
$ openssl req -key server\private\server.private.key -new -sha256 -out server\csr\server.csr
$ openssl ca -config root-ca\root-ca.conf -extensions server_cert -days 365 -notext -in server\csr\server.csr -out server\certs\server.crt
The configuration has a `subjectAltName` for both root and server and it looks like this :
See config file : https://pastebin.com/kAcwkp9w
The certificate chain looks valid between my *root ca* and my *server*:
$ openssl verify -CAfile root-ca\certs\ca.crt server\certs\server.crt
server\certs\server.crt: OK
Both `ca.crt` and `server.crt` have a reference to my ip address, so I used the subjectAltName parameter to define it. I thought that my *root ca* would need it (I am not even sure that it makes sense to have a domain on the *root ca*), but it doesn't make any difference.
Code that is not working
My IXWebSocket c++ client :
https://pastebin.com/tLGi3amA
Code that is working
wss _javascript_ client:
I also coded a _javascript_ client (using the same npm package as my server, not ) and this little client can connect using the ip address!!
https://pastebin.com/Huzv59gX
My Node.js server :
https://pastebin.com/QCYg5z1B
Questions :
1. Any idea why my c++ client cannot connect using an ip address to the server, while the _javascript_ client can? (using the same certificate chain)
2. If not, any idea how I could debug this?
3. Would it be possible that the problem is a high level SSL stuff, where you actually need a real hostname and can't use an IP?
openssl-users mailing list
openssl-users@xxxxxxxxxxx
https://mta.openssl.org/mailman/listinfo/openssl-users
