Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Gerben Wierda via macports-users]

I contacted NLNet Labs, they updated their certs which made NSD fetch on Mojave 
work again for me.

Somewhere during my tests accidentally OpenSSL was activated on my machine (a 
destroot on nsd 4.3.8 maybe?), which killed all the installed ports that were 
dependent on an opensll 1.1.1 dylib (which had been made inaccessible), so 
suddenly a lot of programs couldn’t start anymore (Abort 6) because the dylib 
wasn’t there. That kind of forced me to do a quick update of everything.

So I updated NSD to 4.3.8 and created a pull request for it (as the existing 
MacPorts version 4.1.2 would not compile with OpenSSL3 which is now standard 
and I am an NSD maintainer)

That change has now been merged with MacPorts master (yes! yes! I did it 
correctly! I’m getting the hang of it!)

Everything NSD is back as it should be.

Gerben Wierda (LinkedIn )
R Enterprise Architecture  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

> On 8 Nov 2021, at 03:54, Dave Horsfall  wrote:
> 
> On Sun, 7 Nov 2021, Bill Cole wrote:
> 
>>> So I wonder how widespread this problem is?
>> 
>> The problem in this case is not the existence of the cert in the CA bundle, 
>> but the fact that this particular expired cert was used in an alternative 
>> validation path and the logic of verification for multi-path certs isn't 
>> correct. Normally, expired root CAs should stay in there because that allows 
>> positive non-verification of certs supposedly issued by an expired (and 
>> maybe compromised) root CA.
> 
> Gotcha; thanks.
> 
>>> And I'm not happy with those that are set way in the future; I heard 
>>> somewhere that 5 years is the recommended max.
>> 
>> CAs are special. The current limit on server certs is 397 days. I don't 
>> think there's a consensus on CA lifetimes because of the conflicting risks 
>> of too-short and too-long lives.
> 
> One day past a leap year :-)  I don't remember where I saw the 5-year 
> recommendation, unfortunately.
> 
> -- Dave

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Dave Horsfall]

On Sun, 7 Nov 2021, Bill Cole wrote:


So I wonder how widespread this problem is?


The problem in this case is not the existence of the cert in the CA 
bundle, but the fact that this particular expired cert was used in an 
alternative validation path and the logic of verification for multi-path 
certs isn't correct. Normally, expired root CAs should stay in there 
because that allows positive non-verification of certs supposedly issued 
by an expired (and maybe compromised) root CA.


Gotcha; thanks.

And I'm not happy with those that are set way in the future; I heard 
somewhere that 5 years is the recommended max.


CAs are special. The current limit on server certs is 397 days. I don't 
think there's a consensus on CA lifetimes because of the conflicting 
risks of too-short and too-long lives.


One day past a leap year :-)  I don't remember where I saw the 5-year 
recommendation, unfortunately.


-- Dave

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Bill Cole]

On 2021-11-07 at 16:29:30 UTC-0500 (Mon, 8 Nov 2021 08:29:30 +1100 
(EST))

Dave Horsfall 
is rumored to have said:


On Sun, 7 Nov 2021, Bill Cole wrote:

I have my own Mojave machines working without a problem after 
removing the bad certificate from /etc/ssl/cert.pem. The one that 
starts like this:


[...]

Intrigued, I checked my own:

mackie:~ dave$ grep "Not After" /etc/ssl/cert.pem


[... many dates snipped ...]

So I wonder how widespread this problem is?


The problem in this case is not the existence of the cert in the CA 
bundle, but the fact that this particular expired cert was used in an 
alternative validation path and the logic of verification for multi-path 
certs isn't correct. Normally, expired root CAs should stay in there 
because that allows positive non-verification of certs supposedly issued 
by an expired (and maybe compromised) root CA.


And I'm not happy with those that are set way in the future; I heard 
somewhere that 5 years is the recommended max.


CAs are special. The current limit on server certs is 397 days. I don't 
think there's a consensus on CA lifetimes because of the conflicting 
risks of too-short and too-long lives.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Dave Horsfall]

On Sun, 7 Nov 2021, Bill Cole wrote:

I have my own Mojave machines working without a problem after removing 
the bad certificate from /etc/ssl/cert.pem. The one that starts like 
this:


[...]

Intrigued, I checked my own:

mackie:~ dave$ grep "Not After" /etc/ssl/cert.pem


Not After : Aug 13 23:59:00 2018 GMT
Not After : Aug 22 16:41:51 2018 GMT
Not After: Aug 22 16:41:51 2018 GMT
Not After : Aug  1 23:59:59 2028 GMT
Not After : Jan 28 12:00:00 2028 GMT
Not After : Dec 15 08:00:00 2021 GMT
Not After : Mar 18 10:00:00 2029 GMT
Not After : Dec 31 23:59:59 2020 GMT
Not After : Dec 31 23:59:59 2020 GMT
Not After : Jul 16 23:59:59 2036 GMT
Not After : Jul 16 23:59:59 2036 GMT
Not After : Jan 18 23:59:59 2038 GMT
Not After : Dec  1 23:59:59 2037 GMT
Not After : Jul 16 23:59:59 2036 GMT
Not After : Sep 17 19:46:36 2036 GMT
Not After : Jun 26 00:19:54 2019 GMT
Not After : May 25 16:39:40 2019 GMT
Not Before: May 25 16:09:40 1999 GMT, Not After: May 25 
16:09:40 2019 GMT
Not After : Nov 10 00:00:00 2031 GMT
Not After : Nov 10 00:00:00 2031 GMT
Not After : Nov 10 00:00:00 2031 GMT
Not After : Jun 21 04:00:00 2020 GMT
Not After : Jun 21 04:00:00 2020 GMT
Not After : May 21 04:00:00 2022 GMT
Not After : Mar  4 05:00:00 2019 GMT
Not After : Jul 16 23:59:59 2036 GMT
Not After : Dec  1 23:59:59 2037 GMT
Not After : Mar  4 05:00:00 2029 GMT
Not After : Mar  4 05:00:00 2029 GMT
Not After : Jun 29 17:06:20 2034 GMT
Not After : Dec 31 23:59:59 2037 GMT
Not After : Jun 29 17:39:16 2034 GMT
Not After : Dec 31 23:59:59 2037 GMT
Not After : Dec 31 23:59:59 2037 GMT
Not After : Dec 31 23:59:01 2039 GMT
Not After : Jul 16 23:59:59 2036 GMT
Not After : Jan 18 23:59:59 2038 GMT
Not After : Dec  1 23:59:59 2037 GMT
Not After : May 30 10:48:38 2020 GMT
Not After : Dec 31 23:59:59 2028 GMT
Not After : Jul  9 18:19:22 2019 GMT
Not After : May 12 23:59:00 2025 GMT
Not After : Jul  9 23:59:00 2019 GMT
Not After : Oct  1 23:59:59 2033 GMT
Not After : Oct  1 23:59:59 2033 GMT
Not After : Oct 25 08:30:35 2036 GMT
Not After : Oct 25 08:36:00 2036 GMT
Not After : Oct 25 08:32:46 2036 GMT
Not After : Sep 30 14:01:15 2021 GMT
Not After : Dec  6 15:08:21 2028 GMT

So I wonder how widespread this problem is?  And I'm not happy with those 
that are set way in the future; I heard somewhere that 5 years is the 
recommended max.


-- Dave

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Bill Cole]

On 2021-11-07 at 06:40:01 UTC-0500 (Sun, 7 Nov 2021 12:40:01 +0100)
Gerben Wierda via macports-users 
is rumored to have said:

The reason is libcurl in Mojave which is less permissive than High 
Sierra.


I'm unconvinced of that.

I have my own Mojave machines working without a problem after removing 
the bad certificate from /etc/ssl/cert.pem. The one that starts like 
this:


-### Digital Signature Trust Co.
-
-=== /O=Digital Signature Trust Co./CN=DST Root CA X3
-Certificate:
-Data:
-Version: 3 (0x2)
-Serial Number:
-44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
-Signature Algorithm: sha1WithRSAEncryption
-Validity
-Not Before: Sep 30 21:12:19 2000 GMT
-Not After : Sep 30 14:01:15 2021 GMT






On 7 Nov 2021, at 03:08, Kastus Shchuka  wrote:

Something does not add up here.

High Sierra is older than Mojave, right? I can fetch sources of nsd 
on High Sierra without any problems:


$ sudo port -d fetch nsd
DEBUG: Copying 
/Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd

DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies

DEBUG: Running callback portstartupitem::add_notes
DEBUG: Finished running callback portstartupitem::add_notes
DEBUG: Attempting ln -sf 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work

DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: Starting logging for nsd @4.2.1_2
DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
DEBUG: MacPorts 2.7.1
DEBUG: Xcode 9.4.1
DEBUG: SDK 10.13
DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
DEBUG: Executing org.macports.main (nsd)
DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
--->  Fetching distfiles for nsd
DEBUG: elevating privileges for fetch: euid changed to 0, egid 
changed to 0.

DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: Executing org.macports.fetch (nsd)
--->  nsd-4.2.1.tar.gz does not exist in 
/opt/local/var/macports/distfiles/nsd
--->  Attempting to fetch nsd-4.2.1.tar.gz from 
http://distfiles.macports.org/nsd
 % Total% Received % Xferd  Average Speed   TimeTime Time 
 Current
Dload  Upload   Total   SpentLeft 
 Speed
100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- 
--:--:-- 3563k

$ ls -l /opt/local/var/macports/distfiles/nsd
total 2240
-rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz

I have MacPorts installed from a package, I did not build it, so it 
is pretty much standard. Neither I did anything to the system 
certificate chain.


On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  
wrote:





On Nov 6, 2021, at 05:39, Gerben Wierda wrote:

I was looking at updating nsd (for which I am maintaining and it is 
high time)


But fetching failed on macOS Mojave (where I have my MacPorts 
setup).


:debug:fetch Executing org.macports.fetch (nsd)
:info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
/opt/local/var/macports/distfiles/nsd
:notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
https://www.nlnetlabs.nl/downloads/nsd/
:debug:fetch Fetching distfile failed: SSL certificate problem: 
certificate has expired


Now, my main MacPorts dev/use machine is macOS Mojave so I suspect 
that is the Mojave-doesn’t-get-root-cert-updates problem. So, I 
tried to do a port fetch on Catalina, and there it works and the 
distribution is downloaded.


It is strange, though, because Safari on both Catalina (other 
machine) and Mojave say the cert is fine. Still, it is most likely 
that this is a problem that comes from still using Mojave.


Updating that machine will not happen until late December, so if I 
am to maintain anything MacPorts, I need a fix to get this working 
again.


I have tried using curl on the Mojave machine, and that one works.

So, Safari works, curl works, but port does not work.

I tried copying /etc/ssl/cert.pem over to the Mojave machine, but 
that doesn’t work either.


This is the "Let's Encrypt's old root certificate expired" problem 
described here:

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[André-John Mas]

Actually it was more about curl, using that as a reference point to see if it 
was behaving differently with certificates based on user. 

André-John

Sent from my phone. Envoyé depuis mon téléphone. 

> On 07 Nov 2021, at 01:03, Kastus Shchuka  wrote:
> 
> 
> 
>> On Nov 6, 2021, at 7:53 PM, André-John Mas  wrote:
>> 
>> Does it make a difference if you test via sudo or your own user login?
>> 
> 
> Well, it won't work as regular user. Regular user does not have write 
> permissions to /opt/local tree.
> 
> On the other hand, it's plain dumb why it works for me. As you can see below, 
> org.macports.fetch does not use HTTPS, it downloads over HTTP. Certificates 
> are just irrelevant for that.
> 
> I am not sure what part of macports.conf controls protocol for fetch, I have 
> not modified that file since 2017. (I guess I should have done it). I looked 
> at the diff between my macports.conf and macports.conf.default from May 2021, 
> and I don't see anything with regards to http/https. I must be missing 
> something there.
> 
> Thanks,
> 
> Kastus
> 
>> André-John
>> 
>> Sent from my phone. Envoyé depuis mon téléphone. 
>> 
 On 06 Nov 2021, at 22:08, Kastus Shchuka  wrote:
>>> 
>>> Something does not add up here.
>>> 
>>> High Sierra is older than Mojave, right? I can fetch sources of nsd on High 
>>> Sierra without any problems:
>>> 
>>> $ sudo port -d fetch nsd
>>> DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
>>> /opt/local/var/macports/home/Library/Preferences
>>> DEBUG: Changing to port directory: 
>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
>>> DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
>>> DEBUG: adding the default universal variant
>>> DEBUG: Reading variant descriptions from 
>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
>>> DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
>>> DEBUG: Finished running callback 
>>> portconfigure::add_automatic_compiler_dependencies
>>> DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
>>> DEBUG: Finished running callback 
>>> portbuild::add_automatic_buildsystem_dependencies
>>> DEBUG: Running callback portstartupitem::add_notes
>>> DEBUG: Finished running callback portstartupitem::add_notes
>>> DEBUG: Attempting ln -sf 
>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work
>>>  
>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work
>>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
>>> DEBUG: Starting logging for nsd @4.2.1_2
>>> DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
>>> DEBUG: MacPorts 2.7.1
>>> DEBUG: Xcode 9.4.1
>>> DEBUG: SDK 10.13
>>> DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
>>> DEBUG: Executing org.macports.main (nsd)
>>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
>>> DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
>>> --->  Fetching distfiles for nsd
>>> DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0.
>>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
>>> DEBUG: Executing org.macports.fetch (nsd)
>>> --->  nsd-4.2.1.tar.gz does not exist in 
>>> /opt/local/var/macports/distfiles/nsd
>>> --->  Attempting to fetch nsd-4.2.1.tar.gz from 
>>> http://distfiles.macports.org/nsd
>>> % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>>   Dload  Upload   Total   SpentLeft  Speed
>>> 100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- --:--:-- 
>>> 3563k
>>> $ ls -l /opt/local/var/macports/distfiles/nsd
>>> total 2240
>>> -rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz
>>> 
>>> I have MacPorts installed from a package, I did not build it, so it is 
>>> pretty much standard. Neither I did anything to the system certificate 
>>> chain.
>>> 
 On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  wrote:
 
 
 
> On Nov 6, 2021, at 05:39, Gerben Wierda wrote:
> 
> I was looking at updating nsd (for which I am maintaining and it is high 
> time)
> 
> But fetching failed on macOS Mojave (where I have my MacPorts setup).
> 
> :debug:fetch Executing org.macports.fetch (nsd)
> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
> /opt/local/var/macports/distfiles/nsd
> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
> https://www.nlnetlabs.nl/downloads/nsd/
> :debug:fetch Fetching distfile failed: SSL certificate problem: 
> certificate has expired
> 
> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that 
> is the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a 
> port fetch on 

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Ryan Schmidt]

On Nov 7, 2021, at 00:03, Kastus Shchuka wrote:
> 
> On the other hand, it's plain dumb why it works for me. As you can see below, 
> org.macports.fetch does not use HTTPS, it downloads over HTTP. Certificates 
> are just irrelevant for that.
> 
> I am not sure what part of macports.conf controls protocol for fetch,

Right. We already modified MacPorts so that it knows on which OS versions https 
won't work -- with regard to our mirror servers only.

https://github.com/macports/macports-ports/commit/d8986b24bac94f22a60bfdd3e5d815d6a68c7a05

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Gerben Wierda via macports-users]

The reason is libcurl in Mojave which is less permissive than High Sierra.

Sent from my iPhone

> On 7 Nov 2021, at 03:08, Kastus Shchuka  wrote:
> 
> Something does not add up here.
> 
> High Sierra is older than Mojave, right? I can fetch sources of nsd on High 
> Sierra without any problems:
> 
> $ sudo port -d fetch nsd
> DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
> /opt/local/var/macports/home/Library/Preferences
> DEBUG: Changing to port directory: 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
> DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
> DEBUG: adding the default universal variant
> DEBUG: Reading variant descriptions from 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
> DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
> DEBUG: Finished running callback 
> portconfigure::add_automatic_compiler_dependencies
> DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
> DEBUG: Finished running callback 
> portbuild::add_automatic_buildsystem_dependencies
> DEBUG: Running callback portstartupitem::add_notes
> DEBUG: Finished running callback portstartupitem::add_notes
> DEBUG: Attempting ln -sf 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work
>  
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: Starting logging for nsd @4.2.1_2
> DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
> DEBUG: MacPorts 2.7.1
> DEBUG: Xcode 9.4.1
> DEBUG: SDK 10.13
> DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
> DEBUG: Executing org.macports.main (nsd)
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
> --->  Fetching distfiles for nsd
> DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0.
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: Executing org.macports.fetch (nsd)
> --->  nsd-4.2.1.tar.gz does not exist in /opt/local/var/macports/distfiles/nsd
> --->  Attempting to fetch nsd-4.2.1.tar.gz from 
> http://distfiles.macports.org/nsd
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
> 100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- --:--:-- 3563k
> $ ls -l /opt/local/var/macports/distfiles/nsd
> total 2240
> -rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz
> 
> I have MacPorts installed from a package, I did not build it, so it is pretty 
> much standard. Neither I did anything to the system certificate chain.
> 
>> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  wrote:
>> 
>> 
>> 
>>> On Nov 6, 2021, at 05:39, Gerben Wierda wrote:
>>> 
>>> I was looking at updating nsd (for which I am maintaining and it is high 
>>> time)
>>> 
>>> But fetching failed on macOS Mojave (where I have my MacPorts setup).
>>> 
>>> :debug:fetch Executing org.macports.fetch (nsd)
>>> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
>>> /opt/local/var/macports/distfiles/nsd
>>> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
>>> https://www.nlnetlabs.nl/downloads/nsd/
>>> :debug:fetch Fetching distfile failed: SSL certificate problem: certificate 
>>> has expired
>>> 
>>> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is 
>>> the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port 
>>> fetch on Catalina, and there it works and the distribution is downloaded.
>>> 
>>> It is strange, though, because Safari on both Catalina (other machine) and 
>>> Mojave say the cert is fine. Still, it is most likely that this is a 
>>> problem that comes from still using Mojave.
>>> 
>>> Updating that machine will not happen until late December, so if I am to 
>>> maintain anything MacPorts, I need a fix to get this working again.
>>> 
>>> I have tried using curl on the Mojave machine, and that one works.
>>> 
>>> So, Safari works, curl works, but port does not work.
>>> 
>>> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that 
>>> doesn’t work either.
>> 
>> This is the "Let's Encrypt's old root certificate expired" problem described 
>> here:
>> 
>> https://trac.macports.org/wiki/ProblemHotlist#letsencrypt
>> 
>> When you said "curl works but port does not work" that's not quite right. 
>> /opt/local/bin/curl and /opt/local/lib/libcurl.dylib work. /usr/bin/curl and 
>> /usr/lib/libcurl.dylib (the latter of which MacPorts uses by default) do not 
>> work for Let's Encrypt-protected sites anymore.
>> 
>> I, on High Sierra, have the same issue, and I have no solution for you. This 
>> issue 

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Masha Vecherkovskaya]

Hi.
Just out of interest I’ve tried to fetch nsd on my Mojave
Absolutely standard MacPorts installation
MacBook-Pro:~ mashavecher$ sudo port -d fetch nsd
Password:
DEBUG: Copying /Users/mashavecher/Library/Preferences/com.apple.dt.Xcode.plist 
to /opt/local/var/macports/home/Library/Preferences
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/net/nsd
DEBUG: OS darwin/18.7.0 (macOS 10.14.6) arch i386
DEBUG: only one arch supported, so not adding the default universal variant
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Running callback portstartupitem::add_notes
DEBUG: Finished running callback portstartupitem::add_notes
DEBUG: Attempting ln -sf 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_nsd/nsd/work
 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/net/nsd/work
DEBUG: dropping privileges: euid changed to 502, egid changed to 501.
DEBUG: Starting logging for nsd @4.2.1_2
DEBUG: macOS 10.14.6 (darwin/18.7.0) arch i386
DEBUG: MacPorts 2.7.1
DEBUG: Xcode 11.3.1
DEBUG: SDK 10.14
DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.14
DEBUG: Executing org.macports.main (nsd)
DEBUG: dropping privileges: euid changed to 502, egid changed to 501.
DEBUG: fetch phase started at Sun Nov  7 09:40:41 MSK 2021
--->  Fetching distfiles for nsd
DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0.
DEBUG: dropping privileges: euid changed to 502, egid changed to 501.
DEBUG: Executing org.macports.fetch (nsd)
--->  nsd-4.2.1.tar.gz does not exist in /opt/local/var/macports/distfiles/nsd
--->  Attempting to fetch nsd-4.2.1.tar.gz from 
http://cph.dk.distfiles.macports.org/nsd
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1118k  100 1118k    0     0  3847k      0 --:--:-- --:--:-- --:--:-- 3858k
MacBook-Pro:~ mashavecher$ 

Maybe this could be helpful

Masha



On 7 November 2021 at 08:03:25, Kastus Shchuka (macpo...@tprfct.net) wrote:



> On Nov 6, 2021, at 7:53 PM, André-John Mas  wrote:  
>  
> Does it make a difference if you test via sudo or your own user login?  
>  

Well, it won't work as regular user. Regular user does not have write 
permissions to /opt/local tree.  

On the other hand, it's plain dumb why it works for me. As you can see below, 
org.macports.fetch does not use HTTPS, it downloads over HTTP. Certificates are 
just irrelevant for that.  

I am not sure what part of macports.conf controls protocol for fetch, I have 
not modified that file since 2017. (I guess I should have done it). I looked at 
the diff between my macports.conf and macports.conf.default from May 2021, and 
I don't see anything with regards to http/https. I must be missing something 
there.  

Thanks,  

Kastus  

> André-John  
>  
> Sent from my phone. Envoyé depuis mon téléphone.  
>  
>> On 06 Nov 2021, at 22:08, Kastus Shchuka  wrote:  
>>  
>> Something does not add up here.  
>>  
>> High Sierra is older than Mojave, right? I can fetch sources of nsd on High 
>> Sierra without any problems:  
>>  
>> $ sudo port -d fetch nsd  
>> DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
>> /opt/local/var/macports/home/Library/Preferences  
>> DEBUG: Changing to port directory: 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
>>   
>> DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386  
>> DEBUG: adding the default universal variant  
>> DEBUG: Reading variant descriptions from 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
>>   
>> DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies  
>> DEBUG: Finished running callback 
>> portconfigure::add_automatic_compiler_dependencies  
>> DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies  
>> DEBUG: Finished running callback 
>> portbuild::add_automatic_buildsystem_dependencies  
>> DEBUG: Running callback portstartupitem::add_notes  
>> DEBUG: Finished running callback portstartupitem::add_notes  
>> DEBUG: Attempting ln -sf 
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work
>>  
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work
>>   
>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.  
>> DEBUG: Starting logging for nsd @4.2.1_2  
>> DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386  
>> DEBUG: 

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Kastus Shchuka]

> On Nov 6, 2021, at 7:53 PM, André-John Mas  wrote:
> 
> Does it make a difference if you test via sudo or your own user login?
> 

Well, it won't work as regular user. Regular user does not have write 
permissions to /opt/local tree.

On the other hand, it's plain dumb why it works for me. As you can see below, 
org.macports.fetch does not use HTTPS, it downloads over HTTP. Certificates are 
just irrelevant for that.

I am not sure what part of macports.conf controls protocol for fetch, I have 
not modified that file since 2017. (I guess I should have done it). I looked at 
the diff between my macports.conf and macports.conf.default from May 2021, and 
I don't see anything with regards to http/https. I must be missing something 
there.

Thanks,

Kastus

> André-John
> 
> Sent from my phone. Envoyé depuis mon téléphone. 
> 
>> On 06 Nov 2021, at 22:08, Kastus Shchuka  wrote:
>> 
>> Something does not add up here.
>> 
>> High Sierra is older than Mojave, right? I can fetch sources of nsd on High 
>> Sierra without any problems:
>> 
>> $ sudo port -d fetch nsd
>> DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
>> /opt/local/var/macports/home/Library/Preferences
>> DEBUG: Changing to port directory: 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
>> DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
>> DEBUG: adding the default universal variant
>> DEBUG: Reading variant descriptions from 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
>> DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
>> DEBUG: Finished running callback 
>> portconfigure::add_automatic_compiler_dependencies
>> DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
>> DEBUG: Finished running callback 
>> portbuild::add_automatic_buildsystem_dependencies
>> DEBUG: Running callback portstartupitem::add_notes
>> DEBUG: Finished running callback portstartupitem::add_notes
>> DEBUG: Attempting ln -sf 
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work
>>  
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work
>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
>> DEBUG: Starting logging for nsd @4.2.1_2
>> DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
>> DEBUG: MacPorts 2.7.1
>> DEBUG: Xcode 9.4.1
>> DEBUG: SDK 10.13
>> DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
>> DEBUG: Executing org.macports.main (nsd)
>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
>> DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
>> --->  Fetching distfiles for nsd
>> DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0.
>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
>> DEBUG: Executing org.macports.fetch (nsd)
>> --->  nsd-4.2.1.tar.gz does not exist in 
>> /opt/local/var/macports/distfiles/nsd
>> --->  Attempting to fetch nsd-4.2.1.tar.gz from 
>> http://distfiles.macports.org/nsd
>> % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>>Dload  Upload   Total   SpentLeft  Speed
>> 100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- --:--:-- 
>> 3563k
>> $ ls -l /opt/local/var/macports/distfiles/nsd
>> total 2240
>> -rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz
>> 
>> I have MacPorts installed from a package, I did not build it, so it is 
>> pretty much standard. Neither I did anything to the system certificate chain.
>> 
>>> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  wrote:
>>> 
>>> 
>>> 
 On Nov 6, 2021, at 05:39, Gerben Wierda wrote:
 
 I was looking at updating nsd (for which I am maintaining and it is high 
 time)
 
 But fetching failed on macOS Mojave (where I have my MacPorts setup).
 
 :debug:fetch Executing org.macports.fetch (nsd)
 :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
 /opt/local/var/macports/distfiles/nsd
 :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
 https://www.nlnetlabs.nl/downloads/nsd/
 :debug:fetch Fetching distfile failed: SSL certificate problem: 
 certificate has expired
 
 Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is 
 the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port 
 fetch on Catalina, and there it works and the distribution is downloaded.
 
 It is strange, though, because Safari on both Catalina (other machine) and 
 Mojave say the cert is fine. Still, it is most likely that this is a 
 problem that comes from still using Mojave.
 
 Updating that machine will not happen until late December, so if I am to 
 maintain anything MacPorts, I 

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[André-John Mas]

Does it make a difference if you test via sudo or your own user login?

André-John

Sent from my phone. Envoyé depuis mon téléphone. 

> On 06 Nov 2021, at 22:08, Kastus Shchuka  wrote:
> 
> Something does not add up here.
> 
> High Sierra is older than Mojave, right? I can fetch sources of nsd on High 
> Sierra without any problems:
> 
> $ sudo port -d fetch nsd
> DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
> /opt/local/var/macports/home/Library/Preferences
> DEBUG: Changing to port directory: 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
> DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
> DEBUG: adding the default universal variant
> DEBUG: Reading variant descriptions from 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
> DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
> DEBUG: Finished running callback 
> portconfigure::add_automatic_compiler_dependencies
> DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
> DEBUG: Finished running callback 
> portbuild::add_automatic_buildsystem_dependencies
> DEBUG: Running callback portstartupitem::add_notes
> DEBUG: Finished running callback portstartupitem::add_notes
> DEBUG: Attempting ln -sf 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work
>  
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: Starting logging for nsd @4.2.1_2
> DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
> DEBUG: MacPorts 2.7.1
> DEBUG: Xcode 9.4.1
> DEBUG: SDK 10.13
> DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
> DEBUG: Executing org.macports.main (nsd)
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
> --->  Fetching distfiles for nsd
> DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0.
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: Executing org.macports.fetch (nsd)
> --->  nsd-4.2.1.tar.gz does not exist in /opt/local/var/macports/distfiles/nsd
> --->  Attempting to fetch nsd-4.2.1.tar.gz from 
> http://distfiles.macports.org/nsd
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
> 100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- --:--:-- 3563k
> $ ls -l /opt/local/var/macports/distfiles/nsd
> total 2240
> -rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz
> 
> I have MacPorts installed from a package, I did not build it, so it is pretty 
> much standard. Neither I did anything to the system certificate chain.
> 
>> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  wrote:
>> 
>> 
>> 
>>> On Nov 6, 2021, at 05:39, Gerben Wierda wrote:
>>> 
>>> I was looking at updating nsd (for which I am maintaining and it is high 
>>> time)
>>> 
>>> But fetching failed on macOS Mojave (where I have my MacPorts setup).
>>> 
>>> :debug:fetch Executing org.macports.fetch (nsd)
>>> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
>>> /opt/local/var/macports/distfiles/nsd
>>> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
>>> https://www.nlnetlabs.nl/downloads/nsd/
>>> :debug:fetch Fetching distfile failed: SSL certificate problem: certificate 
>>> has expired
>>> 
>>> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is 
>>> the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port 
>>> fetch on Catalina, and there it works and the distribution is downloaded.
>>> 
>>> It is strange, though, because Safari on both Catalina (other machine) and 
>>> Mojave say the cert is fine. Still, it is most likely that this is a 
>>> problem that comes from still using Mojave.
>>> 
>>> Updating that machine will not happen until late December, so if I am to 
>>> maintain anything MacPorts, I need a fix to get this working again.
>>> 
>>> I have tried using curl on the Mojave machine, and that one works.
>>> 
>>> So, Safari works, curl works, but port does not work.
>>> 
>>> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that 
>>> doesn’t work either.
>> 
>> This is the "Let's Encrypt's old root certificate expired" problem described 
>> here:
>> 
>> https://trac.macports.org/wiki/ProblemHotlist#letsencrypt
>> 
>> When you said "curl works but port does not work" that's not quite right. 
>> /opt/local/bin/curl and /opt/local/lib/libcurl.dylib work. /usr/bin/curl and 
>> /usr/lib/libcurl.dylib (the latter of which MacPorts uses by default) do not 
>> work for Let's Encrypt-protected sites anymore.
>> 
>> I, on High Sierra, have the same issue, and I have 

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Kastus Shchuka]

Something does not add up here.

High Sierra is older than Mojave, right? I can fetch sources of nsd on High 
Sierra without any problems:

$ sudo port -d fetch nsd
DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Running callback portstartupitem::add_notes
DEBUG: Finished running callback portstartupitem::add_notes
DEBUG: Attempting ln -sf 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work
 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work
DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: Starting logging for nsd @4.2.1_2
DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
DEBUG: MacPorts 2.7.1
DEBUG: Xcode 9.4.1
DEBUG: SDK 10.13
DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
DEBUG: Executing org.macports.main (nsd)
DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
--->  Fetching distfiles for nsd
DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0.
DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: Executing org.macports.fetch (nsd)
--->  nsd-4.2.1.tar.gz does not exist in /opt/local/var/macports/distfiles/nsd
--->  Attempting to fetch nsd-4.2.1.tar.gz from 
http://distfiles.macports.org/nsd
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- --:--:-- 3563k
$ ls -l /opt/local/var/macports/distfiles/nsd
total 2240
-rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz

I have MacPorts installed from a package, I did not build it, so it is pretty 
much standard. Neither I did anything to the system certificate chain.

> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  wrote:
> 
> 
> 
> On Nov 6, 2021, at 05:39, Gerben Wierda wrote:
> 
>> I was looking at updating nsd (for which I am maintaining and it is high 
>> time)
>> 
>> But fetching failed on macOS Mojave (where I have my MacPorts setup).
>> 
>> :debug:fetch Executing org.macports.fetch (nsd)
>> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
>> /opt/local/var/macports/distfiles/nsd
>> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
>> https://www.nlnetlabs.nl/downloads/nsd/
>> :debug:fetch Fetching distfile failed: SSL certificate problem: certificate 
>> has expired
>> 
>> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is 
>> the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port 
>> fetch on Catalina, and there it works and the distribution is downloaded.
>> 
>> It is strange, though, because Safari on both Catalina (other machine) and 
>> Mojave say the cert is fine. Still, it is most likely that this is a problem 
>> that comes from still using Mojave.
>> 
>> Updating that machine will not happen until late December, so if I am to 
>> maintain anything MacPorts, I need a fix to get this working again.
>> 
>> I have tried using curl on the Mojave machine, and that one works.
>> 
>> So, Safari works, curl works, but port does not work.
>> 
>> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that 
>> doesn’t work either.
> 
> This is the "Let's Encrypt's old root certificate expired" problem described 
> here:
> 
> https://trac.macports.org/wiki/ProblemHotlist#letsencrypt
> 
> When you said "curl works but port does not work" that's not quite right. 
> /opt/local/bin/curl and /opt/local/lib/libcurl.dylib work. /usr/bin/curl and 
> /usr/lib/libcurl.dylib (the latter of which MacPorts uses by default) do not 
> work for Let's Encrypt-protected sites anymore.
> 
> I, on High Sierra, have the same issue, and I have no solution for you. This 
> issue affects High Sierra and Mojave. I recommend upgrading to Catalina or 
> later; I plan to eventually.
> 
> Well, you could rebuild MacPorts from source, instructing it to use a newer 
> copy of libcurl with a newer copy of openssl or libressl that has a newer 
> certificate bundle. For example, install a 

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Ryan Schmidt]

On Nov 6, 2021, at 05:39, Gerben Wierda wrote:

> I was looking at updating nsd (for which I am maintaining and it is high time)
> 
> But fetching failed on macOS Mojave (where I have my MacPorts setup).
> 
> :debug:fetch Executing org.macports.fetch (nsd)
> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
> /opt/local/var/macports/distfiles/nsd
> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
> https://www.nlnetlabs.nl/downloads/nsd/
> :debug:fetch Fetching distfile failed: SSL certificate problem: certificate 
> has expired
> 
> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is 
> the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port 
> fetch on Catalina, and there it works and the distribution is downloaded.
> 
> It is strange, though, because Safari on both Catalina (other machine) and 
> Mojave say the cert is fine. Still, it is most likely that this is a problem 
> that comes from still using Mojave.
> 
> Updating that machine will not happen until late December, so if I am to 
> maintain anything MacPorts, I need a fix to get this working again.
> 
> I have tried using curl on the Mojave machine, and that one works.
> 
> So, Safari works, curl works, but port does not work.
> 
> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that 
> doesn’t work either.

This is the "Let's Encrypt's old root certificate expired" problem described 
here:

https://trac.macports.org/wiki/ProblemHotlist#letsencrypt

When you said "curl works but port does not work" that's not quite right. 
/opt/local/bin/curl and /opt/local/lib/libcurl.dylib work. /usr/bin/curl and 
/usr/lib/libcurl.dylib (the latter of which MacPorts uses by default) do not 
work for Let's Encrypt-protected sites anymore.

I, on High Sierra, have the same issue, and I have no solution for you. This 
issue affects High Sierra and Mojave. I recommend upgrading to Catalina or 
later; I plan to eventually.

Well, you could rebuild MacPorts from source, instructing it to use a newer 
copy of libcurl with a newer copy of openssl or libressl that has a newer 
certificate bundle. For example, install a bootstrap copy of MacPorts in a 
separate prefix, install curl in that prefix, then rebuild your primary 
MacPorts from source, telling it to use the libcurl in the separate prefix. Any 
future upgrades to MacPorts base probably also have to be done from source; 
using "sudo port selfupdate" will not preserve your configure arguments and 
you'll be back to using the System's broken libcurl again.