It doesn’t look like the .tar.gz file downloaded successfully, it looks like the HTML for the 301 redirect was downloaded.
Nils. > Op 19 jul. 2022 om 17:20 heeft Mark Brethen <mark.bret...@gmail.com> het > volgende geschreven: > > Understood. Using HTTP instead of HTTPS doesn’t invoke SSL/TLS. If you look > at the command line output (not port), that error didn’t occur and the file > downloaded successfully. I was curious what the fetch curl command looked > like vs the command line? > > Sent from my iPhone > >>> On Jul 19, 2022, at 9:57 AM, Nils Breunese <n...@breun.nl> wrote: >>> >> >> This depends on your definition of succeeding. The request to the HTTP URL >> returns a 301 redirect, which is not necessarily a ‘success’ status code. >> This response points to the HTTPS URL and the TLS/SSL error only occurs when >> requesting that URL. >> >> Nils. >> >>>> Op 19 jul. 2022 om 11:58 heeft Mark Brethen <mark.bret...@gmail.com> het >>>> volgende geschreven: >>>> >>> Please tell me why fetch still fails when /usr/bin/curl succeeds in >>> terminal? >>> >>> :notice:fetch ---> Attempting to fetch tetgen1.5.1.tar.gz from >>> http://wias-berlin.de/software/tetgen/1.5/src/ >>> :debug:fetch Fetching distfile failed: error:14008410:SSL >>> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure >>> >>> Mark Brethen >>> mark.bret...@gmail.com >>> >>> >>> >>>> On Jul 19, 2022, at 4:46 AM, Mark Brethen <mark.bret...@gmail.com> wrote: >>>> >>>> HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. Use >>>> HTTP instead: >>>> >>>> ~ $ cd Downloads >>>> Downloads $ /usr/bin/curl -vO >>>> http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz >>>> % Total % Received % Xferd Average Speed Time Time Time >>>> Current >>>> Dload Upload Total Spent Left >>>> Speed >>>> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- >>>> 0* Trying 62.141.177.111... >>>> * TCP_NODELAY set >>>> * Connected to wias-berlin.de (62.141.177.111) port 80 (#0) >>>> > GET /software/tetgen/1.5/src/tetgen1.5.1.tar.gz HTTP/1.1 >>>> > Host: wias-berlin.de >>>> > User-Agent: curl/7.64.1 >>>> > Accept: */* >>>> > >>>> < HTTP/1.1 301 Moved Permanently >>>> < Date: Tue, 19 Jul 2022 09:37:56 GMT >>>> < Server: Apache >>>> < Location: >>>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz >>>> < Content-Length: 273 >>>> < Content-Type: text/html; charset=iso-8859-1 >>>> < >>>> { [273 bytes data] >>>> 100 273 100 273 0 0 291 0 --:--:-- --:--:-- --:--:-- >>>> 291 >>>> * Connection #0 to host wias-berlin.de left intact >>>> * Closing connection 0 >>>> >>>> Mark Brethen >>>> mark.bret...@gmail.com >>>> >>>> >>>> >>>>> On Jul 18, 2022, at 11:56 AM, Mark Brethen <mark.bret...@gmail.com> wrote: >>>>> >>>>> It’s more likely that curl 7.64.1 succeeds to connect while openssl 2.8.3 >>>>> fails with alert number 40 (see below). It might be related to the server >>>>> which has several virtual hosts. openssl 3.0.5 (mp) seems to handle it >>>>> fine compared to openssl 2.8.3. >>>>> >>>>> Downloads $ openssl version >>>>> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022) >>>>> >>>>> Downloads $ openssl s_client -connect wias-berlin.de:443 -servername >>>>> wias-berlin.de >>>>> CONNECTED(00000005) >>>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems >>>>> Trust Center, CN = T-TeleSec GlobalRoot Class 2 >>>>> verify return:1 >>>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen >>>>> Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification >>>>> Authority 2 >>>>> verify return:1 >>>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen >>>>> Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA >>>>> verify return:1 >>>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin >>>>> e.V., OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik >>>>> (WIAS), OU = RT, CN = www.wias-berlin.de >>>>> verify return:1 >>>>> >>>>> Downloads $ /usr/bin/openssl version >>>>> LibreSSL 2.8.3 >>>>> >>>>> Downloads $ /usr/bin/openssl s_client -connect wias-berlin.de:443 >>>>> -servername wias-berlin.de >>>>> CONNECTED(00000005) >>>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems >>>>> Trust Center, CN = T-TeleSec GlobalRoot Class 2 >>>>> verify return:1 >>>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen >>>>> Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification >>>>> Authority 2 >>>>> verify return:1 >>>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen >>>>> Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA >>>>> verify return:1 >>>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin >>>>> e.V., OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik >>>>> (WIAS), OU = RT, CN = www.wias-berlin.de >>>>> verify return:1 >>>>> 4381900460:error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert >>>>> handshake >>>>> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL >>>>> alert number 40 >>>>> 4381900460:error:140080E5:SSL routines:CONNECT_CR_KEY_EXCH:ssl handshake >>>>> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:585: >>>>> --- >>>>> >>>>> >>>>> >>>>> Mark >>>>> >>>>> >>>>> >>>>>> On Jul 18, 2022, at 8:11 AM, Mark Brethen <mark.bret...@gmail.com> wrote: >>>>>> >>>>>> wias-berlin.de >>>>> >>>> >>>
