Tim, Thanks for that. I like the idea of rebuilding GnuTLS so I don't have to add the --ca-directory flag, but will hold on that until I can resolve the connecting problem.
I added the --ca-directory=/system/etc/security/cacerts flag to the wget call and now see this (still not connecting and pulling the file, but slightly different message): Certificates loaded: 138 Resolving (URL) ... failed: Name or service not known wget: unable to resolve host address '(URL)' OK - so this begs these questions: (1) How can I find out if the (hash #).0 files in the --ca-directory I point to are PEM format and thus readable? (2) Assuming they are readable, and are PEM format, how can I update one of them, or create a new PEM format file, that will allow access to the URL I need? thanks, Steve On Tue, May 19, 2020 at 1:43 AM Tim Rühsen <tim.rueh...@gmx.de> wrote: > Stephen, > > you should use the --ca-directory=directory options for this. > > That one loads all PEM files in that directory into the internal GnuTLS > cert store. The file naming doesn't matter, only the content must be PEM. > > You wouldn't have that hassle if GnuTLS would have been built with the > correct system cert store set. As far as I know, that would be > "./configure --with-default-trust-store-dir=/system/etc/security/cacerts". > > Regards, Tim > > On 19.05.20 00:10, Stephen Kirby wrote: > > Tim, > > > > Thanks for that clarification. You are correct -- > > > > I checked the x86-based Google Pixel emulator and there is no > > /etc/ssl/certs directory. Rather it appears this OS puts certificates > > in: /system/etc/security/cacerts. There the files are named (hash > #'s).0. > > > > Do I need to tell wget to look in this directory instead? The relevant > > flag available with wget looks to be "--ca-certificate=FILE". However, > > I do not know, out of the 30 or so files in the aforementioned directory > > I should point to. Furthermore does wget require these certificate > > files strictly be either PEM or DER format? Not sure what the format of > > the files in /system/etc/security/cacerts on this emulator are? Sorry > > for this short list of questions. Just trying to get a feel for what to > > do next... > > > > Best, > > Steve > > > > On Sun, May 17, 2020 at 12:24 PM Tim Rühsen <tim.rueh...@gmx.de > > <mailto:tim.rueh...@gmx.de>> wrote: > > > > -1250 is a GnuTLS failure "GNUTLS_E_UNIMPLEMENTED_FEATURE" returned > by > > gnutls_certificate_set_x509_system_trust(). > > > > Due to a bug, this is output instead of the real number of certs > loaded. > > > > The fallback code tries to open /etc/ssl/certs to search for > > certificates. But it seems, this doesn't exist on your system. > > > > Regards, Tim > > > > On 16.05.20 19:15, Stephen Kirby wrote: > > > Hi all, > > > > > > Tim let me know I only responded to him instead of the list. My > > bad and > > > thanks for noticing! So here is what I sent Tim the other day -- > > > > > > Thanks all for you inputs! > > > > > > I just tried adding the --debug flag and get one more piece of > info: > > > certificates loaded: -1250 > > > > > > I am not seeing this error code on a quick search. Maybe someone > > on the > > > list knows what it means?. > > > > > > Thanks for the strace suggestion. I do see it on the phone > > emulator and am > > > thinking next I would run an strace on my Debian Linux system > > where my wget > > > is working and compare it to the strace on the mobile emulator > > where wget > > > is failing. > > > > > > thanks, > > > Steve > > > > > > On Sat, May 16, 2020 at 5:24 AM Tim Rühsen <tim.rueh...@gmx.de > > <mailto:tim.rueh...@gmx.de>> wrote: > > > > > >> Hi Stephen, > > >> > > >> please answer to the mailing list, so everybody can participate :) > > >> > > >> Regards, Tim > > >> > > >> On 15.05.20 20:22, Stephen Kirby wrote: > > >>> Thanks all for you inputs! > > >>> > > >>> I just tried adding the --debug flag and get one more piece of > info: > > >>> certificates loaded: -1250 > > >>> > > >>> Any idea what this code means? > > >>> > > >>> It does look like the emulator has strace. I will check this as > > well... > > >>> > > >>> thanks, > > >>> Steve > > >>> > > >>> On Fri, May 15, 2020 at 12:07 PM Tim Rühsen <tim.rueh...@gmx.de > > <mailto:tim.rueh...@gmx.de> > > >>> <mailto:tim.rueh...@gmx.de <mailto:tim.rueh...@gmx.de>>> wrote: > > >>> > > >>> On 15.05.20 19:08, Stephen Kirby wrote: > > >>> > Petr/Everyone, > > >>> > > > >>> > Thanks so much for your detailed recommendations on how to > > >>> proceed. You > > >>> > were spot on regarding gnutls_priority_set_direct. I > > looked at > > >>> config.log > > >>> > and noticed configure was failing due to a missing pthread > > lib. I > > >>> inserted > > >>> > that, then had to fix some other missing symbols. Anyway, > > I have a > > >>> > statically linked wget that I have now pushed onto the > > Google Pixel > > >>> > Emulated phone I have running via Android Studio. > > >>> > > > >>> > I can definitely move this question to another forum if > > you all > > >>> believe it > > >>> > better since it involves an emulated Google Pixel phone now > > >>> (x86_64 arch.), > > >>> > but it has to do with wget still, so if I may please: > > >>> > > > >>> > on the emulated phone, I am trying: > > >>> > > > >>> > wget -O filename http://###.##.###.## (i.e., here I use > the IP > > >> address > > >>> > found via nslookup on the named URL) > > >>> > > > >>> > Then, I get: > > >>> > HTTP request sent, awaiting response... 302 object moved > > >>> > Location: https://(here it lists the correctly named URL) > > >>> > Resolving (named URL)... Failed: Name or Server not known > > >>> > wget: unable to resolve host address "named URL" > > >>> > > > >>> > I'll note that this wget call works perfectly on my Debian > > Linux > > >>> > system, downloading the file I need. > > >>> > Also interesting to me is the fact that I can ping > > _successfully_ > > >>> both the > > >>> > URL by name or its associated IP address, on the emulated > > phone > > >>> So, not > > >>> > sure why wget would throw this error. > > >>> > > >>> wget uses getaddrinfo(), except you built it with c-ares. > > >>> > > >>> Perhaps you have 'strace' installed !? > > >>> Then you could start wget with strace and see what fails (or > why > > >>> getaddrinfo fails). > > >>> > > >>> Regards, Tim > > >>> > > >> > > >> > > > >