openssl-users Digest, Vol 99, Issue 26
Pierre-Luc Boily
pierreluc.boily at gmail.com
Mon Feb 13 21:52:28 UTC 2023
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 at openssl.org> a
écrit :
> Send openssl-users mailing list submissions to
> openssl-users at openssl.org
>
> 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 at openssl.org
>
> You can reach the person managing the list at
> openssl-users-owner at openssl.org
>
> 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 at dukhovni.org>
> To: openssl-users at openssl.org
> 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 at microfocus.com>
> To: "openssl-users at openssl.org" <openssl-users at openssl.org>
> 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 at openssl.org> 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 at gmail.com>
> To: Mark Hack <markhack at markhack.com>
> Cc: openssl-users at openssl.org
> 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 address
> So, 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 at gmail.com> a écrit :
>
>> You can see the server cert here : https://pastebin.com/Eb8b9tUf
>>
>> 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
>>
>> 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.*
>>
>>
>> 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 at markhack.com> 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.
>>>
>>>
>>> Regards
>>>
>>> Mark Hack
>>>
>>> On 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 at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230213/c310b222/attachment-0001.htm>
More information about the openssl-users
mailing list